CentOS SSH password-less login principle, configuration and FAQs

CentOS SSH password-less login principle, configuration and FAQs
Principles

For ease of understanding, it is assumed that the hadoop148 host can be connected to hadoop107 without a password.

Generate a key pair on hadoop148, including a public key and a private key, and copy the public key to hadoop107.

Then, when hadoop148 connects to the hadoop107 machine through SSH, The hadoop107 machine will generate a random number and encrypt the random number with the public key of hadoop148 and send it to hadoop148.

At last, hadoop148 decrypts the encrypted data with the private key and returns the decryption data to hadoop107. After confirming that the decryption data is correct, hadoop148 is allowed to connect without entering the password.

Configuration

Procedure

1. log on to hadoop148, run the command ssh-keygen-t rsa, and then return to the car all the way. Check the generated password-less key pair: cd. ssh and then execute ll

2. append id_rsa.pub to the authorization key. Run the command cat ~ /. Ssh/id_rsa.pub> ~ /. Ssh/authorized_keys

3. Modify permissions: Execute chmod 600 ~ /. Ssh/authorized_keys

4. Make sure the following content exists in cat/etc/ssh/sshd_config:

RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile      .ssh/authorized_keys

If you need to modify it, run the restart SSH server command after modification to make it take effect: service sshd restart

5. Copy the public key to all other machines: scp ~ /. Ssh/id_rsa.pub root @ hadoop107 :~ /Then enter yes and the password of the hadoop107 machine.

6. Create a. ssh folder on the hadoop107 machine:

Mkdir ~ /. Ssh

Then run chmod 700 ~ /. Ssh (create a folder if it already exists)

7. append to the authorization file authorized_keys and execute the following command:

Cat ~ /Id_rsa.pub> ~ /. Ssh/authorized_keys

Then run chmod 600 ~ /. Ssh/authorized_keys

8. Repeat Step 1

9. Verification command: Execute ssh hadoop107 on the hadoop148 machine and find that the host name is changed from hadoop148 to hadoop107. Then, delete the id_rsa.pub file: rm-r id_rsa.pub.

FAQs Symptom:

The hadoop148 machine has produced the rsa key.

The public key has been added to the server B server/root/. ssh/authorized_keys

However, when using ssh root @ hadoop107, you still need to enter the password, that is, no password authentication fails,

 

Analysis and Processing:

 

Step 1: View Permissions

Use ssh-v debug for access. The log is as follows, but the cause of failure cannot be seen from the log. Only when publickey is used for authentication, no reply is provided to the peer;

View the/var/log/secure log

By viewing the hadoop107 machine/var/log/secure, the following error is reported:

 

Jan  8 13:31:34 wng-141 sshd[32366]: Authentication refused: bad ownership or modes for directory /rootJan  8 13:31:34 wng-141 sshd[32367]: Connection closed by 135.251.218.231

 

? This log may be caused by incorrect/root directory permissions. "Authentication refused: bad ownership or modes for directory/root"

It is found that the HOME directory of all users should have 700 permissions. Otherwise, many problems may occur. This problem is also caused by this problem.

Finally, run chmod 700 root to solve the problem.

The permissions are summarized as follows:

1) the ssh directory permission must be 700

2) The permission for the user directory must be 700. For example, if I use the root user, the/root permission must be 700.
3). The ssh/authorized_keys File Permission must be 600

Part 2: view security context

If changing permissions does not solve the problem, try the following methods:

First, use ls-laZ to check the. ssh directory. If it is not ssh_home_t, use the restorecon command to restore the context of the. ssh directory. Command: restorecon-r-vv/root/. ssh

Part 3: Analysis of/var/log/audit. log logs

If the problem persists, check the audit. log File of hadoop107, which may contain incorrect information.
Reference solution: http://www.bkjia.com/ OS /201503/383435.html:

 

I immediately checked my. ssh directory with ls-laZ, but it wasn't ssh_home_t. I was so happy that I immediately used restorecon to restore the context of the. ssh directory. If you try to connect again, the result still does not work. The symptoms and error information are the same as before. So I checked the context of The. ssh directory on other machines and did not mark it as ssh_home_t, but the SSH service on those machines is normal. I carefully read the description and error information of the online case. I still suspect that it was caused by SELinux. So I want to temporarily disable SELinux. Use setenforce 0 to disable SELinux and try again. The publickey authentication is normal. I confirmed the problem caused by SELinux. Next I checked/var/log/audit. log and found the following logs:

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 sshd on my machine has no search permission on the root of the partition sda3. After confirming the problem, I carefully recalled the differences between the system installation process and other machines. The sda3 mentioned in the log is the/home partition of the system. When the operating system fails, the/home partition is only 200 MB. This problem is found after the system is installed, so I deleted and rebuilt the sda3 partition and mounted it to/home. The context on the/home directory is incorrect. Then I will restore the context of the/home directory:

[root@data ~]# 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 and reconnects to SSH. authentication is successful and the problem is solved.