Shulou(Shulou.com)06/01 Report--

The purpose of this article is to share with you the content of an example analysis of SSH services in Linux systems based on key authentication practices. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

It is well known that ssh is currently a reliable protocol designed to provide security for remote login sessions and other network services. It works on port 22 of tcp by default. The specific implementation software are: openssh (centos installed by default), dropbear. At present, there are two versions of ssh protocol: v1 and v2 MAC based on CRC-32, which is not safe. V2 does key exchange based on DH algorithm and realizes identity authentication based on RSA or DSA. So at present, most of the popular Linux uses the V2 version.

After a brief understanding of ssh, let's talk about its two ways of user login authentication, the first one is based on the user name and password, which we should all know, that is, if we want to log on to the remote Linux system, we must enter the corresponding user name and password to log in to the remote Linux system. The second is the key-based authentication that we are going to talk about today.

First of all, let's take a look at the process of ssh encrypting communication.

As you can see from the above figure, there must be a key pair on the client, we all know that the key appears in pairs, and only A's private key can be decrypted with A's public key encryption. It is precisely because of this feature of asymmetric encryption that it is not difficult to understand that ssh communication also uses this feature to determine data security. There is also a pair of public and private keys on the server side, which also exists 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 get the public key of the server. After getting the public key of the server, it can use the public key of the server to encrypt the data to be sent to the server, and then send it to the server. When the server receives the data of the ciphertext, it will decrypt it with its own private key, thus realizing the data encryption from the client to the server. Similarly, it is the same process for the server to send the data to the client. The public key of the client is encrypted with the public key of the client, and then sent to the client, and the client decrypts it with its own private key, thus realizing the encrypted communication between you and me.

Let's think about it, both the server and the client communicate with each other's public key to encrypt the data, so how does the client get the server's public key? How does the server get the public key of the client?

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

First, the client sends a ssh connection request to the server. After receiving the request, the server sends its public key and session ID to the client. After the client receives the public key from the server, it makes an XOR operation between its public key and the session ID sent by the server, encrypts the result with the server's public key, and then sends the encrypted ciphertext to the server through the network. After receiving the ciphertext sent by the client, the server will decrypt it with its own private key, and then make a difference or calculation between the result and the previous session ID, and finally get the public key of the client. After such a process, the client has the public key of the server, and the server also has the public key of the client. after having the other party's public key, the client can use the other party's public key to encrypt the data.

Anyone who has used Linux knows that when we establish a ssh remote connection with the server for the first time, there will be a confirmation asking if we should continue to connect, and we can enter the password only after we enter yes. This is why I am. 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 md5 and sha256 the received public key, extract the fingerprint of the public key, and then prompt us to say that I have received a public key whose md5 is xxx. Do you confirm this public key? If we confirm it, we believe that the public key is sent by the server, so that we can do an XOR operation between our public key and the session ID, and encrypt the result with the public key we just received. We imagine that if it is not the public key sent by the server, but the public key sent by the hacker, if we confirm it, after the subsequent ciphertext hackers get it, the hacker will decrypt it with his own private key and get 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 data sent by the real client. This is called a man-in-the-middle attack, which uses its own public key to impersonate server and client roles back and forth.

After learning about the process of encrypted communication and key exchange in ssh, let's take a look at the process of login authentication based on user name, password and key in ssh.

Login based on username and password is a process like this: first, the client initiates a ssh connection request, and the server sends its own public key to the client. After receiving the public key of the server, the client sends the password to the server after being encrypted by the public key of the server. The server receives the encrypted password and decrypts it with its own private key to get the password sent by the client, and then it uses the password for authentication. The result of authentication is encrypted with the public key of the client and sent to the client. After receiving the result, the client decrypts it with its own private key, thus realizing the authentication process. If the authentication is passed, then the client logs in successfully, otherwise the client login fails.

The process of key-based login authentication is as follows: first, the client needs to generate a pair of key pairs (this key pair is for the user, not the public and private keys of the host, all of which are the public and private keys of the host), and manually add the generated public key to the server (the. Ssh/authorized_keys added to a user's home directory of the server by default, and we need to use that user to connect to the server. Add the public key to the. ssh/authorized_keys file of that user's home directory). After the server has the client user's public key, when the client initiates the ssh connection request, the server will generate a string of random characters, encrypt the 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 decrypt it with its own private key, and then send the decrypted random characters to the server. After the server receives the random characters sent by the client, it will make a comparison. If it is the same as the random characters sent before, then the server allows password-free login.

Through the above introduction, it is not difficult to find that if we want to authenticate login based on key, we must generate a user key pair on the client side, and put the generated user public key in the server user's home directory. Ssh/authorized_keys file, this user is the user we will use for key authentication login server in the future. Next, let's try it.

1. Generate user key pairs on the client side

[qiuhom@docker] $ssh-keygen-t rsaGenerating 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@dockerThe key's randomart image is:+--- [RSA 2048]-+ |. + = | | + o+ | | + + oo..o. | | Bo=.o=.o.. | | | + *. + o..oS | |. e.。 B.This. | |. +% o. | |. = ostensible. | |.. + 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[ docker ~] $

Description: in Linux, we use the ssh-keygen command to generate a user key pair, and the-t option indicates which encryption algorithm is used to produce the key. The generated key pair is placed in the current user's home directory by default under .ssh / directory, called id_rsa and id_rsa.pub, respectively. From the name, we can know that id_rsa is the private key and id_rsa.pub is the public key. If you are careful, you must see that we use ssh-keygen to generate the key. It will ask us where we need to store the key file under the .ssh directory under the current user's home directory by default. Of course, we can also use the-f option to specify the storage location. In addition, it also allows us to enter the password. The password here represents the password of the encrypted private key, and we all know that it is very dangerous to get the other party's private key. So the system will prompt us by default that if you press enter, the generated private key is not encrypted, of course, we can also use the-P (uppercase) option to specify the password of the encrypted private key.

two。 Put the user-generated public key in the user's home directory of the server. ssh/authorized_keys, we can use the scp command to put it to the server, or we can copy it through the USB disk, 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's home directory on the server side.

[qiuhom@docker ~] $ssh-copy-id-I. ssh / id_rsa.pub root@192.168.0.151/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 keysroot@192.168.0.151's password: Number of key (s) added: 1 Now try logging into the machine, with: "ssh 'root@192.168.0.151'" and check to make sure that only the key (s) you wanted were added. [qiuhom@docker ~] $

Note: the-I option specifies the location of the public key file, which defaults to the name of the .ssh / public key file under the current user's home directory. Because before we copy the public key, the server does not have the client user's public key, so when we copy the user's public key, we also need to enter the password for authentication. It should be noted here that the sshd service on the above experimental server 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 done ssh password-free login verification based on key.

The above key generation and distribution are based on manual, so there is no problem with one or two servers, but if there are more servers, what should we do? If we need to manage many servers, we need to write a script to complete it. The following script is provided to automatically generate the key and send it to the designated host.

[qiuhom@docker ~] $cat sshh keygen.shroud cards Bash remote_host_ip=$1remote_host_user=$2remote_host_port=$3remote_host_passwd=$4local_rsa_file=~/.ssh/id_rsalocal_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

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.