Configure SSH without logon verification, in many scenarios is very convenient, especially in the management of large cluster services, avoid cumbersome password verification, the higher the security level of the server, the usual password settings more complex, configure SSH, not only can use the key to ensure the security of communication between nodes, At the same time, it also reduces the time-consuming of the frequent input password landing, and greatly improves the management efficiency.
Principle Introduction
For ease of understanding, assume that you need to be able to connect to hadoop107 on the hadoop148 machine via 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 hadoop148 connects 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 not enter the password to connect the
Configuration
Specific steps
1, login hadoop148, execute command ssh-keygen-t RSA all the way back, view just generated no key pair: CD. SSH execution ll
2, add the id_rsa.pub to the authorized key inside. Execute command Cat ~/.ssh/id_rsa.pub >>~/.ssh/authorized_keys
3, modify the permissions: the implementation of 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 the SSH root@hadoop107 machine still needs 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 cause of failure, only know that in the PublicKey authentication, the end of the reply;
View the/var/log/secure log again
Finding that all users ' home directories should be 700, or cause a lot of problems, is also a problem for this reason
Finally, the execution of chmod-root resolves
The summary of permissions issues is summarized as follows:
1. SSH directory must have a permission of 700
2 User directory permissions must be 700, for example, I was operating with the root user, then the/root must be 700
3). ssh/authorized_keys file permissions must be 600
Step Two: View the security context
If you cannot resolve the problem by changing permissions, you can try the following methods:
First check with Ls-laz. SSH directory, it is not ssh_home_t, you need to use the Restorecon command to restore the context of the. SSH directory. The order is: Restorecon-r-vv/root/.ssh
Step three: Analyze/var/log/audit/audit.log log
Modify Directory user permissions
Chown-r Root.root/root
Thank you for reading, I hope to help you, thank you for your support for this site!