Exploring SSH Protocol Security: Analyzing Password-Based Authentication with Transport Layer Protocol Insights

Analyzing the Transport Layer Protocol in SSH with Wireshark

Experiment Foundation

“SSH Security Authentication at Two Levels with Transport Layer Protocol”

• Password-based security authentication
• Key-based security authentication

Three Sub-protocols of SSH2: A Transport Layer Protocol

• Transport Layer Protocol
• User Authentication Protocol
• Connection Protocol

This analysis mainly focuses on the transport layer protocol and user authentication protocol of password-based security authentication

Experimental Environment for Transport Layer Protocol

The client side uses Termius based on SSH2

/>

The server side is an ECS running Ubuntu, also based on SSH2’s OpenSSH

/>

Experimental Process

What actually happens when we establish an SSH connection?

1. When you attempt to establish an SSH connection with the server, an encrypted channel is first established between the client and server for packet transmission
2. Once the encrypted channel is established, your inputted password is encrypted and transmitted through the channel to the server for authentication
3. After authentication is successful, a connection is established between the client and server, with packet transmission still relying on the encrypted channel set up in the first step

Next, analyze the SSH protocol through packet capture

Analyze the captured packets step by step

1. First, in the initial packet, the client informs the server of the SSH version it is using

1. Similarly, the server returns a packet to the client, informing it of the SSH protocol version being used. This step is essentially a protocol negotiation between the two, but nowadays SSH-v2 is primarily used, thus this step simply serves to reciprocate the version

1. In this step, the connection begins to be established. The client sends a packet to the server, indicating which encryption algorithms it supports

1. Similarly, the server sends back a packet informing the client of the encryption algorithms it supports. At this point, an algorithm is negotiated between the two

1. The next step involves an interesting process: the client confirms the server’s public key, commonly known as a fingerprint. If it’s the first connection, the client saves this fingerprint locally for verification in future SSH connections
2. Subsequently, two packets are exchanged as the client and server send public keys for the Diffie-Hellman key exchange algorithm. After this step, the session key is confirmed between client and server. Further details about this algorithm can be explored on sites like Zhihu
3. The next step, the client sends a packet to the server: new keys, indicating that the encrypted channel between both ends has been established. At this point, the work of SSH-TRANS is complete

1. Next, it’s time for the SSH-AUTH phase, which occurs after entering the password and pressing enter. The subsequent packets are used for authentication between the client and server, with nothing much to elaborate on

Experiment Summary

How secure is password-based SSH authentication exactly? Do you recall the fingerprint mentioned earlier? When an SSH connection is made for the first time, the client saves the fingerprint locally. For the second connection, the client compares the local fingerprint with the one sent by the server. This step is critical because if a hacker intercepts the communication between the client and server, impersonating the server to communicate with the client, and the client isn’t aware of the fingerprint change and continues the communication, it essentially means the client’s PC has established a connection with the hacker’s PC. This is a man-in-the-middle attack.

Here, I attempted an MITM attack. As you can see, if the client carelessly clicks replace, it’s disastrous. Also, older SSH protocols below SSH2 are more susceptible to being ARP-ed for passwords.