Summary

  • RFC 4251 describes a client storing a host name and its public key locally after an initial connection, then comparing that key on later visits.
  • OpenSSH's known_hosts file gives that comparison a durable home. Its client can prompt for an unfamiliar key and refuse a changed one; authenticated servers can announce additional keys before a planned rotation.

The first time a person connects to a server over SSH, the server presents a host key. The client can test the cryptographic exchange, but it needs a way to know whose key it has just seen. The SSH architecture published as RFC 4251 in January 2006 lays out two possibilities: keep a local association between a host name and a public key, or rely on a trusted certification authority. The local option needs no central address book. It does need someone to make the introduction.

The RFC describes an expedient introduction. Accept a host key on the first connection, save it, and compare it with the key offered on every future connection to that host. The machine gains a memory. The first meeting still deserves a fingerprint checked through another channel: a stranger who intercepts that meeting can hand over a convincing key of his own. Once a legitimate key has been recorded, though, a different key cannot walk in wearing the same host name unnoticed.

In OpenSSH, the memory lives in ~/.ssh/known_hosts. The OpenBSD ssh(1) manual explains how the client records keys for known hosts and presents a prominent warning when a host key changes. The warning is a useful interruption. It says the saved introduction and today's cryptographic visitor disagree. The server may have been rebuilt or had its key replaced; an impostor is another possibility. The protocol cannot decide which story is true from the mismatch alone. It makes the disagreement impossible to miss.

The OpenBSD ssh_config(5) manual gives operators distinct ways to handle that moment. With StrictHostKeyChecking=ask, the client asks before recording a new host and refuses a changed key. accept-new records a new key automatically but still refuses a changed one. yes requires the new key to be installed deliberately. These choices adjust the first meeting. The remembered key still has a say at the second.

Key changes can be planned. The same configuration manual describes UpdateHostKeys: after the client authenticates a server it already trusts, that server can announce additional host keys. A replacement can enter the notebook before the old key leaves. The order matters. The client learns the new face from someone whose old face it has already recognized.

There is a tempting shortcut for filling the notebook. ssh-keyscan can collect public host keys and format them for known_hosts. Its manual says the scan cannot establish who really owns the keys it collects; a network interceptor can substitute their own. The notebook is only as good as the introduction that filled it. SSH's clever trick was to make future introductions answer to the first one, then give the operator a loud reason to investigate when the story changes.