I'm a cybersecurity student and I'm eager to understand the basic processes of an SSH session. I wrote down the stages to the best of my ability but need help understanding what happens right after the TCP handshake and right before the Diffie-Hellman key exchange. Please help:

Session Start/TCP Handshake

  1. Client begins a session with Server by initiating a TCP handshake.
    Assymetric Encryption for TCP Session

  2. Server and Client negotiate back-and-forth and agree upon a mutually supported encryption protocol for the TCP session.
    At this point, post-protocol-negotiation, it is unclear to me how their session is initially being encrypted. I used Wireshark to try and capture the Client or Server sending over their public key or something but could only see the protocol version exchange. Regardless, please explain this stage if you can.
    Client and Server negotiate a shared secret key for this session using the Diffie-Hellman algorithm in order to establish a symmetric-key encrypted session.

  3. Client and Server begin process of producing temporary key pairs, using

    1. Shared prime number
    2. Encryption generator (typically AES)
    3. Private prime number (as private key).
  4. Client and Server use these three to each generate their own public key that can be derived from their own private key.

  5. Client and Server each share their generated public key with each other.

  6. Client and Server each use their own private key, the other's public key and their original shared prime number to generate the same secret key.

  7. Client and Server use this key as their shared secret key to encrypt and decrypt all future communication on this session.

At this stage, Client and Server have successfully established a symmetric-key-encrypted session without having needed to send the secret key over the network.

If I got anything else wrong I'd really appreciate any clarification. Thanks!


1 Answer 1


The Diffie-Hellman key exchange takes place over an unencrypted connection, as does the initial algorithm negotiation. This is required because the key exchange results in a shared secret which is used to generate the secrets required for symmetric-key encryption.

Since there is no encryption or integrity checking (e.g., with an AEAD or HMAC), it's important to authenticate this part of the session, so the exchange hash includes both the shared secret and a variety of other data, including the client and server version, client and server Diffie-Hellman parameters, and the initial algorithm offers. The exchange hash is signed by the server (and the client, along with other data, if public keys are used). If an attacker tampered with these values, the exchange hash would differ from what the parties computed, the signature would fail to verify, and the connection would be aborted. Even if the client is not using public keys, the hash and keys would differ, and the connection would be unusable (and would promptly fail due to MAC failures).

The server signs its version of the exchange hash when it sends its Diffie-Hellman response.

From the exchange hash and the shared secret, the encryption, MAC, and initial IV are generated. A NEWKEYS messages is then sent and the new keys are then used.

The client then authenticates over the encrypted connection. This is required because they may be using a password, and authenticating with a password over an unencrypted connection would be a bad idea. If the client uses keys, they also sign the original exchange hash plus additional data.

Note that the encryption keys, MAC keys, and IVs are generated from the shared secret; they are not generated independently. This means that less randomness is required and ensures that an appropriate level of security is achieved. TLS does the same thing.

The gory details are described in RFC 4253 and client authentication is described in RFC 4252. Note that many of the algorithms described are no longer in use or are deprecated. Modern algorithms are described in other RFCs, or sometimes in external documents if they are specified by an implementation (that is, their name contains an @ sign).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .