SSH Protocol

Created: 16.05.2023

This is about … .



The first step is to inform what software and SSH version are used by both the client and the server. Then, they are trying to find the key exchange and message authentication algorithm that suits them both.


SSH header and payload sit atop the TCP header and look something like this:


❗️ All the data and the requests the were generated by the client πŸ₯Ά are coloured in blue. Each type of request or reply (the SSH payload, to be precise) sent has its own dedicated emoji (for example, the identification string is a πŸ“).

Since the client πŸ₯Ά needs the service, the client πŸ₯Ά initiates the connection and presents his preferences for both the SSH version and the software. This is called an identification string πŸ“.


The server 🌝 then demonstrates it’s “household” with a similar reply πŸ“:

img Now, they need to agree on the settings: ciphers and hash algorithms. First, the client πŸ₯Ά is coming out with the Key Exchange Init 🍎 message.


Then the server 🌝 sends a similar Key Exchange Init 🍎 message showing its acceptable cipher suits.


The server 🌝 typically uses the first acceptable option presented by the client. But if none is acceptable for the server 🌝, the SSH connection won’t be established.

🎼 🀫 Session Key Generation

The client πŸ₯Ά generates two keys: a private πŸ—οΈ and a public πŸ”‘ one. The algorithm used for this key generation was agreed upon in the previous stage. Often it’s Elliptic Curve Diffie-Hellman or Diffie-Hellman. To understand how Diffie-Hellman works to exchange secret keys without actually sending them over (something like when scientists from different parts of the world come up with the same ideas).

img The client’s πŸ₯Ά public key πŸ”‘ is then sent over to the server 🌝 and that’s called an SSH message Key Exchange Initialisation πŸ‡.

img Upon receiving the client’s πŸ₯Ά public key πŸ”‘, the server 🌝 starts generating its own pair of asymmetrical keys.

img Here are the states of both the client πŸ₯Ά and the server 🌝 at this stage.

img As you can see, the client πŸ₯Ά has only its own private πŸ—οΈ and public πŸ”‘ keys, while the server 🌝 has the following data:

  1. the client’s πŸ₯Ά DF public key πŸ”‘;
  2. the server’s 🌝 DF public πŸ”‘ and private πŸ—οΈ keys;
  3. the server’s 🌝 host asymmetrical public πŸ”‘ and private πŸ—οΈ keys (these can be used, for example, with other clients or/and in SSL connections etc.). Let’s call them global. CA (certificate authority) will store the certificate with this public πŸ”‘ key so that the server’s 🌝 clients can verify its identity. But that’s another story.

Both parties have all the information needed to generate a shared secret key 🎼 🀫 and a hash 🧢. Let’s take a little peek at the server’s 🌝 activity first. The server 🌝 takes its private πŸ—οΈ and public πŸ”‘ keys, plus the client’s πŸ₯Ά public key πŸ”‘ shared previously to derive the value of the shared secret key (session key 🎼 🀫).


Then the server will calculate the hash based on the following data (the list is quite long):

  1. the client’s πŸ₯Ά identification string πŸ“ (the payload of the first client’s request);
  2. the server’s 🌝 identification string πŸ“ (the payload of the first server’s reply);
  3. the payload of the second client’s πŸ₯Ά request 🍎;
  4. the payload of the second server’s 🌝 reply 🍎;
  5. the server’s 🌝 global public πŸ”‘ πŸͺͺ key generated long ago;
  6. the client’s πŸ₯Ά public πŸ”‘ key;
  7. the server’s public DF πŸ”‘ key that was generated at the beginning;
  8. the shared secret key 🎼 🀫 was generated in the previous stage.

img Now, the server 🌝 will sign this hash with its global private key πŸ—οΈ πŸͺͺ so that the client πŸ₯Ά who has its global public key πŸ”‘ πŸͺͺ can verify that the server sent this. No one is supposed to have the private key πŸ—οΈ πŸͺͺ of the server 🌝 and the corresponding public key can only decrypt the message locked by the corresponding public key πŸ”‘ .

β—οΈβš”οΈ If the private key πŸ—οΈ was compromised, game over.


Now, the server 🌝 sends the calculated and signed hash 🧢, its DF public key πŸ”‘ and the global public key πŸ”‘πŸͺͺ to the client πŸ₯Ά so that the client πŸ₯Ά can repeat the same steps.

img And so the client does. This message is called SSH Message Exchange Elliptic Curve Diffie-Hellman Reply πŸ‰.

First, the client πŸ₯Ά generates the same shared secret key 🎼🀫, but using its own private πŸ—οΈ and public πŸ”‘ keys (not the server’s) and the server’s global public key πŸ”‘ πŸͺͺ received in the previous step.

img Now, it’s time to calculate the hash 🧢. Note the client πŸ₯Ά doesn’t yet touch the hash 🧢 sent over by the server 🌝.


❗️ βš”οΈ Note that both the client πŸ₯Ά and the server 🌝 have all this data. However, the eavesdropper won’t have one little element: 🎼 🀫 the shared secret key. That’s because the eavesdropper has neither the client’s nor the server’s private keys πŸ—οΈ.

But now, the client πŸ₯Ά will use the server’s 🌝 public key πŸ”‘ πŸͺͺ to unlock the hash 🧢 sent over by the server 🌝. After that, the client πŸ₯Ά will compare this hash 🧢 to the one the client πŸ₯Ά has just calculated.


❗️ By the way, note that the client πŸ₯Ά doesn’t have nor it needs a client certificate πŸ₯Ά πŸͺͺ.

πŸͺ› Decryption Key Generation

Now, at this point, both the client and the server have the session key (shared secret one), and can proceed to the next stage. At this stage, they both will derive three values from this session key:

  1. πŸͺ› Decryption key that will be used to encrypt and decrypt the messages.
  2. πŸ”§ IV (initialisation vector) - a random value generated separately by the client and the server to randomise the ciphertext.
  3. πŸ”© A key for HMAC (signing the messages exchange to spot tampering).

❗️Note that πŸ₯ΆπŸͺ› = 🌝πŸͺ›, πŸ₯ΆπŸ”© = πŸŒπŸ”©, but the IVs are random and thus different. IV is not a private value! I have tried to show this by using blue colors for client specific data, yellow - for server’s specific data, and purple - for separately generated data that’s the same for both parties.


Establishing The Connection

Now, the server informs the client πŸ₯Ά that it has finished and sends a New Keys πŸ‘ message over.

img The client πŸ₯Ά then responds with a similar message πŸ‘, also New Keys.


It took so long to establish this connection that the server 🌝 and the client πŸ₯Ά might have forgotten already what this was all about… . Ah, right, the service request!

The client sends a service request πŸ₯ message to the server.


All is good, no point to back off at this stage, so the server 🌝 presents the lucky winner with a flag.txt πŸ‡¦πŸ‡Ί.



Detection and Investigation

πŸ›  ExtraHop or πŸ›  ntop (see Chapter 1) provides insight into the amount of data being transferred and to where even when that data is encrypted.

πŸ›  Wireshark Filters:

  1. http.request - show only HTTP request. Useful to get rid of all ARP and TCP handshake garbage.
  2. ip.src == and udp.port == 67 - show the DHCP requests for this machine. Can show the computer name.