SSH Handshake and Host Key Authentication

SSH begins with a TCP connection to port 22. Once established, both client and server exchange version strings such as SSH-2.0-OpenSSH_9.3, which identifies the protocol version and implementation. This version exchange allows both sides to confirm compatibility before proceeding.

After version exchange, both parties send SSH_MSG_KEXINIT packets listing their supported algorithms. These lists cover key exchange methods, host key types, symmetric ciphers, MAC algorithms, and compression. The intersection of both lists determines the chosen algorithms for the session.

The session key is established using a key exchange algorithm such as Diffie-Hellman or ECDH. The client and server each generate ephemeral key pairs, exchange public values, and independently compute the same shared secret. This shared secret seeds the session key derivation without ever being transmitted directly.

The server proves its identity by signing the key exchange hash using its host private key. The host key can be RSA, ECDSA, or the modern Ed25519 format. The client uses the corresponding public key to verify this signature, confirming it is talking to the genuine server and not an impostor.

On the first connection to a new server, the client does not yet know the host public key. SSH displays the key fingerprint and prompts the user to accept it. This Trust On First Use model stores the key in known_hosts and detects changes on future connections, warning of possible man-in-the-middle attacks.

The safest way to verify a new server host key is through an out-of-band channel. An administrator can read the server fingerprint in person or via a verified secure channel, then compare it to what the SSH client displays. This prevents accepting a fraudulent key silently on first connection.

The known_hosts file stores lines of the form: hostname algorithm base64-key. Each entry represents a trusted server identity. When you connect to a host already in known_hosts, SSH verifies the presented key matches the stored one, refusing the connection if there is a mismatch.

After the key exchange, both sides independently derive session keys using the shared secret, exchange hash, and session identifier. Separate keys are derived for each direction of communication and for encryption versus MAC operations. This means the keys used for client-to-server traffic differ from server-to-client keys.

Once session keys are established, all subsequent SSH communication is encrypted and authenticated. The negotiated cipher, such as AES-256-GCM or ChaCha20-Poly1305, protects confidentiality, while the MAC ensures integrity. Even the username and authentication credentials are sent inside this encrypted tunnel.

RSA host keys of 2048 or 4096 bits are widely supported but slower. ECDSA keys based on NIST curves are faster but some distrust NIST curve parameters. Ed25519 keys based on Curve25519 are the modern recommendation: small, fast, strongly secure, and not reliant on NIST curve parameters. Most modern SSH servers offer Ed25519 by default.

The SSH handshake: TCP connect, version exchange, algorithm negotiation, key exchange establishing session keys, server host key verification, and user authentication. All steps after the version exchange occur inside an encrypted and integrity-protected channel established by the key exchange phase.

How does a client verify the SSH server host key on subsequent connections after the first?

In this lesson: TCP connects on port 22, version strings are exchanged, algorithm negotiation selects ciphers and key exchange methods, ECDH or DH establishes a shared secret, session keys are derived separately per direction, the server authenticates itself with its host key signature, and the client verifies against known_hosts using TOFU on the first connection.