Introduction to the SSH protocol
We often use the SSH username@hostIp command to log in to our Linux server, as shown below:
We understand that SSH is used to log in, but what we want to know is, why is it possible to use SSH to log in, why is it safe to use SSH, and what is the rationale behind it? Let’s discuss these topics together.
Of course! If you have a public network accessible cloud host, log in to your cloud host and run grep SSHD.*Failed /var/log/secure. You might be surprised to see how many people are trying to log in to your cloud host.
Simply put, SSH protocol is built on the insecure network for remote security login protocol. It is a protocol family with three sub-protocols, which are:
- 1. Transport layer protocol
[SSH-TRANS]: Provides server authentication, integrity, and confidentiality functions based on the traditional TCP/IP protocol. - 2. Verify the protocol
[SSH-USERAUTH]: Authenticates client users to the server. There are two authentication modes based on the user name, password, and public key. The authentication mode is established on the transport layer protocol[SSH-TRANS]Above the law. - 3. Connection protocol
[SSH-CONNECT]: Multiplexes an encryption tunnel into logical channels. It’s built on a validation protocol.
Here is not the SSH protocol to do more detailed introduction, we can baidu. The following writing idea will first analyze the above three processes of SSH protocol by capturing packets in Wireshire, and finally discuss the problems encountered by Xiaobian in the whole learning process.
Analysis of SSH handshake process
Before moving on, a few concepts are important!
- 1.
Session key key: The key is negotiated between the client and the server through the D-H algorithm. - 2,
Public key pub key: pub key becomesServer host key server_HOST_keyforSSH-TRANSThe transport protocol is used to authenticate the server, which is basically what the client uses to authenticate the server
The following figure shows the SSH handshake process:
The following is the data packet captured by The Small editor through the Wireshire tool. Let’s analyze it step by step:
- 1. The TCP three-way handshake establishes the connection
As we all know, THE TCP protocol has a process called the three-way handshake. From the figure above, you can see that the number (647-649) is the TCP connection establishment process.
| NO. | describe | seq | Win | ACK | explain |
|---|---|---|---|---|---|
| 647 | The first handshake | 0 | 8192 | There is no | Seq = 0 indicates the sequence number of the current TCP packet on the client |
| 648 | Second handshake | 0 | 14600 | 1 | Seq = 0: indicates the sequence number of the current TCP packet on the server Ack = 1(client SEq + 1) : responds to the TCP packet at seq = 0 on the client |
| 649 | The third handshake | 1 | 65536 | 1 | Seq = 1: indicates the sequence number of the current TCP packet on the client Ack = 1(server SEq + 1), indicating that the server responds to the TCP packet whose seq = 0 |
- 2. SSH version protocol exchange
Figure 647-649 shows the SSH protocol exchange process.
| NO. | describe | explain |
|---|---|---|
| 650 | Protocol Version Negotiation | The server sends its SSH version to the client in the following format:Ssh-protoversion (version number) -softwareVersion (custom) SP(blank one, optional) Comments (comment, optional) CR(enter) LF(newline) |
| 651 | Protocol Version Negotiation | The client sends its SSH version to the server in the following format:Ssh-protoversion (version number)- SoftwareVersion (custom) SP(space one, optional) Comments (comment) LF(line feed) |
This step is nothing more than sending a byte stream in the format of SSH-protoversion-softwareVersion SP comments CR LF.
- 3. Key negotiation key
The sequence number (652-677) in the preceding figure shows the SSH version protocol exchange process.
The client and server send Key Exchange Init requests to each other to inform each other of supported encryption algorithms and MAC algorithms.
After the last negotiation success, will generate a symmetric encryption key session key and a session ID, here be especially emphasized that the key is symmetric encryption key, don’t be confused and public key, public key and the key at the beginning of the above has been emphasized the difference between the two, the public key is to authentication server to the client.
In this step, the public key is passed from the server to the client:
The session key is calculated by D-H algorithm, and will not be transmitted over the network. The difficulty of cracking it depends on the difficulty of cracking discrete logarithm, and generally it will not be cracked. Those who are interested can understand the principle of this algorithm by themselves.
Next I’ll post a data analysis of the request packet sent by Key Exchange Init
| NO. | describe | explain |
|---|---|---|
| 1 | kex_algorithms |
The key exchange algorithm, which includes our D-H algorithm, is used to generate the session key |
| 2 | server_host_key_algorithms |
The server host key algorithm can bessh-rsa,ssh-dss,ecdsa-sha2-nistp256Public key private key Public key private key public key private key public key private key public key private keyunderstanding public key private key concepts |
| 3 | encryption_algorithms_client_to_server |
Symmetric encryption algorithm, commonly used areaes128-cbc,3des-cbc |
| 4 | mac_algorithms_client_to_server |
The MAC algorithm is used to ensure data integrity |
| 5 | compression_algorithms_client_to_server |
Compression algorithm |
- 4. Certification phase
The number (678-680) in the preceding figure indicates the SSH version authentication phase.
-
1. Account and password-based authentication
The client encrypts its user name and password using the generated session key key and sends it to the server for authentication. If the authentication succeeds on the server, the response succeeds. If the authentication fails, the client re-authenticates the user name and password for a limited number of times (20 times is recommended). As for how the server is verified, it is not clear whether it is combined with the session ID xiaobian, there is a lot of debate online. Note that the user name and password are encrypted using the session key key generated in the key negotiation phase above, including the data transmitted in the subsequent connection session phase. Do not think that the user name and password are encrypted using the server pub key
-
2. Public and private key based authentication
This is also known as no-secret login. In simple terms, the client generates its own public and private keys (usually using the ssh-keyGen program), and then saves the public keys in a certain way (usually manually added) to the server ~/.ssh/authorized_keys file. The server will accept the public keys encrypted by the session key from the client. Then decrypt the public key and the local authorized_keys configured public key is equal, if yes, allow login.
If you have a github or Gitlab public key configured, the second authentication mode is easy to understand, because Github also uses SSH to clone code. It seems that cloning is not allowed without a public key configured.
3. Related Issues
- 1. Is the key negotiation phase secure? Is there a man-in-the-middle attack?!
From what I understand, it’s never safe the first time. Why is that? In the negotiation process, the server will send its public key server_host_KEY_ALGORITHMS to the client, but the client can’t guarantee that the public key it gets is the one from the target server. It’s possible that a middleman intercepted your request and sent another public key to the client. It’s not safe! This explains why the Shell terminal always displays this prompt when we first log in:
This is also a strategy that leaves confirmation to the client’s discretion. On the contrary, if we want to be more secure, then we can use the second authentication method to log in. Since the prompt is the public key after MD5, how do we know that this value is valid? Please look at the third question below.
- 2. What are the functions of the session key and session ID negotiated by the transport protocol?
Session key: the key of the symmetric encryption algorithm used to encrypt and decrypt communication data. Session ID is similar to the Session in the WEB. It represents each Session and determines whether the same Session is valid during authentication.
- 3, since the password verification login, then how to verify the server public key when the client first login?
Please tell xiaobian! Xiaobian struggled to find the answer!
Four, other
Here are the related documentation:
- 1. SSH RFC Chinese document address
- 2. The Secure Shell (SSH) Protocol Architecture
- 3. The Secure Shell (SSH) Transport Layer Protocol
We might ask, now that we have the SSH protocol documentation, how do we start if we want to write an implementation based on the documentation? SSH’s transport protocol [SSH-tarns] is based on THE TCP protocol, so we can start by creating a basic Java Socket, and gradually implement SSH’s transport protocol, authentication protocol, and connection protocol. If you are interested in the implementation process, you can study the ganymed-SSH2-build209.jar source code, combined with SSH protocol RFC documentation, you will find that SSH protocol negotiation and authentication process, in fact, through the Socket input stream, output stream form. Xiaobian oneself to the negotiation stage to give up decisively, the reason is that I do not know too much algorithm!