This article introduces you to SSH

SSH is what

Secure Shell (SSH) is an encrypted network transport protocol that provides a Secure transport environment for network services on insecure networks.

— Wikipedia

As wikipedia explains, SSH is actually an encrypted network transport protocol, and the SSH command we use to log in to remote hosts is actually a software wrapper implementation of SSH. The most common open source implementation is OpenSSH (OpenBSD Secure Shell).

SSH is relatively reliable at present. SSH can effectively prevent information leakage during remote management. SSH can be used to encrypt all transmitted data and prevent DNS and IP spoofing. Another advantage of SSH is that the data it transmits can be compressed, so it speeds up transmission.

SSH currently has two versions, SSHv1 and SSHv2. V2 is the mainstream version and V1 has security risks caused by man-in-the-middle attacks.

The basic flow

The communication flow specified by SSH can be divided into the following phases:

1. SSH version negotiation phase
2. Key and algorithm negotiation phase
3. Client authentication phase
4. Session request phase
5. Interactive session stage

SSH version negotiation phase

1. The server opens the service port (22 by default) and waits for the client to connect.
2. The client initiates a TCP connection to the server, and the handshake is complete.
3. The server sends a packet containing SSH version information to the client over a TCP connection.
4. After receiving the packet, the client compares the version of the packet with its own version:
   1. If the packet version is earlier than its own version but compatible with its own version, the packet version is used for communication.
   2. In other cases, use its own version for communication;
5. The client will send the version number to the server through TCP connection, and the server will judge whether to support:
   1. Enter the key and algorithm negotiation phase.
   2. If the SSH connection is not supported, the request will be interrupted.

Key and algorithm negotiation phase

1. The server and client send algorithm negotiation packets to the peer end over the TCP connection. The packets contain the list of supported public key algorithms, encryption algorithms, MAC algorithms, and compression algorithms.
2. Similar to the protocol version negotiation phase, the server and client decide the final algorithm to be used based on the algorithm supported by themselves and the peer.
3. The server and client use diffie-Hellman key exchange using the algorithm, the host key peer parameter, to generate the shared key and the session ID;
4. The encrypted SSH communication channel is established. In subsequent communication, the shared key is used to encrypt and decrypt transmitted data, and the session ID is used for authentication.

Diffie-hellman algorithm

The DH algorithm can establish a secure connection on an insecure channel to resolve the problem of secure information exchange on an insecure channel.

Assume that A and B use the DH algorithm to securely exchange information over an insecure channel. The process is as follows:

1. A and B choose A prime number P and its original root G through negotiation;
2. A generates A random number A ∈[1,p−1] A \in [1, P-1] A ∈[1, P −1] and calculates YA=gamodpY_{A} = G ^{A} mod pYA= GAModp
3. B generates a random number B ∈[1,p−1] B \in [1, P-1] B ∈[1, P −1] and calculates YB=gbmodpY_{B} = G ^{B} mod pYB= GBmodp
4. Both parties exchange their generated YYY;
5. K=YBamodpK = Y_{B}^{A} modpK =YBamodp;
6. K=YAbmodpK = Y_{A}^{B} modpK =YAbmodp;
7. After the above process, BOTH A and B obtain the secure shared key KKK.

Note 1: Mathematical knowledge in the process is not popularized here, because the blogger himself is not very familiar with it. Note 2: This is only a rough explanation of the principle, not the best implementation process;

The algorithm is established for the following reasons: In this method, the public data are P, G, YA, YBp, G, Y_{A}, Y_{B} P, G, YA, YB, if you want to calculate KKK through public data, YA= GAModp ∣YB=gbmodpY_{A} = G ^{A} modp \mid Y_{B} = G ^{B} mod pYA=gamodp∣YB= GBmodp The time complexity is O(p)O(p)O(p), as long as P is large enough to ensure that this method can meet the requirements of computer security.

How to use the Diffie-Hellman algorithm for SSH

Due to the limited technology of bloggers, TCP packets of this process are not screened out. Therefore, the general implementation process of Diffie-Hellman-group-exchange-SHA256 is given by referring to the third reference article:

1. The client sends a PACKET over a TCP connection to notify the server to start the DH switching process.
2. The server sends the selected P and G to the client (refer to the previous section for meanings).
3. After receiving P and G, the client generates its own Y-client and returns the y-client to the server.
4. After the server receives the y-client:
   1. The key K is obtained by calculation;
   2. Use SHA256 algorithm to encrypt some known information to H-server and sign it with RSA;
   3. Send the rsa public key, Y-server, and H-server after rsa signature to the client.
5. The client receives the return value from the server:
   1. Calculate the same key K;
   2. Sha256 algorithm is also used to encrypt the same information to the H-client;
   3. Rsa server public key is used to obtain h-client signature and h-server signature is compared.
   4. If the check is correct and a specific packet is returned, the key exchange is complete and all data is encrypted with the key.

