3.1.2 Key-exchange process and methods
The initial key-exchange process is started right after exchanging version strings and terminates after a few packet exchanges. During most of the lifetime of a session, no key-exchange process is running.
Additional key-exchange processes can be initiated by either side at any time. This is generally requested after some amount of transferred data or after a delay. Processing of other messages is postponed during a key-exchange so that the process is transparent to higher layers of the protocol.
The key-exchange process has several purposes:
It negotiates the multiple algorithms that will be used to secure the connection and compress the packets. The protocol supports using a different set of algorithms for each directions, even if this is rarely used in practice.
Note that the signature algorithm possibly involved in the user authentication is not negotiated during the key-exchange process.
It creates a shared secret and derives the symmetric session keys that will be used to encrypt and authenticate the binary packets using the selected algorithms.
It authenticates the server host using the selected signature algorithms. The client application is involved in the process because it has to decide if the host key of the server is known and trusted. This is generally achieved by keeping track of known keys in a database and asking the user to check and compare the fingerprint of yet unknown keys.
Because public key cryptography is involved, the process may be computationally intensive. Depending on the selected algorithm, it can be costly, especially on embedded platforms.
The key-exchange process starts when the two peers each transmit an SSH_MSG_KEXINIT packet. This packet contains lists of supported algorithm names, allowing both sides to select a matching set by applying the specified selection rules. For each type of algorithm, the first algorithm in a client list that appears somewhere in the associated server list is retained. Among the various types of algorithms selected, a key-exchange method is retained and executed immediately.
This key-exchange method employs its own specific crypto in order to create the shared secret. It may however rely on a separate signature algorithm in order to authenticate the server. To achieve this, it needs to use specific packet exchanges until the end of the process. Because new key-exchange methods can be developed, this part of the protocol is not specified in a fixed way.