SSH Handshake Explained

May 9, 2019 by Russell Jones

Introduction

Secure Shell (SSH) is a widely used Transport Layer Protocol to secure connections between clients and servers. SSH is the underlying protocol thatTeleport uses to secure connections between clients and servers. Below is a relatively brief description of the handshake that occurs to establish a secure channel between a client and a server.

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 flaws in the design of version 1.0 .

Key Exchange

The 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 Teleport supports.

Key Exchange (KEX) Symmetric Cipher Message Authentication Code (MAC) Server Host Key Algorithm [email protected] [email protected] [email protected] [email protected] ecdh-sha2-nistp256 [email protected] hmac-sha2-256 ssh-rsa ecdh-sha2-nistp384 aes256-ctr ecdh-sha2-nistp521 aes192-ctr aes128-ctr

Above: Teleport default cryptographic primitives.

Elliptic Curve Diffie-Hellman Initialization

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 Teleport 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.

Elliptic Curve Diffie-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:

• Since the exchange hash includes the shared secret, it proves the other side was able to generate the shared secret.
• 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).
• 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.

• Magics M . The client version, server version, clients SSH_MSG_KEXINIT message, servers SSH_MSG_KEXINIT message.
• 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.
• Client public key A
• Server public key B
• 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 Teleport does by default), which allow you to simple store the CA in your local database of known hosts, and then all hosts signed by that CA are validated.

The authenticity of host 10.10.10.10 (10.10.10.10)' can't be established.
ECDSA key fingerprint is SHA256:pnPn3SxExHtVGNdzbV0cRzUrtNhqZv+Pwdq/qGQPZO3.
Are you sure you want to continue connecting (yes/no)?

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.

New Keys

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 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 [email protected] and [email protected] 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 theys 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 :

HASH(K || H || "A" || session_id)
HASH(K || H || "B" || session_id)
HASH(K || H || "C" || session_id)
HASH(K || H || "D" || session_id)
HASH(K || H || "E" || session_id)
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, exchanges 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 teleport handshake security