What Happens Under the Hood of SSH Connections? Analyzing SSH Packets with Wireshark.

Prerequisites

Before we dive into packet analysis, make sure you have the following set up:

Two Endpoints (VMs or Containers)
Wireshark
tcpdump

It’s also important to have a basic understanding of:

TCP
SSH
Linux

Introduction

In this blog post, I'll guide you through the step-by-step process of analyzing SSH connection packets using Wireshark. Whether you're troubleshooting SSH issues or simply curious about how SSH works at the protocol level, this tutorial is for you.

We'll cover both successful and failed SSH connections, examining the packet flow and explaining what’s happening in the background.

I've already set up a working environment for this use case. Let’s dive right into packet capture and analysis, and uncover what happens during an SSH connection.

Fig. 1: A list of servers with roles and IP addresses for quick network reference.

Breaking Down Packet Capture and Analysis: A Step-by-Step Guide

In this post, we'll break down the process of packet capture and analysis into two distinct parts for clarity:

1. Packet Capture

To begin with, we need to capture the network packets involved in the communication between the client and server. Here are the steps:

Login to the Server: First, log in to the server (sure-sunfish at IP 192.168.64.68).
List Network Interfaces: Check and list the available network interfaces on the server.
Enable Packet Capture: Enable packet capture on the enp0s1 interface on the server to monitor the incoming and outgoing packets.
Login to the Client: Next, log in to the client machine (nonchalant-titmouse at IP 192.168.64.67).
Initiate the SSH Connection: Start the SSH connection from the client to the server.
Stop the Capture: Finally, stop the packet capture on the server once the connection process is complete.

Fig. 2: Accessing the Server "sure-sunfish" at IP address 192.168.64.68 for login..

Fig. 3: Using the ifconfig -s command to list all network interfaces on the Server "sure-sunfish" with IP address 192.168.64.68.

Fig. 4: Capturing network traffic on Server "sure-sunfish" (IP: 192.168.64.67) with the command sudo tcpdump -i enp0s1 -s 65535 -w /tmp/failedssh.pcap

Fig. 5: Generating SSH traffic from Client "nonchalant-titmouse" (IP: 192.168.64.67) to Server "sure-sunfish" (IP: 192.168.64.68) using ssh 192.168.64.68.

Fig. 6: Stopping the packet capture on "sure-sunfish" (IP: 192.168.64.68) by pressing Ctrl + C.

Packet Analysis with Wireshark

Load Wireshark: Start by launching the Wireshark application, a powerful tool for network traffic analysis.
Open the Captured PCAP File: Import the packet capture (PCAP) file you want to analyze by navigating to File > Open and selecting the desired file.
Analyze the Packets: Use Wireshark's features, such as filters, statistics, and packet details, to better understand the captured network data and extract meaningful insights.

This streamlined approach ensures better readability and organization for your blog on packet analysis.

Fig. 7: Opening Wireshark on my desktop to analyze the packet capture from the client "sure-sunfish" (IP: 192.168.64.68).

Fig. 8: Loading the packet capture file from the server "sure-sunfish" (IP: 192.168.64.68) into Wireshark for analysis.

The screen above is cluttered and difficult to analyze effectively. To simplify the process, we will validate key elements and apply a conversation filter to focus on specific details. This approach will help streamline the data and ensure more efficient packet analysis, making it easier to pinpoint relevant information for troubleshooting.

Validation Points:

Packet Count: Confirm the total number of packets captured, which is 68.
Conversation Filter: Create a filter to isolate relevant communication streams for easier analysis and to narrow down the scope.

Fig. 9: Creating a TCP conversation filter to isolate relevant traffic for clearer analysis.

The first step in any TCP connection within this pcap is the 3-way handshake, where SYN and ACK packets are exchanged to establish a connection between the client and server, preparing them for data transfer.

Fig. 10: Summary of the TCP 3-way handshake in this pcap. The client sends SYN, the server responds with SYN-ACK, and the client sends ACK to establish the connection.

The client (nonchalant-titmouse at 192.168.64.67) has initiated a TCP connection by sending a SYN packet to the server (sure-sunfish at 192.168.64.68).

Fig. 11: Capturing the source address (192.168.64.67), source port (35970), destination address (192.168.64.68), and destination port (22) during the TCP handshake.

Fig. 12: The TCP flags set for this packet, including the SYN flag, which is set to 1 to indicate the initiation of the connection.

2. The server (sure-sunfish at 192.168.64.68) responds by acknowledging the client's SYN packet (incrementing the ACK to 4168038349, which is SYN 4168038348 + 1) and sending its own server-side SYN packet with a sequence number of 750548651.

Fig. 13: Capturing details from the second packet, with the source address (192.168.64.68), source port (22), destination address (192.168.64.67), and destination port (35970).

Fig. 14: The SYN and ACK flags are set, confirming the server’s acknowledgment of the client’s request. The sequence and acknowledgment numbers indicate the progress of the handshake, marking the second step in the TCP connection setup.

3. The client (nonchalant-titmouse at 192.168.64.67) responds by acknowledging the server's SYN packet (750548651) with an ACK value of 750548652.

