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

This article gives you a detailed introduction to the ssh key login process and matters needing attention to the remote server. The following are the details:

Key login is more secure than password login, mainly because it uses asymmetric encryption and key pairs are needed in the login process. The whole login process is as follows:

The remote server holds the public key, and when a user logs in, the server randomly generates a string and sends it to the user who is logging in.

The user receives the string from the remote server, encrypts the string with the private key paired with the public key of the remote server, and then sends it to the remote server.

The server uses the public key to decrypt the encrypted string sent by the user, and the resulting decrypted string is judged to be successful if it is the same as the random string sent to the client in the first step.

The whole login process is that simple, but you will encounter some small details in the actual use of ssh login. Here is a demonstration of ssh remote login to show these details.

Generate key pair

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

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

Executing ssh-keygen will prompt the user to enter the name of the generated private key at # 1. If left empty, the default private key will be saved in the / home/jaychen/.ssh/id_rsa file. Here are two points to pay attention to:

The generated key is placed in the .ssh folder under the home directory of the user who executed the ssh-keygen command. Under the $HOME/.ssh/ directory.

The file name of the generated public key, usually the file name of the private key followed by the suffix .pub.

At # 2, prompt for the password. Note that the password here is used to ensure the security of the private key. If you fill in the password, you will be asked to enter the password when you log in with the key, which ensures that if the private key is lost, it will not be used maliciously. That's what I say, but I just skip it when I use it here.

# 3 is to repeat the password entered by # 2, so there is no nonsense here.

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

➜.ssh lstotal 16Kdrwx-2 jaychen jaychen 4.0K December 7 17:57. Drwx-9 jaychen jaychen 4.0K December 7 18:14.-rw- 1 jaychen jaychen 1.7K December 7 17:57 id_rsa.github-rw-r--r-- 1 jaychen jaychen 390 December 7 17:57 id_rsa.github.pub

One more thing to note about the generated private key: the permission of the private key should be rw-,. If the permission of the private key is too large, it will become insecure if anyone can read and write the private key. The ssh login will fail.

Ssh login for the first time

The command to log in to the remote server is

Ssh login user @ server ip

Start by paying attention to the concepts of two users:

The user who executes this command locally, that is, the currently logged in user, the user name I demonstrate here is jaychen.

The user to log in to the remote server.

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

The contents of the public key should be saved to the .ssh / authorized_keys file in the home directory of the user to be logged in. Suppose you later log in to the remote server using the root user, then 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 public key separated by a newline.

After uploading, execute

Ssh root@ remote server ip

At this point, as mentioned above, the remote server sends back a random string, which needs to be encrypted with a private key. The private key reads the private key file in the .ssh directory under the home directory of the user who executed the command. The default private key file is the id_rsa file. This is the $HOME/.ssh/id_rsa file. Assuming that the private key is encrypted when the key is generated, you need to enter a password at this time.

Users will not be aware of the above process when logging in. Ssh completes all the verification operations behind. If the keys match, the user can log in directly to the remote server, but if it is the first time to log in, there will be a prompt similar to the following:

➜.ssh ssh root@192.168.1.1The 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)?

This means that the real identity of the remote server cannot be verified, only knowing that the public key fingerprint (the MD5 value of the public key) is 61U/SJ4n/QdR7oKT2gaHNuGxhx98saqMfzJnzA1XFZg, and whether a connection is really needed. The above hint appears to avoid man-in-the-middle attacks.

Man in the middle attack

The premise of a man-in-the-middle attack is that you log in to a remote server for the first time and know nothing about the remote server except the user name, the public and private key corresponding to the user name, and the server ip. Suppose you ssh remotely log in to the remote host of 192.168.1.1 and are intercepted by a third party during the connection, and the third party pretends to be the host of 192.168.1.1, then you will connect directly to someone else's server. This is man-in-the-middle attack.

In order to avoid man-in-the-middle attack, ssh will return the public key fingerprint when logging in for the first time, and users need to manually compare the public key fingerprint of the public key of the remote server you want to log in to is the same as the public key fingerprint returned by ssh.

After comparing the public key fingerprint, confirm that the server is the server you want to log in to, and you can log in successfully after typing yes. The entire login process is over.

Known_hosts file

After the first login, a known_hosts file is generated in the local $HOME/.ssh/ directory, similar to the following

➜.ssh cat known_hosts192.168.1.1 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOPKYWolOYTDevvBR6GV0rFcI0z/DHZizN5l/ajApsgx+UcOOh61liuyBRRCIyF+BR56Le0lP0Pn6nzvLjbqMqg=

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

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 a set of private keys, and different servers should use different private keys. But as we can see from the connection process above, ssh defaults to reading the $HOME/.ssh/id_rsa file to log in as the private key. If you want different servers to log in with different private keys, you need to write a config file in the .ssh directory to configure it.

The configuration of config is simple, as long as you indicate which user needs to use which private key to log on to which remote server. A configuration example is given below.

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

The fields of the above config file are as follows:

Host indicates the ip of the remote host. In addition to using the ip address, you can also use the URL directly.

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

IdentityFile indicates which private key file to use.

After writing the config file, you need to change the permissions of the config file to rw-r--r--. If the permission is too large, ssh will disable login.

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.