How are session keys, public/private keys generated on the ssh server and client and used?

Question

From SSH handshake process explained http://www.cathaycenturies.com/blog/?p=1635

Key Exchange

1. The client has a public & private key pair. The server has a public & private key pair.
2. The client and server exchange their public keys.
3. The client now has its own key pair plus the public key of the server.
4. The server now has its own key pair plus the public key of the client.
5. This exchange of keys is done over an insecure network.
6. The client takes its private key and the server’s public key and passes it through a mathematical equation to produce the shared secret (session key).
7. The server takes its private key and the client’s public key and passes it through a mathematical equation to produce the shared secret (session key). Both these shared secrets are identical! This is an asymmetrical key.
8. This encrypted tunnel is used for the remainder of the session, including the next phase: User Authentication.

1. Is the exchange of public keys between the server and client done once for the following all sessions, until they are changed?

2. are the sessions keys generated on the client and on the server once per session?

   Each time they are generated, they take private keys and public keys as inputs. Does it mean that the session keys for different sessions are the same, as long as the private and public keys stay the same?

3. why does the quote say that the session keys generated on the server and on the client in the same session are "identical"?

4. the bullet 8 seems to say that user authentication happens after the session keys are generated?

   If yes, does user authentication use the session keys generated on the client and on the server, or just use the public and private keys on the client and on the server?

By the way, is there some reference about how the process goes and uses the public and private keys and session keys on the server and on the client?

Thanks.

Answer 1

1. Is the exchange of public keys between the server and client done once for the following all sessions, until they are changed?

Yes. The keys for key exchange change for every key exchange.

2. are the sessions keys generated on the client and on the server once per session?

Yes. Unless you transfer a lot of data, your session lasts long enough or you force Rekeying (or configure the rekeying to happen more frequent than needed). RekeyLimit option in server and client config.

Each time they are generated, they take private keys and public keys as inputs. Does it mean that the session keys for different sessions are the same, as long as the private and public keys stay the same?

As above. These are keys are generated just for the key exchange. They are not authentication keys nor host keys as discussed before in previous questions.

3. why does the quote say that the session keys generated on the server and on the client in the same session are "identical"?

This is point of the key exchange. I really like this picture below explaining it (from wikipedia). They are generated independently, based on the knowledge of one private key each, but the data that travel over the network (public keys) are not enough to construct this shared secret.

4. the bullet 8 seems to say that user authentication happens after the session keys are generated?

If yes, does user authentication use the session keys generated on the client and on the server, or just use the public and private keys on the client and on the server?

No. The session keys are used for encryption of the channel over the network. The point is that before key exchange, the data travel over the network insecure and anyone can intercept/modify/insert any data. After the key exchange, the data are encrypted using cipher and "authenticated" using MAC.

There is a lot information about the SSH protocol. OpenSSH project has a dedicated page with all the standards (RFC's) that are implemented for SSH protocol. Probably most important is RFC4253. Also source code of openssh can explain a lot.

I hope I made it a bit more clear. If there is something missing, let me know.