Illustration of CentOS6.4 two-way login configuration for SSH password-less Authentication
Configuring SSH without logon verification is very convenient in many scenarios, especially when managing large cluster services, avoiding tedious password verification. On servers with higher security levels, generally, the password settings are more complex. configuring SSH not only ensures the security of Inter-node communication with the key, but also reduces the time consumption for Frequent password login and greatly improves the management efficiency. This article is also a basic preparation for the programmers who are preparing to start with Hadoop. Of course, you can also choose not to configure SSH, as long as you are willing to frequently enter the Slave node password to log on.
1. Principles of SSH password-less Authentication
As a client, Master must implement password-free public key authentication. When connecting to the server Salve, a key pair must be generated on the Master, including a public key and a private key, then, copy the public key to all Salve instances. When the Master node is linked to Salve through SSH, Salve generates a random number and encrypts the random number with the public key of the Master node and sends it to the Master node. After the Master receives the number of encrypted data, it decrypts it with the private key and returns the number of decrypted data to Salve. After confirming that the number of decrypted data is correct, the Master is allowed to connect. This is a public key authentication process, during which you do not need to manually enter the password, the important process is to copy the Public Key generated on the Master to Salve.
2. SSH password-less login relationships
Generally, a cluster service has at least one Master and several Slave instances.
Password-less login usually refers to one-way login without verification from the Master to any Slave, meaning that the password is not required to log on only from the Master to the Slave, however, if you want to log on to the Master from Slave without verification, or you want to log on without verification between Slave and Slave, these are not feasible unless, you have performed two-way authentication on the key pair before two-way login. Here we will not discuss the significance of mutual login. These methods may be required in some cases.
| Node name |
IP address |
| Master |
10.2.143.5 |
| Slave |
10.2.143.36 |
Next, let's start to step into the question. xianxian uses centos 6.4, Which is configured with two-way SSH without verification login between two nodes. The other systems are similar, first, we use the root user to log on, modify the machine name in the network, add the ing information in the hosts file, and then save and exit. The Slave machine is configured in the same way. For detailed operations, see
Then, we use the root user on the Master and Slave machines to create a hadoop user and set the password. Note that the user name and password are consistent.
Then, log on to the hadoop user, execute the following command to generate a key pair, write the public key file to the authorization file, and assign permissions,
Ssh-keygen-t rsa-p''
Cat ~ /. Ssh/id_rsa.pub> ~ /. Ssh/authorized_keys
Chmod 600 ~ /. Ssh/authorized_keys
Finally, switch to the root user, configure sshd, and cancel the commented public key field,
RSAAuthentication yes # enable RSA Authentication
PubkeyAuthentication yes # enable public key/private key pair Authentication
AuthorizedKeysFile. ssh/authorized_keys # public key file path (same as the file generated above)
Save the settings and Restart sshd to test the local SSH, as shown in.
Now, the local SSH has been configured. The following figure shows how to log on to the local machine through SSH.
In, we can see that, whether using localhost, IP address, or host name, we can smoothly perform non-verification login on the local machine.
In the following example, the Master public key file is copied to the hadoop user of the created Slave node through scp. Note that this user does not necessarily have one. create an ssh folder. ssh folder, and grant administrative permissions to 700, and then append the public key to the authorization file and grant permissions to 600. These two steps are important. Remember!
After the copy is complete, go to the Slave machine, append the authorization file with the public key, assign permissions, switch to the root user, configure the sshd, and restart the ssh service, such as the Master machine configuration.
Then, return to the hadoop user on the Master machine for testing.
We found that password verification is not required at this time. Of course, only one-way login from the Master to the Slave can be done now. If you find that from the Slave to the Master, you will not be able to, this is normal, and you want to log on to the Master in two directions, the two machines must authenticate each other's public key files, and so on. No matter how many nodes you have, as long as the two machines have mutual authentication, you can achieve login without authentication, of course, in our actual production environment, only meaningful authentication is taken into account. In the following example, hadoop users under the Slave node generate their own public key files and copy them to the Master using scp, then, append the public key to the authorization file to implement two-way authentication.
Hadoop user-generated key pair on Slave
Copy the public key on the server Load balancer instance to the hadoop user on the Master instance.
Then, in the same way as above, it is appended to the authorization file authorized_keys. Then the big work is done, and xianxian provides proof that there is no mutual authentication login.
Two-way authentication for hadoop users on the Master machine
Two-way authentication for hadoop users on Slave
So far, our two-way login verification has been completed. For multi-node authentication, only mutual public key authentication is available between nodes, for one-way management, you only need to configure the public key of one party. Of course, in the actual environment, most of them are one-way. This should be handled according to the actual situation.
You may also like the following SSH-related articles. For details, refer:
Complete SSH service configuration and troubleshooting in Ubuntu
How to install Samba and SSH server in Ubuntu 14.04
SSH service remote access to Linux Server login is slow
How to Improve the SSH login authentication speed of Ubuntu
Enable the SSH service to allow Android phones to remotely access Ubuntu 14.04
How to add dual authentication for SSH in Linux
Configure the SFTP environment for non-SSH users in Linux
Configure and manage the SSH service on Linux
