Understand wireshark capture for ssh key exchange [closed]

Question

I need to understand SSH key exchange, I have tried to read RFC document but it seems very difficult to understand so I have captured packets using wireshark ,I found various packets for ssh keyexchange

SSHv2 Client: Key Exchange Init
SSHv2 Server: Key Exchange Init
SSHv2 Client: Diffie-Hellman Key Exchange Init
SSHv2 Server: Diffie-Hellman Key Exchange Reply
SSHv2 Client: Diffie-Hellman GEX Init
SSHv2 Server: Diffie-Hellman GEX Reply
SSHv2 Client: New Keys

Can any one explain me each packet in detail or sequence of ssh key exchange ??

Answer 1

First of all you should understand the concept of a Diffie-Hellman exchange. It allow to establish a channel between 2 endpoints with these features:

• Protects against eavesdropping. Someone sniffing on the channel cannot decrypt it.
• Diffie-Hellman Does NOT protect against man-in-the middle attacks. This kind of attacks are prevented through verification of host key. This is done after DH exchange, so it is encrypted and cannot be analyzed with wireshark at this time.

• It generates random number that cannot be determined by neither of the peers alone, but the two together. This is an interesting concept to me.

• From the wikipedia article here is a simplified structure of the exchange:

  1. Let g be a known public number from a finite cyclic group.
  2. Alice picks a random natural number a and sends g^a to Bob.
  3. Bob picks a random natural number b and sends g^b to Alice.
  4. Alice computes (g^b)^a = g^ab
  5. Bob computes (g^a)^b = g^ab

As a result they have generated a safe random secret g^ab.

AND NOW FOR THE WIRESHARK CAPTURE!

1. SSHv2 Client: Key Exchange Init

   Several parameters negotiation, like compression and some crypto algorithms.

2. SSHv2 Server: Key Exchange Init

   Reply to above

3. SSHv2 Client: Diffie-Hellman Key Exchange Init

   Negotiation of the DH parameters about mathematical group. (See RFC4419 section 3 for more details).

4. SSHv2 Server: Diffie-Hellman Key Exchange Reply

   Reply to above.

5. SSHv2 Client: Diffie-Hellman GEX Init

   First actual exchange of DH. Following wikipedia notation this would be step 2 (Alice sends g^a).

6. SSHv2 Server: Diffie-Hellman GEX Reply

   The exchange finishes (Bob sends g^b).

   After receiving this packet both peers know the secret key (g^ab) and establish a pseudo-secure channel with it (secure against casual eavesdropping, but not against man-in-the-middle-attacks).

7. SSHv2 Client: New Keys

   This looks like a simple acknowlegding message to me. It is small and contains no significative data.

   Ok, I suppose there's a lot going on after this (server public key verification, user authentication, establishment of data channels for shell/sftp/scp/tunnels, etc). I don't know the exact details and (un)fortunately all this is encrypted.

Useful references:

1. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
2. http://www.ietf.org/rfc/rfc4251.txt

Answer 2

The client and the server begin by sending to each other the protocol and software versions they are using.

SSHv2 Client: Key Exchange Init

Here, the client tells the server the algorithms it supports for each function (encryption, MAC, key exchange, host authentication, compression), in order of preference.

SSHv2 Server: Key Exchange Init

The server does the same. Note that it can send this message before it has received the one from the client.

From the two lists of algorithms, the client and the server compute independently the same cipher suite. For instance, they choose the same kex exchange algorithm (and it takes place right after that).

SSHv2 Client: Diffie-Hellman Key Exchange Init
SSHv2 Server: Diffie-Hellman Key Exchange Reply
SSHv2 Client: Diffie-Hellman GEX Init
SSHv2 Server: Diffie-Hellman GEX Reply

The Diffie-Hellman key exchange enables the client and the server to end up with a shared secret that an observer on the network cannot feasibly guess. For example, they will derive a key for the encryption algorithm from this secret.

Note that the reply of the server also contains its public host key (or certificates). If it is a public key and the client has never seen it, the client usually asks the user if it should trust it:

The authenticity of host 'debian.org (130.89.148.14)' can't be established.
ED25519 key fingerprint is SHA256:bNnjFMvzsNhkwzRHwGRbTIUM4XzUjlLrBl/7MzCbndw.

SSHv2 Client: New Keys

With the New Keys message, the client means:

Hey server! All the following messages from me will use the ciphers we just negotiated.

The server must also send a New Keys message to the client.

My main reference is the RFC for the SSH Transport Protocol: https://www.rfc-editor.org/rfc/rfc4253. This is the lowest layer of SSH, on which all other SSH services (user authentication, shell, X11 forwarding, etc) are based.