SSH Login Authentication Process detailed

Authentication principle: SSH Login has 2 types of authentication methods:Authentication methods based on account and password based on public key and private key the login process for SSH is divided into 5 stages:Version number negotiation phase key and algorithm negotiation phase authentication phase Session request Phase Session interaction phase 1. Version number negotiation phase

The server opens port 22, waiting for the client to connect.

The client initiates a TCP connection to the server, and after the connection is established, the server sends the first message to the client, including the version flag string, in the form "Protocol version number, version number, software version number".
Debug1:local Version string ssh-2.0-openssh_7.4

After the client receives the message, resolves the protocol version number, if the service side of the protocol version number is lower than its own, and the client can support the low version of the service side, use the service-side protocol number, otherwise use its own protocol version number.
Debug1:remote Protocol version 2.0, Remote software version openssh_5.3

The client replies to the service-side message, which contains the protocol version number that the client decides to use.
debug1:match:openssh_5.3 Pat openssh_5* Compat 0x0c000000

The server compares the version number sent by the client and determines whether it can interact with the client. If the negotiation succeeds, it enters the key and algorithm negotiation phase. Otherwise, the server disconnects the TCP connection. 2. Key and algorithm negotiation phase

The server and the client send the algorithm negotiation message to each other separately, including the list of public key algorithms, the list of cryptographic algorithms, the list of message verification codes and the list of compression algorithms. The end-use algorithm is derived by the server and the client based on each other and the algorithms they support. The service side and client use the DH exchange algorithm, the host key peer parameter, to generate the session key and conversation ID.

The server sends the service-side public key to the client.

The server generates the session ID, which is set to the ID and sent to the client.

The client generates a session key, sets it as key, and calculates res = ID XOR or key.

The client encrypts the RES with the service-side public key and sends the result to the server.

The server is decrypted with the service-side private key to obtain Res.

The server calculates the Res XOR ID and gets the key.

Both the server and the client are aware of the session key and conversation ID, and subsequent data transfers are encrypted and decrypted using the session key. 3. Certification Phase

After the certification begins there will be a set order such as Publickey,gssapi-keyex,gssapi-with-mic,password first with the PublicKey method that is the secret key authentication, if the key authentication through the password will not be used for authentication, Password Authentication is used if the key authentication fails.

If we want to remove the user name password login can use the secret key authentication method.

Authentication method based on account and password:

The client encrypts the account, authentication method, password, and sends the result to the server using the session key generated during the negotiation phase of the key and algorithm.

The server uses the obtained session key to decrypt the message and obtains the account number and password.

The server determines the account and password, and if it fails, sends the authentication failure message to the client, which contains a list of methods that can be re-authenticated.

The client selects a method from the authentication method list to re-authenticate.

This process is repeated until the authentication succeeds or the number of authentications is capped, and the server shuts down the TCP connection.

Authentication methods based on public and private keys:

First use the Ssh-keygen program to generate the public key id_dsa.pub and the private key ID_DSA, typically generated on the client, and then send id_dsa.pub in some way to the server. The server is placed under the. SSH directory of the account that will be telnet over.

The client uses the session key generated during the key and algorithm negotiation phase to encrypt the account, authentication method, Id_dsa.pub, and send the results to the server.

The service side uses the session key to decrypt the message, obtains the account number, id_dsa.pub. The server is located in the directory of this account. SSH directory to find the corresponding public key, if not found, send the failure message to the client, if found, compare the client sent over the public key and found the public key, if the content is the same, the server generates a random string, called "Challenge", The challenge is then encrypted with the found public key and then encrypted again using the session key.

The server sends this double-encrypted data to the client.

The client uses the session key to decrypt the message, and then uses ID_DSA to decrypt the data again to get the challenge.

The client uses the session key to encrypt the challenge and sends it to the server.

The server uses the session key to decrypt the message, gets a challenge, and determines whether the query is generated by itself, if not the same, sends the failed message to the client, if the same, the authentication is passed.