RFC 4253: 7.2. Output from Key Exchange
The key exchange produces two values: a shared secret K, and an
exchange hash H. Encryption and authentication keys are derived from
these.
Each key exchange method specifies a hash function that is used in
the key exchange. The same hash algorithm MUST be used in key
derivation. Here, we'll call it HASH.
Overloaded.
RFC 4253: Section 7. KeyExchange
Key exchange (kex) begins by each side sending name-lists of
supported algorithms. Each side has a preferred algorithm in each
category, and it is assumed that most implementations, at any given
time, will use the same preferred algorithm. Each side MAY guess
which algorithm the other side is using, and MAY send an initial key
exchange packet according to the algorithm, if appropriate for the
preferred method.
The guess is considered wrong if:
o the kex algorithm and/or the host key algorithm is guessed wrong
(server and client have different preferred algorithm), or
o if any of the other algorithms cannot be agreed upon (the
procedure is defined below in Section 7.1).
Otherwise, the guess is considered to be right, and the
optimistically sent packet MUST be handled as the first key exchange
packet.
However, if the guess was wrong, and a packet was optimistically sent
by one or both parties, such packets MUST be ignored (even if the
error in the guess would not affect the contents of the initial
packet(s)), and the appropriate side MUST send the correct initial
packet.
A key exchange method uses explicit server authentication if the key
exchange messages include a signature or other proof of the server's
authenticity. A key exchange method uses implicit server
authentication if, in order to prove its authenticity, the server
also has to prove that it knows the shared secret, K, by sending a
message and a corresponding MAC that the client can verify.
The key exchange method defined by this document uses explicit server
authentication. However, key exchange methods with implicit server
authentication MAY be used with this protocol. After a key exchange
with implicit server authentication, the client MUST wait for a
response to its service request message before sending any further
data.
10. Service Request
After the key exchange, the client requests a service. The service
is identified by a name. The format of names and procedures for
defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS].
If the server rejects the service request, it SHOULD send an
appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
When the service starts, it may have access to the session identifier
generated during the key exchange.
RFC4253: 7.3. Taking Keys Into Use
Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
This message is sent with the old keys and algorithms. All messages
sent after this message MUST use the new keys and algorithms.
When this message is received, the new keys and algorithms MUST be
used for receiving.
The purpose of this message is to ensure that a party is able to
respond with an SSH_MSG_DISCONNECT message that the other party can
understand if something goes wrong with the key exchange.
RFC4253: 7.3. Taking Keys Into Use
Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
This message is sent with the old keys and algorithms. All messages
sent after this message MUST use the new keys and algorithms.
When this message is received, the new keys and algorithms MUST be
used for receiving.
The purpose of this message is to ensure that a party is able to
respond with an SSH_MSG_DISCONNECT message that the other party can
understand if something goes wrong with the key exchange.
