Principle Introduction
For ease of understanding, it is assumed that the hadoop148 machine can be connected to the hadoop107 by means of a password-free login.
First, a key pair is generated on the hadoop148, including a public key and a private key, and the public key is copied to the hadoop107.
Then when the hadoop148 is connected to the hadoop107 machine via SSH, the hadoop107 machine generates a random number and encrypts the random number with the hadoop148 public key and sends it to hadoop148.
Finally hadoop148 received the encryption number and then decrypted with the private key, and the decryption number back to hadoop107, hadoop107 confirm the decryption number is correct after allowing hadoop148 do not enter the password to connect
Configuration
Specific steps
1, log in hadoop148, execute the command ssh-keygen-t RSA and then return to view the no key pair that just generated: CD. SSH after execute ll
2, add the id_rsa.pub to the authorized key inside. Execute command Cat ~/.ssh/id_rsa.pub >>~/.ssh/authorized_keys
3. Modify permissions: Execute chmod ~/.ssh/authorized_keys
Problems
problem Phenomenon:
HADOOP148 machine has produced RSA key
And the public key has been added to the ServerB machine/root/.ssh/authorized_keys
But SSH [email protected] machine still need to enter the password, that is, no password authentication failed,
analysis and Processing:
First step: View permissions
With ssh-v debug access, the log is as follows, but from the log can not see the reason for failure, only know in the use of PublicKey authentication, the end is not reply;
View the/var/log/secure log again
Find all Users home directory should be 700 permissions, otherwise it will cause a lot of problems, this problem is also for this reason
Finally, execute chmod after root to resolve
A summary of the permissions issue is as follows:
1). The SSH directory must have permissions of 700
2) User directory permissions must be 700, for example, I am using the root user, then the/root permission must be 700
3). The. ssh/authorized_keys file permission must be 600
Step Two: view the security context
If you do not resolve the issue by changing permissions, you can try the following methods:
First check with Ls-laz. SSH directory, which is not ssh_home_t, you need to use the Restorecon command to restore the context of the. SSH directory. The command is: Restorecon-r-vv/root/.ssh
Step three: analyze/var/log/audit/audit.log logs
Fourth step:
Chown-r Root.root/root
This article is from the "My Ops Time" blog, so be sure to keep this source http://aaronsa.blog.51cto.com/5157083/1729244
CentOS ssh Password-free login principle, configuration and FAQs