Detail the linux SSH login process

This article gives you a detailed introduction to the ssh key login remote server process and precautions. Here are the details:

Key login is more secure than password login, mainly because it USES asymmetric encryption and requires key pairs during the login process. The whole login process is as follows:

The remote server holds the public key. When a user logs in, the server generates a random string and sends it to the logged in user.
The user receives the string from the remote server, encrypts the string using the private key paired with the public key of the remote server, and sends it to the remote server.
The server USES the public key to decrypt the encrypted string sent by the user. If the decrypted string is the same as the random string sent to the client in step 1, it will be judged as successful login.
The login process is as simple as that, but there are a few minor details that can be encountered when actually using ssh to log in, and here is a demo of ssh remote login to demonstrate these details.

Generate key pairs

Using ES16en-ES17en, you can directly generate the key pairs needed for login. ssh-keygen is a command under Linux that generates key pairs without adding any parameters.

➜ ~ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jaychen/.ssh/id_rsa): #1
Enter passphrase (empty for no passphrase):      #2
Enter same passphrase again:          #3

Perform ssh - keygen will appear as above, in the # 1 place here to prompt the user for generating the name of a private key, if not fill in, the default private key stored in the/home jaychen /. ssh/id_rsa file. There are two caveats here:

The generated key is placed in the.ssh folder in the home directory of the user who executes the ES33en-ES34en command. HOME/.ssh /.

The filename of the generated public key, usually the.pub suffix after the filename of the private key.

At #2, you are prompted for a password. Note that the password is used to secure the private key. If you fill in the password, you will be asked to enter it when logging in using the key, thus ensuring that if the private key is lost it will not be used maliciously. That's what I'm saying, but I'm just going to skip over it when I use it.

#3 is a repeat of #2, so I'm not going to make any nonsense of it.

Once the key is generated, you can see the two files under /home/jaychen/.ssh/(I put it under /home/jaychen because I use the jaychen user to execute the ES55en-ES56en command)

➜ .ssh ls
total 16K
drwx------ 2 jaychen jaychen 4.0K 12 month  7 17:57 .
drwx------ 9 jaychen jaychen 4.0K 12 month  7 18:14 ..
-rw------- 1 jaychen jaychen 1.7K 12 month  7 17:57 id_rsa.github
-rw-r--r-- 1 jaychen jaychen 390 12 month  7 17:57 id_rsa.github.pub

One more thing to note about the generated private key: the permissions of the private key should be rw. If the permissions of the private key are too large, the private key will be unsafe for anyone to read or write. ssh login fails.

First ssh login

The command to log in to the remote server is

ssh Login user @server ip

Here are two user concepts to start with:

The user executing this command locally is the current logged-in user, whose name I'm demonstrating here is jaychen.

The user who wants to log in to the remote server.

Before we start logging in, we first need to upload the generated public key to the server.

The contents of the public key are saved to the.ssh /authorized_keys file in the home directory of the user to be logged in. Assuming you later want to log in to the remote server using root user, the contents of the public key should be saved in /root/.ssh /authorized_keys. Note that the authorized_keys file can hold multiple public key information, each separated by a newline.

After uploading, execute

ssh ES103en@remote server ip

At this point, as mentioned above, the remote server will send back 1 random string, and this time the string will be encrypted using the private key. The private key goes to the.ssh directory in the home directory of the user executing the command to read the private key file, which is the default private key file of id_rsa. That is the $HOME/.ssh /id_rsa file. Assuming that the private key is encrypted when the key is generated, a password is required.

The above process will not be aware when the user logs in. ssh completes all the verification operations behind the scenes. If the key matches, the user can directly log in to the remote server.

➜ .ssh ssh root@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ECDSA key fingerprint is SHA256:61U/SJ4n/QdR7oKT2gaHNuGxhx98saqMfzJnzA1XFZg.
Are you sure you want to continue connecting (yes/no)?

The meaning of this sentence is that the remote server's true identity cannot check, only know that the public key fingerprint (public key MD5 value) of 61 U/SJ4n/QdR7oKT2gaHNuGxhx98saqMfzJnzA1XFZg, really want to establish a connection. The above tip appears to avoid man-in-the-middle attacks.

Man-in-the-middle attack

The premise of a man-in-the-middle attack is that the first time you log in to a remote server, you know nothing about the remote server except the username, the public key corresponding to the username, and the server ip. If you ssh remotely logged into the 192.168.1.1 remote host and were intercepted during the connection, the third person pretended to be the 192.168.1.1 remote host, then you would directly connect to someone else's server. This is the man-in-the-middle attack.

To avoid man-in-the-middle attacks, ssh returns a public key fingerprint on the first login, and the user has to manually compare the public key fingerprint of the remote server to that of ssh.

After comparing the public key fingerprint, confirm that this server is the server you want to log in to. Enter yes to log in successfully. The whole login process ends.

known_hosts file

After the first login, an known_hosts file is generated in the $HOME/.ssh/directory on the native machine, which looks like the following

➜ .ssh cat known_hosts
192.168.1.1 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOPKYWolOYTDevvBR6GV0rFcI0z/DHZizN5l/ajApsgx+UcOOh51liuyBRRCIyF+BR56Le0lP0Pn6nzvLjbqMqg=

This file records the public key fingerprint of the remote host ip and the remote host, so on the next login, the public key fingerprint sent by the remote host can be directly compared with the public key fingerprint of the corresponding ip in the FILE known_hosts.

config configuration

In many cases, we may need to connect to multiple remote servers and configure the private key of the git server. So many servers cannot share one set of private keys, different servers should use different private keys. But as we can see from the connection flow above, ssh defaults to reading the $HOME/.ssh /id_rsa file to log in as a private key. If you want different servers to log in with different private keys, you need to write the config file in the.ssh directory to configure it.

The CONFIGURATION of config is as simple as specifying which user to log in to which remote server needs to use which private key. An example configuration is shown below.

Host github.com
 User jaychen
 IdentityFile ~/.ssh/id_rsa.github
Host 192.168.1.1
 User ubuntu
 IdentityFile ~/.ssh/id_rsa.xxx

The config file field above has the following meanings:

Host specifies the ip for the remote host. In addition to using the ip address, you can also use the web address directly.

User refers to a user who logs on to a remote host.

IdentityFile specifies which private key file to use.

After writing the config file, you need to change the permissions of the config file to ES201en-ES202en --r--. ssh will disable logins if permissions are too high.