SSH Handshake Explained

What is SSH handshake?

Secure Shell (SSH) is a widely used Transport Layer Protocol to secure connections between clients and servers. SSH handshake is a process in the SSH protocol responsible for negotiating initial trust factors for establishing a secure channel between an SSH client and SSH server for an SSH connection. The handshake process includes:

1. SSH protocol version exchange
2. Key Exchange
3. Elliptic Curve Diffie-Hellman Initialization
4. Elliptic Curve Diffie-Hellman Reply
5. New Keys

This post will cover these five steps of the handshake process in detail. Although this post references SSH handshake based on Remoteler, the process is compliant with SSH protocol and is compatible with OpenSSH SSH handshake process. Remoteler is an open source access place offering security-hardened SSH access with RBAC and security auditing features.

1. SSH Version Exchange

SSH begins by both sides sending a version string to each other. Nothing terribly exciting happens in this part of the handshake, but it should be noted that most relatively modern clients and servers only support SSH 2.0 due to several flaws in the design of SSH1 most notably:

1. SSH1 is a one monolithic protocol, without the ability to customize transport, authentication and connection concerns.
2. SSH1 uses weaker CRC-32 integrity check.
3. SSH1 does not support channel encapsulation within a single session. You can read more about SSH1 limitations here.

2. Key Exchange

SSH key exchange (sometimes called KEX) is used by the client and server to exchange information in public that leads to a secret shared by the client and server that an observer can not discover or derive from public information.

Key Exchange Initialization

The key exchange is kicked off by both sides sending a SSH_MSG_KEX_INIT message to each other with a list of cryptographic primitives they support with the order reflecting their preference.

The cryptographic primitives are to establish the building blocks that will be used to perform the key exchange and then bulk data encryption. The table below lists of cryptographic primitives that Remoteler supports.

Above: Remoteler default cryptographic primitives.

3. Elliptic Curve Diffe-Hellman Initialisation

Because both sides use the same algorithm to select cryptographic primitives out of the supported list, after the key exchange initialization, the key exchange can begin immediately. Since Remoteler only supports Elliptic Curve Diffie-Hellman (ECDH), the key exchange begins by the client generating an ephemeral keypair (private and associated public key) and sending the server it’s public key in a SSH_MSG_KEX_ECDH_INIT message.

It’s worthwhile to emphasise that this keypair is ephemeral: it will only be used during the key exchange and disposed of afterwards. This makes a class of attack where an attacker passively records encrypted traffic with the hope of stealing a private key sometime in the future extremely difficult. It’s very difficult to steal something that simply no longer exists. This property is called forward secrecy.

Figure 1: Generation of the key exchange initialization message.

4. SSH Ellipctic Curve Diffe-Hellman Reply

The server listens for the SSH_MSG_KEX_ECDH_INIT message, and upon receipt, generates its own ephemeral keypair. With the client’s public key and its own keypair, the server can generate the shared secret K.

Next, the server generates something referred to as the exchange hash H and signs it generating HS, see Figure (3) for more details. The exchange hash and its signature serves several purposes:

1. Since the exchange hash includes the shared secret, it proves the other side was able to generate the shared secret.
2. The signature/verification loop of the exchange hash and signature allows the client to verify the server has ownership of the host private key and therefore the client is connected to the correct server (as long as the client can trust the corresponding public key, more on this later).
3. By signing the exchange hash, instead of signing the input to the exchange hash, the size of the data to be signed is substantially reduced and results in a faster handshake.

The exchange hash is generated by taking the hash (either SHA256, SHA384, or SHA512, depending on the key exchange algorithm) of the following fields.

1. Magics M. The client version, server version, clients SSH_MSG_KEXINIT message, servers SSH_MSG_KEXINIT message.
2. Server host public key (or certificate) HPub. This value (and its corresponding private key HPriv) is typically generated during process initialization and not generated for every handshake.
3. Client public key A
4. Server public key B
5. The shared secret K

With this information in hand, the SSH_MSG_KEX_ECDH_REPLY message can be constructed by the server from the ephemeral public key of the server B, the host public key of the server HPub, and the signature on the exchange hash HS. See Figure (4) for more details.

Figure 2: Generation of the exchange hash H

Once the client receives a SSH_MSG_KEX_ECDH_REPLY, it has everything needed to calculate the secret K and the exchange hash H.

