[Jiwang] Detailed explanation of SSH protocol

1. Concept introduction

SSH (Secure Shell), Secure Shell Protocol , is a security protocol based on the application layer. By encrypting and verifying passwords, it can provide a secure transmission environment for network services in unsafe networks and realize SSH client The connection between the client and the SSH server, so SSH is based on the client-server model.

2. Function

By using SSH, all transmitted data can be encrypted, so that "man-in-the-middle" attacks are impossible, and DNS spoofing and IP spoofing are also possible. Another advantage is that the transmitted data is compressed, so the transmission speed can be accelerated.

SSH has many functions. It can not only replace Telnet, but also provide a secure "channel" for FTP, Pop, and even PPP.

3. Service composition

The SSH service consists of the server software OpenSSH and the connection client (SSH, SecureCRT, xshell, etc.). The default port is 22. SSH is a daemon process that is responsible for monitoring client requests in real time and processing them.

4. Framework composition

There are three main protocols in the SSH protocol framework: transport layer protocol, user authentication protocol, and connection protocol.

1. The Transport Layer Protocol: Provides support for server authentication, data security, information integrity and other functions.
2. The Authentication Protocol : Provides the server with identification of the client's identity.
3. The Connection Protocol : multiplexes the encrypted information tunnel into several logical channels and provides them to higher-level application protocols; various high-level application protocols can be relatively independent of the SSH basic system, and then rely on this basic system. Framework that uses SSH's security mechanisms through the connection protocol.
   

5. Workflow

1. During the version number negotiation phase,
   SSH currently includes two versions: SSH1 and SSH2. The two parties will actually use the version through version negotiation.
   (1) The server opens port 22 and waits for the client to initiate a connection request.
   (2) The client initiates a TCP initial connection request to the server. After establishment, the server sends a message to the client (version flag string: SSH-<main protocol version number>.<secondary protocol version number>-<software version Number>)
   (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 will use the server's lower version protocol number, otherwise it will use the client's The client's own protocol version number.
   (4) The client responds to the server with a message containing the protocol version number that the client decides to use. The server will compare the version number sent by the client to decide whether to work normally with the client.
   (5) If the negotiation is successful, it will enter the key and algorithm negotiation stage, otherwise the server will disconnect the TCP connection.

Note: Messages during the version number negotiation phase are transmitted in clear text.

2. During the key and algorithm negotiation phase,
   SSH supports multiple encryption algorithms. The two parties negotiate the final algorithm based on the algorithms supported by the server and client.

(1) The server and the client send algorithm negotiation messages to each other respectively. The messages include the public key algorithm list, encryption algorithm list, MAC (Message Authentication Code, message verification code) algorithm list, compression algorithm list, etc. they support. Negotiate information.
(2) The server and the client determine the final algorithm to be used based on the algorithm lists supported by each other and themselves.
The server and client use the DH (Diffie-Hellmenan Exchange) algorithm and host key parity parameters to generate a session key and session ID, and then both parties get the same session ID and session key.
(3) For subsequent data communication, both ends will use session keys for encryption and decryption to ensure the security of data transmission.

Note: Before the negotiation phase, the server has already generated an RSA or DSA key pair, which is mainly used to participate in the generation of session keys.

3. In the authentication phase
   , the SSH client initiates an authentication request to the server, and the server authenticates the client.

(1) The client sends an authentication request to the server. The authentication request information includes the user name, authentication method, and content related to the authentication method (for example, during password authentication, the content is the password).
The server authenticates the client. If the authentication fails, it will send an authentication failure message to the client, which also contains a list of methods by which authentication can be initiated again.
(2) The client selects an authentication method from the authentication method list returned by the server to authenticate again.
(3) This process is repeated until the authentication is successful or the number of authentications reaches the upper limit and the server closes the connection.

4. Session request phase
   After passing the authentication, the client sends a session request to the server.

(1) The server waits for the client's request
(2) After the authentication is passed, the client sends a session request to the server
(3) The server processes the client's request. After the request is successfully processed, the server will respond to the client with an SSH_SSMG_SUCCESS packet, and SSH enters the interaction The reply phase; otherwise, the SSH_SSMG_FAILURE packet is responded to, indicating that the server failed to process the request or cannot recognize the request.

5. Interactive session stage:
   After the session request passes, the server and client can exchange information.

(1) The client encrypts the command to be executed and transmits
it to the server (2) The server receives the message, decrypts it and executes the command, and encrypts the execution result and sends it back to the client
(3) The client decrypts the received result and then displayed on the terminal

Note: At the current stage, data can be transmitted in both directions.

6. Authentication method

1. password authentication

   The client sends a password authentication request to the server, then encrypts the username and password and sends them to the server; the server decrypts the information and obtains the clear text of the username and password. Compare it with the username and password saved on your device, and return a message indicating success or failure of authentication.

2. publickey authentication

   Use digital signatures to authenticate clients. Currently, two public key algorithms, RSA and DSA, can be used to implement digital signatures on the device.

   The client sends a publickey authentication request containing the user name, public key and public key algorithm to the server. The server checks the validity of the public key and directly sends a failure message if it is not valid; otherwise, the server uses a digital signature to authenticate the client and returns a message indicating success or failure of the authentication.

SSH key authentication login process:

(1) Before making an SSH connection, the SSH client needs to generate its own public key and private key pair and store its own public key on the SSH server.
(2) When the SSH client sends a login request, the SSH server will locally search for the client's public key based on the user name and other information in the request, and use this public key to encrypt a random number and send it to the client.
(3) The client uses its own private key to decrypt the returned information and sends it to the server.
(4) The server verifies whether the information decrypted by the client is correct. If correct, the authentication passes.

Since the SSH protocol is oriented to mutual access and information exchange between hosts in the Internet network, the host key becomes the basic key mechanism. In other words, the SSH protocol requires that each host using this protocol must have at least one host key pair of its own. The server can only allow its connection request after passing the authentication of the client's host key. A host can use multiple keys and have different keys for different key algorithms, but at least one is necessary, that is, the key generated by the DSS algorithm.

There are two management schemes for host key authentication in the SSH protocol, as shown in the figure below:

Scheme 1

Scheme 2

Each host must have its own host key. There can be multiple pairs of keys. Each host key pair includes a public key and a private key. How are these keys used in practical applications and relied on to implement security features? As shown in the figure above, two solutions are proposed in the SSH protocol framework.

In the first scheme, the host distributes its public key to the relevant clients. When the client accesses the host, it uses the host's public key to encrypt the data, and the host uses its own private key to decrypt the data. , thereby realizing host key authentication and determining the reliable identity of the client. As can be seen in Figure 2(a), the user initiates an operation from host A to access host B and host C. At this time, A becomes the client, and it must configure the public keys of host B and host C in advance. When accessing, the corresponding public key is found according to the host name. For the visited host (that is, the server), it only needs to ensure that its private key is stored securely.

In the second solution, there is a key certification center, and all hosts that provide services in the system submit their public keys to the certification center, and any host that is a client only needs to save a copy of the certification center's public key. Just click the key. In this mode, before accessing the server host, the client must also request authentication from the key authentication center. Only after authentication can it correctly connect to the destination host.

Obviously, the first method is easier to implement, but the client's key maintenance is a troublesome thing, because every change must be reflected on the client; the second method perfectly solves the management and maintenance problem, however Such a model places high demands on the certification center. To achieve such centralized certification on the Internet, it is a big trouble just to confirm the authority. Who can have the final say on everything? However, from a long-term development perspective, in the fields of enterprise applications and commercial applications, it is necessary to adopt a central certification solution.

In addition, the SSH protocol framework also allows a compromise for the host key, that is, no authentication is required for the first access. Authentication-free for first access means that when a client accesses the host for the first time, the host does not check the host key, but issues a copy of the public key to the client, so that the key must be used in subsequent visits. , otherwise it will be considered illegal and access will be denied.

3. Password+publickey authentication (SSH2.0)
   specifies that the user's authentication method is password+publickey authentication, which must be met at the same time.

   Note: Users with client version SSH1 can log in as long as they pass one of the authentications; users with client version SSH2 must pass both authentications before they can log in.

4. any authentication
   Specifies that the user's authentication method can be either password or publickey.

7. Commonly used commands

1. Remote login
   ssh username@remote host IP: You need to download the other party's public key when logging in for the first time.
   Example: ssh [email protected]

2. Remote upload
   scp [local location where the file needs to be uploaded] root@remote host ip: [need to be saved on the remote host morning path]: Upload files from the local to the remote host.
   Example: scp /root/test.sh [email protected]

3. Remote copy
   scp root@remote host ip:[remote host file absolute path][local location to be saved]: Download files from the remote host to the local machine.
   Example: scp [email protected]:/root/test.sh /root