1. Version negotiation phase
1.
The server opens port
22
and waits for the client to connect;
2. The client initiates a
TCP initial connection request
to the server . After the
TCP connection is established, the server sends the first message to the client, including the version flag string. The format is "SSH-< primary protocol version number >.< secondary protocol Version number >.< software version number >" , the protocol version number is composed of major version number and minor version number, and the software version number is mainly used for debugging.
3.
After receiving the message, the client parses the data packet. If the server’s protocol version number is lower than its own, and the client can support the server’s lower version, it uses the server’s lower version protocol number, otherwise uses its own protocol version number.
4.
The client responds to the server with a message, including the protocol version number that the client decides to use. The server compares the version number sent by the client to determine whether it can work with the client. If the negotiation is successful, enter the phase of key and algorithm negotiation; otherwise, the server disconnects the TCP connection.
Note: The above messages are all transmitted in plain text.
2. Key and algorithm negotiation phase
1.
The server and the client send algorithm negotiation messages to the peer respectively. The messages contain the list of public key algorithms and encryption algorithms they support.
table,
MAC
(
Message Authentication Code
, message authentication code) algorithm list, compression algorithm list, etc.
2.
The server end and the client end obtain the final used algorithm according to the list of algorithms supported by the peer end and the local end.
3.
The server and client use
the DH
exchange (
Diffie-Hellman Exchange
) algorithm, host key pair and other parameters to generate session key and session ID
. Thus, the server and the client get the same session key and session ID
. For subsequent data transmission, both ends will use the session key to encrypt and decrypt, ensuring the security of data transmission. During the authentication phase, both ends use sessions for the authentication process.
Generation of session key
:
1.
The client needs to use an appropriate client program to request to connect to the server, and the server sends the server's public key to the client. (The server’s public key generation process: every
time the server starts the sshd service, the service will take the initiative to find the
/etc/ssh/ssh_host*
file. If the system has just been installed, since there are no these public key files, sshd
will take the initiative to calculate These required public key files will be calculated, and the private key files required by the server will also be calculated.)
2.
The server generates a session
ID
and sends the session
ID
to the client.
3.
If the client connects to the server for the first time, the server's public key data will be recorded in the client's user home directory.
~/.ssh/known_hosts
. If the public key data of the server has been recorded, the client will compare the received data with the
Whether there is a discrepancy with the previous record. The client generates a session key, encrypts it with the server's public key, and sends it to the server.
4.
The server decrypts the received data with its own private key to obtain the session key.
5.
Both the server and the client know the session key, and future transmissions will be encrypted by the session key.
3. Certification stage
SSH
provides two authentication methods:
Password-based authentication (
password
authentication
): the client sends a
password
authentication request to the server, and the user name and password
After encryption, it is sent to the server, and the server decrypts the information to obtain the plaintext of the user name and password, which is the same as the user name and password stored on the device.
Passwords are compared and an authentication success or failure message is returned.
Key-based authentication (
publickey
authentication)
: the client generates a pair of public keys and saves the public key to the server to be logged in
In the
.ssh/authorized_keys file
of the home directory of the account above .
Authentication phase: the client first passes the public key to the server
end. After the server receives the public key, it will
compare it with the public key in
authorized_keys in the local account's home directory.
If they are the same, the authentication fails; otherwise, the server generates a random string and encrypts it with the client public key and session key successively.
sent to the client. After receiving it, the client sends the decrypted random character string to the server with the session key. If the string sent back
If it is the same as that generated by the server before, the authentication is passed; otherwise, the authentication fails.
Note
: The server authenticates the client, if the authentication fails, it sends an authentication failure message to the client, which includes
List of authentication methods. The client selects an authentication method from the authentication method list to re-authenticate, and this process is repeated.
Until the authentication is successful or the number of authentications reaches the upper limit, the server closes the connection
Two hosts realize password-free login
Server:
1. Modify the ssh configuration file
client:
(1) Generate a key pair
Send the public key to the server host to be connected
Test the client host to log in to the server host