First, the situation
The company has just a few Linux, now to the host between the remote SSH password-free login.
Second, the principle
quite simply, using Ssh-keygen to generate private and public keys on host A, copying the generated public key to remote machine Host B, you can use the SSH command to log on to another machine Host B without a password.
Third, step
Host A:
1. Generate public and private key files Id_rsa and Id_rsa.pub (knock 3 down to enter)
[Root@bogon ~]# ssh-keygen-t RSA
Generating public/private RSA key pair.
Enter file in which to save the key (/ROOT/.SSH/ID_RSA):
Enter passphrase (empty for no passphrase):
Enter same Passphrase again:
Your identification has been saved In/root/.ssh/id_rsa.
Your public key has been saved in/root/.ssh/id_rsa.pub.
The key fingerprint is:
67:da:0d:79:e0:d6:2b:cd:7d:22:af:51:7e:9c:75:fe Root@bogon
The key ' s Randomart image is:
+--[RSA 2048]----+
| |
| |
| . |
| . + |
| S B O. o|
| * * = o+|
| . o B +.=|
| . + +.|
| ... e|
+-----------------+
2. The Ssh-cop-id command copies the specified public key file to the remote computer
[Root@bogon ~]# ssh-copy-id-i ~/.ssh/id_rsa.pub root@10.1.250.166
the authenticity of host ' 10.1.250.166 (10.1.250.166) ' can ' t be established.
RSA key fingerprint is c8:9d:6d:92:55:77:3d:3e:af:f5:cb:18:80:5a:47:93.
Are you sure your want to continue connecting (yes/no)? Yes
warning:permanently added ' 10.1.250.166 ' (RSA) to the list of known hosts.
Reverse mapping checking getaddrinfo for Bogon [10.1.250.166] failed-possible break-in-attempt!
root@10.1.250.166 ' s password: < Host B login password >
Now try logging to the machine, with SSH ' root@10.1.250.166 ', and check in:
. Ssh/authorized_keys
To make sure we haven ' t added extra keys this you weren ' t expecting.
3, and then SSH Landing Host B Verify the need for a password
[Root@localhost ~]# ssh 10.1.250.166
Reverse mapping checking getaddrinfo for Bogon [10.1.250.166] failed-possible break-in-attempt!
Last login:wed Oct 10:05:39 2015 from 10.1.250.141
[Root@bogon ~]#
4, after the successful landing, we need to do in the Host B more than 3 steps, so that the password can be mutually-free SSH landing. (if there are more than one host, each host will do the same operation to facilitate later management).
5, Permission issues
Recommended to use other users to do SSH login, adjust directory file permissions
Set Authorized_keys Permissions
chmod 644 Authorized_keys
setting. SSH Directory Permissions
chmod 700-r. SSH
6, to ensure that. Both SSH and Authorized_keys have write permission only to the user. Otherwise the validation is invalid.
This article comes from the "good Big Knife" blog