Calculation method of H: H=hash(VC/parallel VS/IC/IS/KS/YC/YS/K)H =hash(VC \parallel VS/parallel IC/parallel IS/parallel IS/parallel YC/parallel YS / \ parallel K) H = hash (VC ∥ VS ∥ IC ∥ IS ∥ KS ∥ YC ∥ YS ∥ K)

The above contents are concatenated in sequence without inclusion or trailing redundant characters. The result of the concatenated string is calculated by SHA256, H is session_ID. Only H generated during the first key exchange of a session is session_ID. The session_ID does not change during subsequent key exchange.

AES algorithm is generally used for subsequent communication encryption. Key calculation method: Hash (K/H/W/session− ID)hash(K/parallel H/parallel W/Session − ID)hash(K/parallel H/parallel W/session− ID), where W refers to a single uppercase ASCII letter, Different encryption keys are computed using different characters.

If we want the secret key to be longer than RE, then we add a value to the RE: hash(K∥H∥RE)hash(K \parallel H∥RE)hash(K ∥H∥RE) becomes an extended RE. If this is not enough, the sum is continued using the same method.

Note 1: The blogger expressed doubt about the occurrence of H and session-id in the calculation formula of the secret key, but did not find more information, so I wrote this for the time being. If there is any discrepancy between the specific implementation and the content given, I hope you can kindly comment and contact the blogger for modification as soon as possible.

Extension: SSH why use diffie-Hellman algorithm

My understanding of SSH negotiation is as follows:

1. A uses the RSA algorithm to generate public key A and private key A. B generates public key B and private key B.
2. User A sends public key A to user B.
3. B sends public key B to A.
4. During subsequent communication, A encrypts the content with public key B and sends it to B. User B uses public key A to encrypt the content and sends it to user A.

My confusion is as follows: Many documents mention Diffie-Hellman (DH) in the explanation of SSH communication negotiation between two hosts in Linux. I know DH is a key exchange algorithm, which enables the communication parties to safely generate a public key (symmetric key). After the negotiation, A and B can use the public and private keys generated by the RSA algorithm to encrypt communication. Why is the DH algorithm needed? Is this process followed by a DH algorithm to regenerate a public key?

Question: Why does SSH use Diffie-Hellman Exchange (DH)?

The first thing to point out is that the author’s understanding of SSH negotiation is wrong.

As for why RSA is not used to encrypt communication, it is similar to HTTS: RSA is an asymmetric encryption algorithm. It consumes a lot of resources and has low running efficiency. Therefore, RSA is not suitable for data exchange encryption over long connections.

If you want to read more about this question, it is recommended to click here to see the answer to the sixth reference article.

Client authentication phase

1. The client sends an authentication request to the server.
2. The server authenticates the client. If the authentication fails, it sends a failure message to the client.
3. The client can choose to re-authenticate to know the number of times the authentication has gone online (if set) or the location of the authentication success.

There are two common client authentication modes

1. Password authentication: The password used for password authentication is the same as the password of a system user.
2. Key authentication: The public key is generally stored in the user directory~/.ssh/authorized_keysThe SSH server must have the permission to access the file.

Session request phase

1. The server waits for a client request;
2. After the authentication is complete, the client sends a session request to the server.
3. The server processes the client request:
   1. After that, a SSH_SMSG_SUCCESS message is sent to the client. The two parties enter the interactive session.
   2. If the request is not successfully processed, the SSH_SMSG_FAILURE packet is returned, indicating that the request fails to be processed or the client request cannot be recognized.

Interactive session stage

1. The command to be executed by the client is encrypted and sent to the server.
2. After receiving the decryption command, the server encrypts the result and returns it to the client.
3. The client decrypts the result and displays it on the terminal.

OpenSSH

OpenSSH first appeared in OpenBSD 2.6 in October 1999 as a project to replace the SSH software provided by SSH Communications Security.

— Wikipedia

The program mainly includes several parts:

1. SSH: SSH client implementation
2. SCP, SFTP: An alternative to RCP that copies files to other computers
3. SSHD: indicates the implementation of SSH server
4. Ssh-keygen: generates an RSA or ECDSA key for authentication
5. Ssh-agent, ssh-add: helps users not enter the key or password every time
6. Ssh-keysacn: collects SSH host public keys of a large number of hosts

ssh-keygen

Common options:

SSH to agent and SSH to add

Ssh-agent is a tool developed by OpenSSH to provide SSH agents for users. It can provide agents for other programs that need to use SSH keys.

Ssh-add is used to work with the ssh-agent. You can use this tool to add private keys to the ssh-Agent.

To view the list of added private keys, run the ssh-add-l command.

reference

1. How SSH works
2. Run wind: Linux SSH connection process analysis
3. WCHRT: SSH key exchange details and implementation…
4. Yue Half brother: Diffie – Hellman key negotiation algorithm details
5. Soulike: Diffie-Hellman key exchange algorithm and its security
6. Che Xiaopang answered: SSH why use diffie-Hellman Exchange (DH)?
7. Kunge playing CSDN: Introduction to the ssh-keygen command