The last part of the key exchange has the client extract the host public key (or certificate) from SSH_MSG_KEX_ECDH_REPLY and verifies the signature of exchange hash HS proving ownership of the host private key. To prevent Man-in-the-Middle (MITM) attacks, once the signature is validated the host public key (or certificate) is checked against a local database of known hosts; if this key (or certificate) is not trusted the connection is terminated.

If you’ve ever seen a message like below, it means that the the key presented is not in your local database of known hosts. A good way to avoid seeing this type of message is to use SSH certificates instead of keys (something that Remoteledoes by default), which allow you to simple store the Certificate Authority in your local database of known hosts, and then all hosts signed by that Certificate Authority are validated.

Above: An SSH client asking to add a host key to the local database of known hosts. For OpenSSH that is typically ~/.ssh/known_hosts.

Figure 3: Generation of the ECDH KEX reply.

5. New Key

One last thing remains before bulk data encryption can begin, both sides need to generate 6 keys: two keys for encryption, two initialization vectors (IV), and two for integrity. It’s not unreasonable to ask, what is the purpose of so many additional keys? Isn’t the shared secret K enough? It’s not.

First, let’s address the need for distinct keys for encryption, integrity, and IV. One of the reasons is due to how protocols like TLS and SSH have historically been constructed to allow the negotiation of cryptographic primitives. Depending on the cryptographic primitives chosen, key re-use may not be an issue, but as Henrick Hellström points out, for the wrong choice (like AES-256-CBC and AES-256-CBC-MAC for confidentiality and authentication respectively), it can be disastrous. It should be noted that protocol designers are moving away from this type of agility to make protocols simpler and more secure.

Next, let’s address the need for each type of key.

Encryption keys are used to ensure data confidentiality and are used with a symmetric cipher to encrypt and decrypt data.

Integrity keys are typically used with a message authentication code (MAC) to ensure an attacker does not manipulate the ciphertext. If an integrity check on the ciphertext does not exist, an attacker can manipulate the ciphertext being sent over the wire and you might decrypt something the sender did not send. This type of scheme is typically called Encrypt-then-MAC.

It should be noted that modern AEAD ciphers like aes128-gcm@openssh.com and chacha20-poly1305@openssh.com don’t actually use the derived integrity key for the MAC, they perform authentication internal to their construction.

Initialization vectors (IV) are typically random numbers used as input to a symmetric cipher. The purpose of an IV is to ensure that the same message encrypted twice does not result in the same ciphertext. The need for this property has famously been visualized by the ECB mode Tux image. How IVs have been used (and exploited) is an interesting topic in of itself that Filippo Valsorda has written about.

Lastly, why do keys come in pairs? As Thomas Pornin outlines, if only a single integrity key is used, an attacker can replay a record the client sent back to the client and the client would consider it valid. With multiple integrity keys (one for server to client, and another client to server), when the client performs the integrity check on the ciphertext, it would fail.

Now with an understanding of why we need these keys, let’s cover how they are generated, from the RFC:

1. Initial IV client to server: HASH(K || H || "A" || session_id)
2. Initial IV server to client: HASH(K || H || "B" || session_id)
3. Encryption key client to server: HASH(K || H || "C" || session_id)
4. Encryption key server to client: HASH(K || H || "D" || session_id)
5. Integrity key client to server: HASH(K || H || "E" || session_id)
6. Integrity key server to client: HASH(K || H || "F" || session_id)

Here the hash algorithm is SHA{256, 384, or 512} depending on the key exchange algorithm with the || symbol implying concatenation.

Once these values are computed both sides send a SSH_MSG_NEWKEYS to inform the other side that the key exchange is over and all future communication should occur using the new keys generated above.

Figure 4: Generation of the initial IV. Generation for the other keys is similar, replacing “A” and “B” with “C”, “D”, “E”, and “F” respectively.

Conclusion

At this point, both sides have agreed upon cryptographic primitives, exchanged secrets, and arrived upon key material for the selected primitives and a secure channel that can provide confidentiality and integrity can be established between client and server.

And that is how the SSH handshake establishes a secure connection between clients and servers.

SSH access with Remoteler 

Remoteler is an open source access place offering security-hardened SSH, RDP, database, web application, and Kubernetes cluster access with certificates, RBAC, and security auditing features. SSH is the underlying protocol that Remoteler uses to secure connections between clients and servers. Learn how Remoteler works and get started with Remoteler today.