The process of SSH service based on key authentication in Linux system

As we all know, SSH is currently the most reliable protocol designed to provide security for remote login sessions and other network services. It works on TCP port 22 by default. The specific implementation software includes: OpenSSH (installed by default on CentOS) and DropBear. The ssh protocol currently has two versions, v1 and v2. v1 is based on CRC-32 for MAC and is not secure. v2 uses the DH algorithm for key exchange and RSA or DSA for identity authentication. Therefore, most of the popular Linux versions currently use version V2.

After a brief understanding of ssh, let's talk about its two user login authentication methods. The first one is based on username and password. I believe everyone should know this authentication method. If we want to log in to the remote Linux system, we must enter the corresponding username and password to log in to the remote Linux system. This method is an interactive login. The second is the key-based authentication method we are going to talk about today.

First, let's understand the process of ssh encrypted communication

As can be seen from the above figure, there must be a key pair on the client. We all know that keys appear in pairs, and only A's private key can decrypt what is encrypted with A's public key. It is precisely because of this feature of asymmetric encryption that it is not difficult for us to understand that SSH communication also uses this feature to ensure data security. There is also a pair of public and private keys on the server side, and its purpose is also to encrypt and decrypt data. The process of ssh encrypted communication is roughly like this: if the client wants to encrypt communication with the server, the client first needs to obtain the server's public key. After obtaining the server's public key, it can use the server's public key to encrypt the data to be sent, and then send it to the server. When the server receives the ciphertext data, it will use its own private key to decrypt it, thereby realizing data encryption from the client to the server. Similarly, the process for the server to send data to the client is the same. It obtains the client's public key, encrypts it with the client's public key, and then sends it to the client. The client decrypts it with its own private key, thus achieving encrypted communication between you and me.

Let's think about it, the server and client use each other's public key to encrypt data when communicating, so how does the client get the server's public key? How does the server get the client's public key?

Let's look at the public key exchange process when the server and client connect for the first time.

First, the client sends an ssh connection request to the server. After receiving the request, the server will send its public key and session ID to the client. After the client receives the public key from the server, it will XOR its own public key with the session ID sent by the server, encrypt the result with the server's public key, and then send the encrypted ciphertext to the server through the network. After the server receives the ciphertext sent by the client, it will decrypt it with its own private key, and then XOR the result with the previous session ID to finally get the client's public key. After such a process, the client has the server's public key, and the server also has the client's public key. After having each other's public key, they can use the other party's public key to encrypt data later.

Anyone who has used Linux knows that when we establish an ssh remote connection with the server for the first time, there will be a confirmation asking us whether to continue the connection. We can only enter the password after we enter yes. Why do I do this? In fact, when the server sends its own public key to the client, because the client has no way to confirm whether the public key it received is sent by the other server, it will perform md5 and sha256 on the received public key, extract the fingerprint of the public key, and then prompt us to say that I have received a public key with md5 as xxx. Do you confirm this public key? If we confirm, it means we believe that this public key is sent by the server. In this way, we can do the following: XOR our own public key and session ID, and encrypt the result with the public key just received. We imagine that if the public key is not sent by the server, but by the hacker, and if we confirm it, after the subsequent ciphertext is obtained by the hacker, the hacker will use his own private key to decrypt it and obtain the client's public key and data. Then after he gets the real data, the hacker can change it at will, and then encrypt it with the server's public key and send it to the server. In this way, the data obtained by the server is the data modified by the hacker, not the real data sent by the client. This is called a man-in-the-middle attack, which uses one's own public key to impersonate the server and client roles back and forth.

Now that we understand the process of ssh encrypted communication and key exchange, let's take a look at the process of ssh login verification based on username, password and key.

The process of login based on username and password is as follows: first, the client initiates an ssh connection request, and the server will send its public key to the client. After the client receives the server's public key, it encrypts the password with the server's public key and sends it to the server. The server receives the encrypted password and decrypts it with its own private key to obtain the password sent by the client. It then uses this password for verification, encrypts the verification result with the client's public key and sends it to the client. After receiving the result, the client decrypts it with its own private key, thus completing the verification process. If the verification passes, the client logs in successfully, otherwise the client login fails.

The process of key-based login verification is: first, the client must generate a key pair (this key pair is for the user, not the public key and private key of the host. The ones mentioned above are the public key and private key of the host), and manually add the generated public key to the server (by default, it is added to the .ssh/authorized_keys of a user's home directory on the server. If we want to use that user to connect to the server, we need to add the public key to the .ssh/authorized_keys file in the home directory of that user). After the server has the public key of the client user, when the client initiates an ssh connection request, the server will generate a string of random characters, encrypt this random string with the corresponding client user's public key, and then send it to the client. After the client receives the encrypted random characters sent by the server, the client will use its own private key to decrypt it, and then send the decrypted random characters to the server. After the server receives the random characters sent by the client, it will compare them. If they are the same as the random characters sent before, the server will allow password-free login.

From the above introduction, it is not difficult to find that if we want to log in based on key verification, we must generate a pair of user key pairs on the client, and put the generated user public key in the .ssh/authorized_keys file in the home directory of a user on the server. This user is the user we will use for key verification to log in to the server in the future. Next, let’s do some experimenting.

1. Generate a user key pair on the client

[qiuhom@docker ~]$ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/qiuhom/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/qiuhom/.ssh/id_rsa.
Your public key has been saved in /home/qiuhom/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:CbICoBfN3670ucEBjhDR/ltyYoe/jJMIWCkCK5Lt5eA qiuhom@docker
The key's randomart image is:
+---[RSA 2048]----+
|. += |
|+ o+ |
|++oo..o. |
|Bo=.o=.o.. |
|+*.+o..oS |
|. E.. B.=. |
| . + %o. |
| . =o+. |
| ..+o |
+----[SHA256]-----+
[qiuhom@docker ~]$ll .ssh/
Total dosage 8
-rw------- 1 qiuhom qiuhom 1675 November 2 16:54 id_rsa
-rw-r--r-- 1 qiuhom qiuhom 395 November 2 16:54 id_rsa.pub
[qiuhom@docker ~]$

Note: In Linux, we use the ssh-keygen command to generate a user key pair. The -t option indicates the encryption algorithm used to generate the key. The generated key pair is placed in the .ssh/ directory in the current user's home directory by default. They are called id_rsa and id_rsa.pub respectively. From the names we can know that id_rsa is the private key and id_rsa.pub is the public key. If you are careful, you must have noticed that when we use ssh-keygen to generate a key, it will ask us where to store the key file. The default is in the .ssh directory under the current user's home directory. Of course, we can also use the -f option to specify the storage location. In addition, it also asks us to enter a password. The password here represents the password for encrypting the private key. We all know that it is very dangerous to get the other party's private key, so the system will prompt us by default. If you press Enter, it means that the generated private key is not encrypted. Of course, we can also use the -P (uppercase) option to specify the password for encrypting the private key.

2. Put the public key generated by the user into .ssh/authorized_keys in the user's home directory on the server. We can use the scp command to put it on the server, or copy it via a USB flash drive, but this is too troublesome. Here we use a special tool, ssh-copy-id, to copy the user's public key file information to the corresponding user home directory on the server.

[qiuhom@docker ~]$ssh-copy-id -i .ssh/id_rsa.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
The authenticity of host '192.168.0.151 (192.168.0.151)' can't be established.
RSA key fingerprint is SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
RSA key fingerprint is MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
 
Number of key(s) added: 1
 
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
 
[qiuhom@docker ~]$

Note: The -i option specifies the storage location of the public key file. The default is .ssh/public key file name in the current user's home directory. Because the server does not have the client user's public key before we copy the public key, we need to enter the password for verification when we copy the user's public key. One thing to note here is that the sshd service on the server side of our experiment works on port 22 by default. If it does not work on the default port, you need to use the -p (lowercase) option to specify the port.

At this point we have completed ssh key-based password-free login authentication.

The key generation and issuance mentioned above are all done manually, so there is no problem with one or two servers, but what if there are more servers? If we need to manage many servers, we need to write a script to complete it. The following is a script I wrote. The function it implements is to automatically generate a key and automatically send it to the specified host.

[qiuhom@docker ~]$cat ssh_keygen.sh
#!/bin/bash
 
remote_host_ip=$1
remote_host_user=$2
remote_host_port=$3
remote_host_passwd=$4
local_rsa_file=~/.ssh/id_rsa
local_rsa_pub_file=~/.ssh/id_rsa.pub
 
[ $# -ne 4 ] && echo "Usage: sh $0 RemotehostIp RemotehostUser RemotehostPort RemotehostPasswd" && exit 5
 
[ ! -e ${local_rsa_file} ] && ssh-keygen -t rsa -P '' -f ${local_rsa_file} >/dev/null 2>&1
 
expect << EOF
set timeout 10
spawn ssh-copy-id -i ${local_rsa_pub_file} $remote_host_user@$remote_host_ip -p $remote_host_port
expect {
 "(yes/no)?" {send "yes\n";exp_continue}
 "password: " {send "$remote_host_passwd\n"}
}
expect eof
EOF

Note: This script requires you to pass the remote server IP, remote host user, remote host ssh port and password. This script automatically generates keys and sends them to the specified server. If you need to send them to more servers, you can write another script to call this script to achieve the function of batch creation and distribution of key files.

test:

Use the script to generate a key file and send it to the specified server

[qiuhom@docker ~]$ll .ssh/
Total usage 0
[qiuhom@docker ~]$ssh [email protected]
The authenticity of host '192.168.0.151 (192.168.0.151)' can't be established.
RSA key fingerprint is SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
RSA key fingerprint is MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.151' (RSA) to the list of known hosts.
[email protected]'s password:
[root@test ~]#ll .ssh/
Total dosage 4
-rw------- 1 root root 0 Nov 2 17:43 authorized_keys
-rw-r--r-- 1 root root 1202 Oct 31 21:25 known_hosts
[root@test ~]#rm -rf .ssh/*
[root@test ~]#ll .ssh/
Total usage 0
[root@test ~]#exit
logout
Connection to 192.168.0.151 closed.
[qiuhom@docker ~]$rm -rf .ssh/*
[qiuhom@docker ~]$sh ssh_keygen.sh 192.168.0.151 root 22 admin
spawn ssh-copy-id -i /home/qiuhom/.ssh/id_rsa.pub [email protected] -p 22
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/qiuhom/.ssh/id_rsa.pub"
The authenticity of host '192.168.0.151 (192.168.0.151)' can't be established.
RSA key fingerprint is SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
RSA key fingerprint is MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
 
Number of key(s) added: 1
 
Now try logging into the machine, with: "ssh -p '22' '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
 
[qiuhom@docker ~]$ll .ssh/
Total dosage 12
-rw------- 1 qiuhom qiuhom 1675 November 2 17:53 id_rsa
-rw-r--r-- 1 qiuhom qiuhom 395 November 2 17:53 id_rsa.pub
-rw-r--r-- 1 qiuhom qiuhom 395 November 2 17:53 known_hosts
[qiuhom@docker ~]$ssh [email protected]
[root@test ~]#ll .ssh/
Total dosage 4
-rw------ 1 root root 395 Nov 2 17:53 authorized_keys
[root@test ~]#cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6yfNtYfGtwyZLKuffYgFoMZfEnKhpsp1pH3Mky1UGBsUNRGHIhNZzbtVNERWkAV/NndasfHss/vEnDSHVOXRScRfH7pPCNdVdy887WlSgshG6U5UIsQnlxlkUxf0ciVlc9VEw/IIg8eXrlOmcuezadxGc32yHB7o+zkEcg7UBYClDtjp5xqzrHyLDMd5OhGqMPJO+d+OFKqhOOYAUYsUi00aM1qNbf+KHFhYbQQj96UbWRTNQYFnqIJltvDPxqq7W5GGVl0xma6PSgGYMFNwIy9PhJJ8Lxaiaw3FjC8iCWrjzRONbnaqMPqrS8wQXs95vRDi2M0egKUuRlzFjGAGB qiuhom@docker
[root@test ~]#exit
logout
Connection to 192.168.0.151 closed.
[qiuhom@docker ~]$cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6yfNtYfGtwyZLKuffYgFoMZfEnKhpsp1pH3Mky1UGBsUNRGHIhNZzbtVNERWkAV/NndasfHss/vEnDSHVOXRScRfH7pPCNdVdy887WlSgshG6U5UIsQnlxlkUxf0ciVlc9VEw/IIg8eXrlOmcuezadxGc32yHB7o+zkEcg7UBYClDtjp5xqzrHyLDMd5OhGqMPJO+d+OFKqhOOYAUYsUi00aM1qNbf+KHFhYbQQj96UbWRTNQYFnqIJltvDPxqq7W5GGVl0xma6PSgGYMFNwIy9PhJJ8Lxaiaw3FjC8iCWrjzRONbnaqMPqrS8wQXs95vRDi2M0egKUuRlzFjGAGB qiuhom@docker
[qiuhom@docker ~]$

Note: You can see that before our script is run, you need to manually enter the password to log in to the server. After we execute the script, the user key file is created and the user public key file is sent to the corresponding server.

Summary: SSH key-based authentication has the following benefits

1. More secure and convenient. We don't have to remember cumbersome user passwords, nor do we have to worry about password leaks. (We can configure the sshd service to only allow login based on KEY authentication)

2. Password-free login based on key verification can realize remote batch operation of servers, which is convenient for script writing, making it as simple as executing commands locally when we execute remote operation commands (such as scp, ssh)

3. Effectively prevent the threat of brute force password guessing.

Summarize

The above is the process of key authentication practice of SSH service in Linux system introduced by the editor. I hope it will be helpful to everyone!