SSH Protocol Deep Dive: Packet Structure, Key Exchange, and Cryptographic Internals

SSH Protocol Deep Dive: Packet Structure, Key Exchange, and Cryptographic Internals

Secure Shell (SSH) is far more than a simple remote login tool. At the protocol level, SSH is a carefully layered cryptographic framework defined primarily in RFC 4251–4254. It establishes a secure tunnel over TCP and then multiplexes multiple logical channels within that tunnel.

This article examines SSH from a protocol-engineering perspective, focusing on message flow, packet structure, and cryptographic operations.

---

🔐 1. Transport Layer Protocol (RFC 4253)

#

The Transport Layer Protocol is responsible for:

• Server authentication
• Confidentiality (encryption)
• Integrity protection
• Key exchange
• Session key derivation

Everything else in SSH depends on this layer.

---

1.1 Version Exchange

#

After TCP connection (typically port 22), both sides exchange identification strings:

SSH-2.0-OpenSSH_9.6
SSH-2.0-ClientSoftware_1.0

Important details:

• Must end with CRLF
• Used in hash computation during key exchange
• Determines protocol compatibility (SSH-1 vs SSH-2)

---

1.2 Binary Packet Protocol

#

After version exchange, SSH switches to binary packet format.

Each SSH packet has the following structure:

uint32    packet_length
byte      padding_length
byte[n1]  payload
byte[n2]  random_padding
byte[m]   mac (if not using AEAD)

Where:

• packet_length = payload + padding + padding_length field
• padding_length ≥ 4 bytes
• Total packet size must align to cipher block size (or 8 bytes minimum)
• mac is omitted if using AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305)

The payload begins with:

byte    message_number
byte[]  message_specific_fields

---

1.3 Algorithm Negotiation (KEXINIT)

#

Both client and server send SSH_MSG_KEXINIT.

The message contains lists of supported algorithms:

• Key exchange algorithms
• Server host key algorithms
• Encryption algorithms (client→server)
• Encryption algorithms (server→client)
• MAC algorithms
• Compression algorithms

Example negotiation categories:

kex_algorithms:
  curve25519-sha256
  diffie-hellman-group14-sha256

server_host_key_algorithms:
  ssh-ed25519
  rsa-sha2-512

encryption_algorithms:
  chacha20-poly1305@openssh.com
  aes256-gcm@openssh.com

The first mutually supported algorithm in each category is selected.

---

1.4 Key Exchange (Diffie–Hellman / Curve25519)

#

Modern SSH commonly uses:

• curve25519-sha256
• diffie-hellman-group14-sha256

For Diffie–Hellman:

1. Client generates: $$ [ e = g^x mod p ] $$

2. Server generates: $$ f = g^y mod p $$

3. Shared secret: $$ K = f^x mod p = e^y mod p $$

For Curve25519:

• Uses elliptic curve scalar multiplication
• More efficient and resistant to certain attacks

The shared secret K is never transmitted directly.

---

1.5 Exchange Hash and Server Authentication

#

Both sides compute:

$$ H = HASH( V_C || V_S || I_C || I_S || K_S || e || f || K ) $$

Where:

• V_C, V_S = version strings
• I_C, I_S = KEXINIT payloads
• K_S = server public host key
• e, f = key exchange values
• K = shared secret

The server signs H using its private host key.

The client verifies the signature using the server’s known public key.

This step prevents man-in-the-middle attacks.

---

1.6 Session Key Derivation

#

Session keys are derived from:

• Shared secret K
• Exchange hash H
• Session ID

Keys are derived separately for:

• Client → Server encryption
• Server → Client encryption
• MAC keys (if applicable)
• Initialization vectors

After this stage:

• All communication is encrypted
• Integrity is enforced
• Transport layer is fully established

---

🔑 2. Authentication Protocol (RFC 4252)

#

Once transport encryption is active, SSH enters user authentication phase.

---

2.1 Service Request

#

Client sends:

SSH_MSG_SERVICE_REQUEST
  service_name = "ssh-userauth"

Server replies:

SSH_MSG_SERVICE_ACCEPT

---

2.2 Public Key Authentication Flow

#

For Ed25519:

1. Client sends:

   SSH_MSG_USERAUTH_REQUEST
     method = "publickey"
     public_key_algorithm = "ssh-ed25519"
     public_key_blob
   

2. Server responds with acceptance or failure.

3. Client sends signed authentication request:

   signature = SIGN(private_key, session_id || packet_data)
   

4. Server verifies signature using authorized_keys.

If valid → authentication success.

The private key never leaves the client.

---

📡 3. Connection Protocol (RFC 4254)

#

After authentication, SSH enables multiplexed channels.

---

3.1 Channel Model

#

Each channel has:

• Channel ID (local)
• Remote channel ID
• Window size
• Maximum packet size

Common channel types:

• session
• direct-tcpip (local forwarding)
• forwarded-tcpip (remote forwarding)
• subsystem (e.g., sftp)

---

3.2 Channel Open

#

Client sends:

SSH_MSG_CHANNEL_OPEN
  channel_type
  sender_channel
  initial_window_size
  maximum_packet_size

Server responds with:

SSH_MSG_CHANNEL_OPEN_CONFIRMATION

---

3.3 Data Transfer

#

Data is sent using:

SSH_MSG_CHANNEL_DATA

Flow control is enforced using window adjustments:

SSH_MSG_CHANNEL_WINDOW_ADJUST

This prevents buffer overflow and enables controlled streaming.

---

3.4 Example: Port Forwarding Internals

#

Local port forwarding:

1. Client opens channel:

   channel_type = "direct-tcpip"
   

2. Specifies:
   • Target host
   • Target port
3. SSH tunnels data through encrypted transport.

All forwarded traffic is indistinguishable from regular SSH traffic at TCP level.

---

🛡 4. Cryptographic Protection Model

#

Modern SSH typically uses:

• Key Exchange: Curve25519
• Host Key: Ed25519
• Encryption: ChaCha20-Poly1305 or AES-GCM
• Integrity: AEAD (no separate MAC)

AEAD ciphers combine encryption and authentication:

Ciphertext = Encrypt(plaintext, key, nonce)
Tag = MAC(ciphertext)

This eliminates separate MAC calculation and improves performance.

---

🔍 5. Rekeying and Forward Secrecy

#

SSH periodically rekeys:

• After 1 GB of data (default)
• Or after a time threshold

Rekeying repeats key exchange inside encrypted tunnel.

Because ephemeral Diffie–Hellman is used:

• Compromise of long-term host key does NOT expose past sessions
• Provides Perfect Forward Secrecy (PFS)

---

🧠 6. Why SSH Remains Secure

#

SSH’s strength comes from:

1. Layered cryptographic design
2. Strong host authentication
3. Ephemeral key exchange
4. Encrypted transport with integrity protection
5. Channel multiplexing within single TCP stream
6. Rekeying and forward secrecy

When configured with:

• Ed25519 host keys
• Curve25519 key exchange
• ChaCha20-Poly1305 encryption
• Password authentication disabled

SSH remains one of the most robust secure remote access protocols in widespread use today.