This configuration allows you to: ssh logins between cluster servers. If you only want to ssh login from other machines (slave1, slave2) from a single machine (such as master), only follow the second step.
It is recommended to spend two or three minutes to read the full text and then follow the steps
Steps:
1. Cluster environment: master, slave1, and slave2; operating system CentOS 7. For the convenience of the next description, in addition to the master, all other slaves collectively referred to as slaveX
The necessary IP-to-hostname mappings have been added to all servers’ /etc/hosts files, as follows.
192.168.137.20 master
192.168.137.21 slave1
192.168.137.22 slave2
2. Configuration allows slave to log in to slaveX without login.
Execute the following command on the master host. Can be a non-root user, I use Hadoop users. According to my test so far, which user to use to configure, and finally only through that user to achieve free login, other users still need a password to remote login.
2.1 cd ~ // Switch to user’s home directory
2.2 ls -al //Check whether there is a hidden path in the home directory is .ssh. If not, create one. Note that the permission to view the .ssh directory is 700 (drwx — —), if not, it is changed to 700.
2.3 cd.ssh //Enter into the .ssh directory
2.4 ssh-keygen-t rsa // Press the carriage return character continuously while executing the command;
???????????// This command will use rsa algorithm to generate private key id_rsa and public key id_rsa.pub in ~/.ssh directory
2.5 ssh-copy-id master //This command appends the contents of the generated public key file to the master’s authorized_keys file.
????????????/ / Note that before executing this command authorized_keys file may not exist, it does not matter, directly execute the command on the line, it will be automatically generated, of course, you can create one yourself; pay attention to authorized_keys file permissions to be 600;
????????????// In addition to the ssh-copy-id command, you can use cat id_rsa.pub >> authorized_keys to append the contents of the public key to the authorized_keys file. It is not OK to append the content to the copy_paste method.
????????????// After executing this step, you can log in to the master through the ssh master command. (Before this step, even if you log in yourself through ssh, you will need to manually enter the password every time.)
????????????//The contents of the authorized_keys file is a string starting with ssh-rsa, as shown below:
Note: The host name in the figure is inconsistent with the master and slaveX described in the article, but it does not affect the understanding of the content format in the authenticated_keys file.
2.6 ssh-copy-id slaveX // append master’s public key to slaveX’s authorized_keys file, then master can login to slaveX without secret
3. Configuration makes slaveX free to log in to other machines in the cluster
After the second step above, you can already log in to the master and slaveX on the master, but you can’t log on to other machines (master, slaveX) from slaveX. If you want slaveX to be like master, you can avoid it. To log in to other machines, you need to perform the same steps in step 2 on slaveX, that is, generate your own private key public key pair on slaveX, and then append it’s public key to the authorized_keys file of other machines.
To sum up, if you want to configure cluster servers to securely log in to each other, you can use the following two methods: (The essence of the two methods is the same, but the process steps are slightly different.)
Method one: One server is operated as in step 2 until all machines are configured;
Method 2: All machines, including master and slaveX, use the ssh-keygen -t rsa command to generate their own private key public key pairs, and then use the ssh-copy-id master command to append both the master and slaveX public keys to the master. In the authorized_keys file, when all the files are appended, the master’s authorized_keys file already contains the public key information of all the servers in the cluster (including the master and other slaves). It can be seen that all the machines in the cluster can log in without SSH. Master), it is a complete public key information file, then use the scp command to send the authorized_keys on the master sequentially to the ~/.ssh/ directory of each slave (scp command example: scp ~/.ssh/ Authorized_keys hadoop@node01:~/.ssh/). In this way, the entire cluster can be ssh-free login.
————————————————– ——————————
As for the next step, I saw this operation in an individual blog post when I searched for information on the Internet. I didn’t configure this when I operated it. I don’t know how it affects the result because I didn’t do this configuration and also made ssh. Free login is successful. If you must configure it, complete this configuration before performing step 2.
On each host in the cluster
Sudo vim /etc/ssh/sshd_config
Open the following options
RSAAuthentication yes //Allows authentication with RSA keys
PubkeyAuthentication yes //Allows authentication with public key
AuthorizedKeysFile.ssh/authorized_keys //The file of the public key saved by this machine (this is more important)
For the /etc/ssh/sshd_config file, the online query suggested: “Do not change the setting of the /etc/ssh/sshd_config file unless necessary. Because the default situation is usually the most stringent SSH protection, you don’t need to change him!
Recent Comments