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 .
And then when hadoop148Connect via SSHhadoop107Machine, hadoop107 Machine A random number is generated and hadoop148The public key encrypts the random number and sends the hadoop148。
At last hadoop148After you receive the encryption number, decrypt it with the private key, and pass the decryption number back tohadoop107, hadoop107After confirming that the decryption number is correct, allow hadoop148Connect without entering a password
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
4. Ensure that the following contents exist in Cat/etc/ssh/sshd_config
Rsaauthentication yespubkeyauthentication yesauthorizedkeysfile . Ssh/authorized_keys
To modify, execute the Restart SSH Service command after modification to make it effective: service sshd restart
5, the public The key is copied to all other machines: SCP ~/.ssh/id_rsa.pub [Email protected]hadoop107:~/ Then enter Yes, and finally enter hadoop107 password for machine
6. Create the. ssh folder on the hadoop107 machine:
mkdir ~/.ssh
Then execute chmod ~/.ssh (if the folder exists then you do not need to create it)
7. Append to authorization file Authorized_keys Execute command:
Cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
Then execute chmod ~/.ssh/authorized_keys
8, repeat the 4th step
9. Verification command: in Hadoop148Execute SSH on the machine hadoop107The host name is found by hadoop148Become hadoop107That is successful, finally delete the Id_rsa.pub file: Rm-r id_rsa.pub
FAQ
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]hadoop107 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
By looking at the hadoop107 machine/var/log/secure, we found the following error
Jan 8 13:31:34 wng-141 sshd[32366]: Authentication Refused:bad ownership or modes for Directory/rootjan 8 13:31: wng-141 sshd[32367]: Connection closed by 135.251.218.231
? From this log, the permissions for the/root directory may be incorrect, "Authentication Refused:bad ownership or modes for Directory/root"
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
Part II: Viewing 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
Part III: Analyzing/var/log/audit/audit.log logs
If still not, view hadoop107 's Audit.log file, there might be a wrong information about
Processing method Reference: Http://www.cnblogs.com/qcly/archive/2013/07/27/3219535.html article in the processing method:
If I get a lifeline, I'll use Ls-laz to check my. SSH directory, it is not ssh_home_t, Heart secretly happy, immediately use Restorecon to. The context of the. SSH directory is restored. try to connect again, the result is still not working, the symptom and error message is the same as before. So I looked at the context of the. SSH directory on other machines, none of them are labeled ssh_home_t, but the SSH service on those machines is normal. I took a closer look at the description and error message of the case on the Internet, and I still suspect that it was the result of SELinux. So I want to temporarily shut down SELinux to try, use Setenforce 0 to turn SELinux off, retry the connection, PublicKey authentication is OK. confirmed that the problem was caused by selinux, and then I looked at/var/log/audit/audit.log and found the following log:
TYPE=AVC Msg=audit (1362560807.992:320): AVC: denied {search} for pid=1595 comm= "sshd" name= "/" Dev=sda3 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Tcontext=system_u:object_r:file_t:s0 Tclass=dir
The only difference between this log and the online case is that sshd has no Read permission on the Authorized_keys file in the partition dm-0, and my machine is sshd does not have search permission on the root of the partition Sda3. confirming the problem, I carefully recalled how the system's installation process differs from other machines. The sda3 mentioned in the log is the system's/home partition, when the fashion system due to the operation of the fault/home partition only 200M, after loading the system found this problem, so I removed the Sda3 partition reconstruction, and then mounted to/home. Such a toss, the context on the/home directory is not right. I then restored the context of the/home directory:
[[email protected] ~]# restorecon-r-vv/home/restorecon reset/home Context system_u:object_r:file_t : S0->system_u:object_r:home_root_t:s0restorecon Reset/home/lost+found Context system_u:object_r:file_t:s0-> System_u:object_r:lost_found_t:s0restorecon Reset/home/sw/.pki Context Unconfined_u:object_r:user_home_t:s0-> Unconfined_u:object_r:home_cert_t:s0restorecon Reset/home/sw/.pki/nssdb Context unconfined_u:object_r:user_home_t : S0->unconfined_u:object_r:home_cert_t:s0
then Setenforce 1 opens SELinux, reconnecting SSH, authentication success, problem solving.
CentOS ssh Password-free login principle, configuration and FAQs