01. Introduction to the principle of mutual trust
What is SSH?
Simply put, SSH is a network protocol used for encrypted login between computers. For example, a user uses the SSH protocol to log in to another remote computer from a local computer.
In the earliest days, Internet communications were all plaintext communications. Once intercepted, the content was exposed. In 1995, the Finnish scholar Tatu Ylonen designed the SSH protocol to encrypt all login information and become a basic solution for Internet security. It has quickly been promoted throughout the world and has now become the standard configuration of Linux systems.
Basic usage of SSH
The default port of SSH is 22, which means that your login request will be sent to port 22 of the remote host. Use the p parameter to modify this port.
ssh -p 2222 user@hostname
或
ssh -p 2222 user@ip
# 先扩展变量$1,再执行远程命令
ssh user@123.456.789.0 "cd testdir;./test.sh \"$1\""
[Other usage]
http://www.ruanyifeng.com/blog/2011/12/ssh_port_forwarding.html
Man in the middle attack
The reason why SSH can guarantee security is that it uses public key encryption.
- The remote host receives the user's login request and sends its public key to the user.
- The user uses this public key to encrypt the login password and send it back.
- The remote host uses its own private key to decrypt the login password. If the password is correct, it will allow the user to log in.
The process itself is safe, but there is a risk in implementation: if someone intercepts the login request, impersonates the remote host and sends the forged public key to the user, it is difficult for the user to distinguish the authenticity. Because unlike the https protocol, the public keys of the SSH protocol are not notarized by a certificate authority (CA), that is, they are all issued by themselves.
It is conceivable that if an attacker is inserted between the user and the remote host (for example, in a public wifi area), using a forged public key to obtain the user's login password. Then use this password to log in to the remote host, then the SSH security mechanism is gone.
Password login
If you are logging in to the host of the other party for the first time, the following prompt will appear:
$ ssh user@host
The authenticity of host 'host (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
The meaning of this passage is that the authenticity of the host cannot be confirmed, only its public key fingerprint is known. Do you want to continue the connection?
The so-called "public key fingerprint" refers to the long length of the public key (the RSA algorithm is used here, up to 1024 bits), which is difficult to compare, so it is calculated by MD5 to turn it into a 128-bit fingerprint. In the above example, it is 98:2e:d7:e0: de:9f:ac:67:28:c2:42:2d:37:16:58:4d, and it is much easier to compare.
A natural question is, how does the user know what the public key fingerprint of the remote host should be? The answer is that there is no good way. The remote host must post the fingerprint of the public key on its website so that the user can check it by himself.
It is assumed that after risk measurement, the user decides to accept the public key of this remote host.
Are you sure you want to continue connecting (yes/no)? yes
A prompt will appear, indicating that the host has been approved.
Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.
Then, you will be asked for a password.
Password: (enter password)
If the password is correct, you can log in.
When the public key of the remote host is accepted, it will be saved in the file $HOME/.ssh/known_hosts. Next time you connect to this host, the system will recognize that its public key has been saved locally, and skip the warning part and directly prompt for the password.
Each SSH user has its own known_hosts file. In addition, the system also has such a file, usually /etc/ssh/ ssh_known_hosts , which saves the public keys of remote hosts that are trusted by all users.
Public key login
Use a password to log in. You must enter the password every time, which is very troublesome. Fortunately, SSH also provides public key login, which saves the step of entering a password.
The principle of the so-called "public key login" is very simple, that is, the user stores his public key on the remote host. When logging in, the remote host will send a random string to the user, which will be sent back after the user encrypts it with his private key. The remote host uses the public key stored in advance to decrypt it. If it succeeds, it proves that the user is credible and directly allows the login shell without requiring a password.
This method requires users to provide their own public key. If there is no ready-made one, you can directly use ssh-keygen to generate one:
$ ssh-keygen
After running the above command, a series of prompts will appear, and you can press Enter all the way. One of the questions is whether to set a passphrase for the private key. If you are worried about the security of the private key, you can set one here.
After the operation is over, two new files will be generated in the $HOME/.ssh/ directory: id_rsa.pub and id_rsa . The former is your public key and the latter is your private key.
Then enter the following command to transfer the public key to the remote host host:
$ ssh-copy-id user@host
Well, since you log in again, there is no need to enter a password.
If it still doesn't work, open the file /etc/ssh/sshd_config of the remote host and check whether the "#" comment in front of the following lines is removed.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Then, restart the ssh service of the remote host
service ssh restart
Authenticate the authorized_keys file
The remote host saves the user's public key in the $HOME/.ssh/authorized_keys file in the user's home directory after login. The public key is just a string, just append it to the end of the authorized_keys file.
Instead of using the above ssh-copy-id command, use the following command to explain the saving process of the public key:
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
This command consists of multiple statements, broken down one by one:
- "$ ssh user@host" means to log in to the remote host;
- The mkdir .ssh && cat >> .ssh/authorized_keys in single quotes indicates the command executed on the remote shell after login;
- The function of "$ mkdir -p .ssh" is to create one if the .ssh directory in the user's home directory does not exist;
- 'cat >> .ssh/authorized_keys' <~/.ssh/id_rsa.pub is to redirect the local public key file ~/.ssh/id_rsa.pub and append it to the end of the remote file authorized_keys.
After writing the authorized_keys file, the public key login setting is complete.
02. Establish mutual trust between two machines
Generally, when you use the ssh command to access another machine, or use the scp command to copy data and files from another machine, you must enter the password of the corresponding account. To establish a trust relationship between two machines, you can omit the process of entering a password.
A Machine operation
Check whether there are id_rsa and id_rsa.pub files in the current user.ssh folder
ls ~/.ssh
If you have not generated these two files before, you need to execute:
ssh-keygen -t rsa
View id_rsa.pub content
cat ~/.ssh/id_rsa.pub
B Machine operation
Append the public key id_rsa.pub to the authorized_keys file of another machine
vim authorized_keys
In this way, a public key login method from A to B is established, that is, password-free login . In the same way, establish the public key login method from B to A.
Note that because sshd has strict permissions requirements, if you still need to enter a password, you can go to host B to see the permissions of the .ssh folder and authorized_keys file. The permissions of the .ssh folder should be 755, and the permissions of the authorized_keys file should be 600, which can be changed using the chmod command:
chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
03. Establishment of mutual trust between clusters
Mutual trust can be established manually, but too many machines are troublesome. It is much more convenient to pass scripts. The principles of scripting are as follows:
- The first step is to generate keys on each host;
- The second step is to copy the public key on each host to the authorized_keys of the host executing the command;
- The third step is to distribute authorized_keys to other hosts;
- The fourth step is to modify the access permission of authorized_keys to 600.
- Verification mutual trust (no verification mutual trust operation in the script)
#!/bin/sh
## 1 delete .ssh directory
UserName="mongodb"
rm -rf ~/.ssh
ssh-keygen -t rsa
ssh-keygen -t dsa
startnode=7
endnode=7
for ((i=${
startnode}; i<=${
endnode}; i++));
do
ssh $UserName@node$i 'rm -rf ~/.ssh; ssh-keygen -t rsa -f ~/.ssh/id_rsa -P "";exit '
ssh $UserName Node$i 'rm -rf ~/.ssh;ssh-keygen -t rsa -f ~/.ssh/id_rsa -P "";exit'
done;
# 2 copy public keys to one file
#ssh $UserName@node1
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
for ((i=${
startnode}; i<=${
endnode}; i++));
do
ssh $UserName@node$i cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh $UserName@node$i cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
done;
# 3 Dispath authorized_keys to other machines and change file property
chmod 600 ~/.ssh/authorized_keys
for ((i=${
startnode};i<=${
endnode};i++));
do
scp ~/.ssh/authorized_keys $UserName@node$i:~/.ssh/
ssh $UserName@node$i 'chmod 600 ~/.ssh/authorized_keys'
done;
Script parameter description:
- UserName corresponds to the host name;
- ssh-keygen -t rsa and ssh-keygen -t dsa generate two encryption keys, of course you can use only one of them;
- startnode and endnode indicate the range of node IP, such as from 192.168.2.150 to 192.168.2.159, startnode=1, endnode=9, you only need to execute the script on the 192.168.2.150 host;
- ssh username@hostname cmd Log in to the remote host and execute cmd commands. If multiple commands need to be executed, they need to be written as'cmd;cmd;cmd'
- The current function of the script is still relatively weak. For example, the ip range must be continuous and the prefix of the host name must be the same, but for building a small cluster, configuring mutual trust between hosts is basically sufficient.
04. Other issues
The defined masterserver and 192.168.50.131 are the same thing, but the effects of the two methods are different.
ssh-copy-id -i id_rsa.pub root@192.168.50.131
ssh-copy-id -i id_rsa.pub root@masterserver
If the public key is transmitted via IP, it can only be accessed via IP, and access via host name requires a password. The second method is not required.
By observing the know_hosts file, we found that the second method has more host names in front than the first method. After testing, if you manually add the host name to the know_hosts file of the first method, the effect is the same as the second method.