Host keys

Why this page exists

The first time you connect to any SSH server, your client asks whether to trust a key it has never seen. Almost everyone types yes without checking, because there is usually nothing to check against — and that one moment is the only opportunity to detect a machine-in-the-middle.

Publishing the fingerprints over HTTPS gives you a second, independent channel: an attacker would have to compromise both this web certificate and your SSH connection at the same time. That is the entire mechanism, and it is worth using on infrastructure you actually care about — a fingerprint in a README, in your configuration management, or in DNS as an SSHFP record.

Verify before you accept:

ssh-keyscan ssh.rocks 2>/dev/null | ssh-keygen -lf -

Compare the output with the table above. If they differ, do not connect.

What to do when a host key really has changed

The loud warning means the key is not the one you saw last time. Usually the server was rebuilt; sometimes it is not. The reflex to avoid is ssh-keygen -R followed by an unexamined yes, which is indistinguishable from accepting an attacker. Confirm the new fingerprint through some channel the SSH connection does not control — a console, a provider dashboard, a page like this one — and only then remove the old entry.