Introduction to The Principles of SSH Authentication

SSH is an encrypted network transmission protocol, which can provide a secure transmission environment for network services in an insecure network. SSH realizes the connection between the SSH client and server by creating a secure tunnel in the network. Although any network service can be safely transmitted through SSH, the most common use of SSH is to log in to the system remotely. People usually use SSH to transmit command line interfaces and execute commands remotely. The ssh protocol interaction process is as follows:

Alibaba Cloud Simple Application Server:  Anti COVID-19 SME Enablement Program
$300 coupon package for all new SMEs and a $500 coupon for paying customers.

SSH implements authentication by asymmetric encryption, and there are two main types:

• Password-based security verification
• Key-based security verification

The following two methods are introduced:

• Password-based security verification

It uses the automatically generated public key-private key pair to simply encrypt the network connection, and then uses password authentication to log in. The specific process is as follows:

1. The client sends a login request, ssh user@hostname
2. The server accepts the request and sends the server's public key ser_rsa.pub to the client
3. The client enters the password, and the password is encrypted with ser_rsa.pub and sent to the server (secure information transmission)
4. The server accepts the encrypted password, uses the server's private key ser_rsa to decrypt it, and matches whether the authentication password is legal (if it is legal! Successful login)

At this point, the identity authentication is passed, and then the session key is exchanged (symmetric encryption)

5. The client generates the session data encryption sess_key, encrypts it with ser_rsa.pub and transmits it to the server (session key)
6. After the server gets it, use ser_rsa to decrypt and get sess_key

Use the session key to encrypt the data passed afterwards. Note: The use of symmetric encryption is efficient.

7. Client and server use sess_key for secure transmission of session data

However, this authentication method cannot avoid "man-in-the-middle" attacks, and other servers may pretend to be the real servers.

As shown in the figure, if someone intercepts the login request, pretends to be the server and sends the forged public key to the client, it is difficult for the client 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 client and the server and uses a forged public key to obtain the user's login password. Then use this password to log in to the remote host, and the SSH security mechanism is gone.

Therefore, when logging in to the server for the first time, the following prompt will appear:

 $ ssh user@host
  The authenticity of host'host (192.168.100.1)' can't be established.
  RSA key fingerprint is 2d:37:16:58:4d:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)?

After confirming, you can log in (actually, there is no use in real life? Who would manually compare fingerprints~)
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 server, the system will recognize that its public key has been saved locally, and skip the warning part and directly prompt for the password.

• Key-based security verification

The client generates a pair of public and private keys, and stores its own public key on the server. When the client requests to log in, the server randomly generates a string and encrypts it with the client's public key. After receiving it, the client decrypts it with its own private key and sends it back. After the server receives it, the comparison is performed. If the comparison is successful, it proves that the user is authentic, and the login is directly allowed without requiring a password. This avoids "man in the middle" attacks.

In the actual transmission process, all data needs to be encrypted to ensure data transmission security, that is, a session key is also generated, and the transmission data is encrypted using the session key. The detailed process is as follows:

Ac: client public key
Bc: client private key
As: server public key
Bs: server private key

***Before authentication, the client needs to put the public key Ac on the server. ***
##Use the server's public key to exchange data, get q

1. The client sends a login request, ssh user@hostname
2. The server accepts the request and sends the server's public key As to the client
   The server generates a session ID (session id), sets it to p, and sends it to the client.
3. The client generates a session key, set it to q, and calculates r = p xor q.
  The client encrypts r with As, and sends the result to the server.
4. The server uses Bs to decrypt and obtain r.
  The server performs the operation of r xor p to obtain q.

At this point, both the server and the client know the session key q, and all subsequent transmission data will be encrypted by q.

##Use the client's public key to exchange data, confirm the identity, and avoid man-in-the-middle attacks.

5. The server generates a random number x and encrypts it with Ac to generate the result S(x), and sends it to the client
6. The client uses Bc to decrypt S(x) to get x
   The client calculates the md5 value n(q+x) of q + x, where q is the session key obtained in the previous step
   The client sends n(q+x) to the server
7. The server calculates the md5 value m(q+x) of q + x
   The server compares m(q+x) and n(q+x). If the two are the same, the authentication is successful.

At this point, the server and client are authenticated, and the session key can be used for encryption and decryption transmission

8. Client and server use q for secure transmission of session data

Risk point: In the step of placing the client public key Ac on the server, it is important to verify the source of Ac, because SSH only verifies whether the client has a private key that matches the public key, as long as the public key is accepted and the private key matches the server Will grant permission. In this case, once the public key of the malicious attacker is accepted, the system will also treat the attacker as a legitimate user.

ps: The article mentions asymmetric encryption (key pair) and symmetric encryption (session key), you need to check the information yourself to understand.