Fig. 15: The third packet captures source (192.168.64.67), source port (35970), destination (192.168.64.68), and destination port (22). The ACK flag is set, completing the TCP 3-way handshake.

Now that the connection is established, the client-side and server-side sequence numbers are set for the upcoming communication. Let’s analyse how the data exchange progresses with these sequence numbers and flags, as we delve deeper into the transmission process.

Version Negotiation

During version negotiation, the client (nonchalant-titmouse at 192.168.64.67) sends a PSH flag with the SSH version, along with an ACK flag to confirm the connection. The PSH flag ensures that the data is immediately pushed to the receiving application, without being buffered, allowing for faster processing. The server (sure-sunfish at 192.168.64.68) acknowledges the client's message and responds with its own SSH version, also including an ACK flag to confirm receipt

Fig. 16: Displays the version negotiation summary, ensuring both client and server agree on the protocol version before proceeding with communication.

Fig. 17: Captures packets from source 192.168.64.67 to destination 192.168.64.68, showing sequence and acknowledgment numbers, continuing the data exchange.

Fig. 18: Shows the client sharing the supported SSH protocol details with the server for version negotiation.

Fig. 19: Displays the TCP options set by the client while sharing protocol information with the server. The PSH and ACK flags are set to 1, indicating the data is being pushed to the server and acknowledging the previous transmission.

Fig. 20: The server responds with PSH and ACK flags set to 1, accompanied by the respective sequence and acknowledgment numbers. The response includes the supported protocol versions from the server side, completing the negotiation process.

Fig. 21: The server responds with PSH and ACK flags set to 1, accompanied by the respective sequence and acknowledgment numbers. The response includes the supported protocol versions from the server side, completing the negotiation process.

2. Key Exchange and Algo Negotiation

Once the key exchange is complete and the algorithm for encryption and message integrity is negotiated, SSH key-based authentication proceeds as follows:

Client Sends Public Key Information:
- The client presents its public key to the server as part of the authentication process. This public key is pre-shared with the server and stored in the user's ~/.ssh/authorized_keys file on the server.
Server Verifies Public Key:
- The server checks if the presented public key matches any key in the ~/.ssh/authorized_keys file for the user attempting to log in.
Challenge Creation:
- If the public key matches, the server creates a random challenge (nonce) and encrypts it with the client’s public key.
Client Proves Ownership of Private Key:
- The client decrypts the challenge using its private key (which remains secure and is never transmitted) and sends the decrypted challenge back to the server.
Server Verifies Challenge Response:

The server verifies the decrypted challenge. If it matches, the server authenticates the client and establishes the SSH session.

Fig. 21: After protocol negotiation, the client sends the Key Exchange initiation, setting both PSH and ACK flags to 1. Along with this, 1536 bytes of data are transmitted to the server as part of the key exchange process.

Fig. 22: After protocol negotiation, the client sends the Key Exchange initiation, setting both PSH and ACK flags to 1. Along with this, 1536 bytes of data are transmitted to the server as part of the key exchange process.

Fig. 23: After protocol negotiation, the client sends the Key Exchange initiation, setting both PSH and ACK flags to 1. Along with this, 1536 bytes of data are transmitted to the server as part of the key exchange process.

Fig. 24: After protocol negotiation, the client sends the Key Exchange initiation, setting both PSH and ACK flags to 1. Along with this, 1536 bytes of data are transmitted to the server as part of the key exchange process.

Fig. 25: The server responds with PSH and ACK flags set to 1, sending 1120 bytes of data to the client as part of the ongoing key exchange process.

Fig. 26: The server responds with PSH and ACK flags set to 1, sending 1120 bytes of data to the client as part of the ongoing key exchange process.

What Happens in Our Case?

In our packet capture, the TCP connection is closed due to the absence of the client's public key on the server. This prevents the server from verifying the client's authenticity, leading to failed authentication. Following this, the server initiates a graceful termination of the TCP session, closing the connection in a controlled manner.

Fig. 27: The client initiates the connection termination by sending a FIN and ACK to the server, marking the start of the graceful closure process.

Fig. 28: Displays sequence and acknowledgment numbers along with TCP flags, offering more details on the connection termination process initiated by the client.

Fig. 29: The server responds with a FIN and ACK, completing the termination process initiated by the client.

Fig. 30: The server responds with a FIN and ACK, completing the termination process initiated by the client.

Fig. 31: The server responds with a FIN and ACK, completing the termination process initiated by the client.

Fig. 32: The server responds with a FIN and ACK, completing the termination process initiated by the client.

Fig. 33: The server responds with a FIN and ACK, completing the termination process initiated by the client.

Summary

Here's the summary :

Step 1: TCP connection is established.
Step 2: Protocol version is negotiated between the client and server.
Step 3: Key exchange method and algorithm are negotiated.
Step 4: Keys are exchanged and validated for authentication.
Step 5: If any step fails, the TCP connection is closed, ensuring secure communication.

These steps outline the initial SSH connection process before executing SSH commands, ensuring a secure and verified connection.

Feel free to reach out ( Linkedin ) for any questions or doubts. Happy learning, and don't forget to explore more on the topic!

Thanks and regards!!!

Search This Blog

`we@osgroup-techies:~# _`