Multiple CentOS servers share the ssh key for automatic login

Recently, I have been studying how to automatically log on to linux servers. This article describes how to automatically log on to the ssh key. Update: 2014.3.94: 21PM. after finishing this article last night, I found a complete description of ssh authentication on IBM's Internet. Sad .. Using rs

Recently, I have been studying how to automatically log on to linux servers. This article describes how to automatically log on to the ssh key.

Update:. after finishing this article last night, I found a complete description of ssh authentication on IBM's Internet. Sad ..

Https://www.ibm.com/developerworks/cn/linux/security/openssh/part1/

Conjecture: the generation of linux Keys is not related to the server, but only to the encryption method (using rsa or dsa) and passphrase (password phrase, entered when the key is generated.

In this case, the same pair of key can be used on multiple servers, because for servers and clients, they only need to verify that the key matches the public key during communication.

That is, a global public key is stored on the ssh server, and multiple clients use the same key to log on to the ssh server.

Test Environment: secureCRT client is used in windows, and two redhat 6.3 virtual machines (linuxA and B, 192.168.1.2/3) are deployed ). The VM and the host use a bridging network and are in the same LAN.

Test process:

Note: The public key generally ends with pub, but the file verified by the server is authorized_key. Therefore, you need to transfer the content of pub to authorized_key. Pub files are useless.

1. use CRT to generate a key pair and upload the public key to linuxA. after successful login, the public key in the cpoyA machine is sent to Machine B, so that the CRT can automatically log on to Machine B and verify that the public key is universal.

First, use CRT to generate the key:

1. use SecureCRT to create the private key and public key (Set Passphrase can be Set to an empty password for comparison verification) SecureCRT: quick Connect-> Authentiation-> Public Key-> Properties-> Create Identity File-> DSA/RSA-> Set Passphrase-> Done: two files are generated in the specified directory, for example, the private key my_rsa and the public key my_rsa.pub2.linux server are created. ssh Directory. Generally, this directory already exists (it is very important to change the permission. The permission is not 700 forbidden during authentication) # mkdir/root /. ssh # chmod 700/root /. ssh3. Upload The public key my_rsa.pub to the linux server, and convert the public key in the SSH2 compatible format to the Openssh compatible format (generally ssh2, ssh1 is not excluded) # ssh-keygen-I-f Identity. pub>/root /. ssh/authorized_keys2 # chmod 600/root /. ssh/authorized_keys24. in SecureCRT, set the logon mode to PublicKey and select the my_rsa file you just created as the private key. restart the SSH server on the Linux server (the test seems to take effect without restarting the service)

# Service sshd restart or/etc/rc. d/init. d/sshd restart

In this phase, the test is successful. the same pair of authorized_keys2 and CRT used by server A and server B can achieve automatic login.

2. generate A key pair in Machine B, copy the public key to machine A, enable Machine B to log on to machine A automatically, and then pass the key of B to the system, write the authorized_keys2 content of A to the authorized_keys2 file of B, so that A can automatically log on to B.

Step 1: Use ssh-key-gen to create a public key and a key on the local host
Local-host $ ssh-keygen-t rsa

Enter file in which to save the key (/home/jsmith/. ssh/id_rsa): [Enter key]
Enter passphrase (empty for no passphrase): [Press enter key]
Enter same passphrase again: [Pess enter key]
Your identification has been saved in/home/jsmith/. ssh/id_rsa.
Your public key has been saved in/home/jsmith/. ssh/id_rsa.pub.
The key fingerprint is: 33: b3: fe: af: 95: 95: 18: 11: 31: d5: de: 96: 2f: f2: 35: f9
Local-host

Step 2: Use ssh-copy-id to copy the public key to A remote host
Local-host $ ssh-copy-id-I ~ /. Ssh/id_rsa.pub root@192.168.1.2
Remote-host's password:
Now try logging into the machine,? Ssh? Remote-host '', and check in:
. Ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
[Note: ssh-copy-id appends the key to. ssh/id_rsa on the remote host.]

Step 3: log on to the remote host
Local-host $ ssh root@192.168.1.2.
Last login: Sat Mar 8 12:37:48 2014 from 192.168.1.3
[Note: SSH does not ask for the password.]

Then, use sftp to upload id_rsa of Machine B to machine A and transmit authorized_keys2 of machine. At this time, both A and B can automatically log on to each other.

Test result: the conjecture is verified successfully. it is best to have a third linux instance and then verify it.

Supplemental Security Questions: due. both the ssh folder and privatekey have permissions of 700 and 600. at the same time, the sftp server only enables the sftp login permission and controls the home file directory. as long as the privatekey is properly kept, there is no security concern in the ssh protocol. See SSH authentication principles (http://qujunorz.blog.51cto.com/6378776/1371344)

This article is from the "hiubuntu" blog, please be sure to keep this source http://qujunorz.blog.51cto.com/6378776/1370921