Summary

  • SSH turns the first key exchange hash into the session identifier. The value is derived from the negotiated transcript; neither endpoint simply declares it.
  • Rekeying can replace algorithms, traffic keys, initialization vectors, compression and even the server host key, while the original session identifier remains. New protection does not automatically mean new higher-layer state.
  • Public-key authentication signs the session identifier together with the account, service, method, algorithm and key. That blocks cross-session replay, but a valid signature still does not grant a shell, a forwarding rule or any other operation without server-local authorization.

A long connection needed more than one set of keys

Secure remote login has two kinds of continuity to manage. A conversation may last for hours, carry several logical channels and accumulate application state. The encryption keys protecting its packets should not necessarily last as long.

If replacing keys also destroyed every higher-layer association, routine rekeying would close shells, interrupt transfers and abandon forwarding channels. If replacing keys silently created a new identity, an authentication statement made before the change could become detached from the connection it was meant to authorize.

SSH version 2 answered by separating its work into layers. RFC 4251 describes a transport protocol that authenticates the server and protects the byte stream, a user-authentication protocol above it, and a connection protocol that multiplexes shells, subsystems and forwarded streams. The split is not decorative. It lets transport protection change while the protocols above continue to know which conversation they inhabit.

The bridge between those layers is a value the user never chooses and the server never announces as a friendly session name.

The name was constructed from the exchange

Each side begins key exchange with SSH_MSG_KEXINIT. The packet contains a random cookie and ordered lists for key exchange, server host key, encryption, integrity, compression and other choices. The selected item in each category is the first client-preferred option that both sides support under the method's conditions.

Negotiation alone does not establish a secure channel. The chosen key-exchange method also produces a shared secret K and an exchange hash H. In the original finite-field Diffie–Hellman construction, H covers both protocol identification strings, both raw KEXINIT payloads, the server host key, the two ephemeral exchange values and the shared secret.

That composition matters. Change a version string, an algorithm offer, the server key or an ephemeral input, and the transcript being hashed is different. The value is therefore not an assertion such as “session 47.” It is a compact consequence of what the endpoints actually negotiated and computed.

The random cookies contribute unpredictability. They do not give either side unilateral naming power, because both KEXINIT packets enter the hash. The shared secret is not the identifier either. SSH can expose the session identifier without turning it into a credential; possession of the identifier does not reveal K or grant the ability to calculate valid traffic protection.

The host signature answered a narrower question

The server signs the exchange hash using the host key selected during negotiation. A successful check shows that the holder of that private host key signed this exchange transcript. It also protects the algorithm negotiation from being silently rewritten on the path.

It does not, by mathematics alone, prove that the public key belongs to the hostname the user intended. The client still needs a trust rule: a saved host-key association, a certificate-based system, a verified fingerprint or another configured method. Accepting an unfamiliar key without verification may produce a perfectly valid signature from the wrong machine.

This is the first important authority boundary. The exchange hash records protocol evidence. The host signature connects that evidence to one key. The client's trust configuration connects the key to an intended server name. Collapsing those three steps into “SSH authenticated the server” erases where an operational decision still occurs.

Only the first exchange hash became the session identifier

RFC 4253 gives H two jobs in the first key exchange. It participates in deriving encryption and integrity keys, and it becomes session_id, the unique identifier for that connection. Later exchanges still produce a fresh shared secret and exchange hash for fresh protection, but they do not replace session_id.

Rekeying is otherwise allowed to be substantial. Either party can initiate it. Algorithms may change. The host key may change. All keys and initialization vectors are recalculated; encryption and compression contexts are reset after the new-keys boundary. Yet the server remains the server, the client remains the client, and the session identifier stays fixed.

That is not a claim that nothing important changed. A new host key may demand a new trust evaluation. A weaker negotiated method may be unacceptable. A failed rekey can end the connection. The invariant says something narrower: successful transport renewal does not manufacture a new higher-layer conversation.

Nor does the identifier survive a replacement connection. Reconnect after TCP loss and the new initial exchange produces a new H. Applications may restore files, terminals or jobs by their own mechanisms, but they cannot call the new transport the same SSH session merely because the user and host names match.

User authentication signed the connection into the request

The fixed value becomes useful when the client proves possession of a user private key. RFC 4252 does not define that proof as a signature over the username alone. The signed byte sequence begins with the session identifier and continues with the exact SSH_MSG_USERAUTH_REQUEST: message number, user name, requested service, method name, a boolean, public-key algorithm and public-key blob.

An attacker who records that signature cannot place it unchanged into another connection. The other connection has a different first exchange hash and therefore a different session identifier. Altering the account, service, method, algorithm or key also changes the signed statement.

This design keeps three questions distinct. Does the signature verify for the submitted key? Is that key acceptable for this claimed account? Has the server's authentication policy, perhaps requiring another method, been completed? One valid cryptographic calculation does not answer all three.

Host-based authentication uses the same connection-binding pattern with additional client-host and client-user fields. Again, the signature proves possession in the context named by the request. The server must still decide whether the host key belongs to the named client and whether that host and user may log in.

Authentication success did not pre-authorize every channel

After the server sends SSH_MSG_USERAUTH_SUCCESS, the requested service can start. It is tempting to read that packet as a general grant. The architecture refuses that shortcut.

Local policy selects acceptable authentication methods and combinations for each user. It also governs later operations: starting a shell, invoking a subsystem, opening a port forward, accepting an agent-forwarding request or reaching a particular destination. Some of those decisions cannot even be made during authentication because the client has not yet said which channel it will request.

The session identifier therefore supplies binding, not entitlement. It lets a higher layer say, “this proof belongs to this protected conversation.” It does not let that layer say, “every future action in the conversation is approved.” A stable context can carry many separately authorized operations.

This distinction also bounds audit claims. A log containing the session identifier and a successful public-key method can associate an authentication exchange with a transport. It cannot, without channel and policy records, prove which commands ran, which forwarding requests were allowed or what application data meant.

Algorithms aged while the boundary remained

The 2006 documents named algorithms that did not all remain suitable. That did not require redesigning the cross-layer binding.

RFC 8332 added RSA signatures using SHA-256 and SHA-512 for both server and client authentication. Existing RSA public-key material could keep its ssh-rsa key format while a different algorithm name selected the stronger signature procedure. Key bytes, signature algorithm and the statement being signed remained separate objects.

RFC 9142 later revised implementation recommendations across SSH key-exchange methods, moving away from SHA-1-based choices and requiring stronger alternatives in its recommendation set. The registry and recommendations could evolve because negotiation carried named algorithms. The session rule remained: the first accepted exchange fixes the connection's binding context; later key exchanges renew protection inside it.

That continuity should not be mistaken for approval of obsolete methods. A session identifier built by a weak or wrongly trusted exchange faithfully binds later authentication to a weak or wrongly trusted beginning. Binding preserves context; it does not repair the quality of the context.

Evidence has to retain the layer that produced it

Five records may all be called “SSH identity” in an imprecise dashboard: host name, host key, exchange hash, session identifier and user key. They answer different questions.

The host name is the intended destination label. The host key is a cryptographic principal that must be associated with that label. An exchange hash describes one negotiated key exchange. Its first value becomes a connection-scoped identifier. A user key supports a method of proving possession for one account-and-service request. None is a substitute for the server's authorization rule or the application's record of work performed.

The standards establish these semantics and their algorithm history, not the behavior of every deployment. They do not prove that a particular client checks host keys, that a server rotates keys on schedule, that SHA-1 has disappeared, that local policy is sensible or that a successful login caused any specific command to execute.

SSH's durable move was modest but exact. It allowed the keys to age without letting the conversation forget its beginning. The first hash did not become a universal identity. It became the evidence boundary that later proofs could name.