Accepting the correct SSH host key in PuTTY prevents silent server impersonation and reduces the risk of credential theft during man-in-the-middle attacks. A cached host key also eliminates repeat trust prompts, making unexpected server identity changes obvious during later connections.
An SSH server proves its identity with a host key during the initial handshake, and PuTTY validates that identity by comparing the presented key against a locally cached copy. When no cached key exists, PuTTY displays a fingerprint in a PuTTY Security Alert dialog, and the accept option stores the key for the current Windows user under
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
.
Host key caching is only trustworthy when the fingerprint is verified out-of-band (administrator-provided fingerprint, console access, provisioning notes), not from the same network path being protected. Rebuilt systems, key rotation, load balancers, or connecting by a different hostname can legitimately change the presented key and trigger warnings, but the same warnings can also indicate active interception, so treat mismatches as security incidents until proven otherwise.
Host key caching is tied to the exact host string plus port, so server, server.example.com, and 192.0.2.10 cache separately.
Match the fingerprint for the same key type shown in the dialog (ED25519, ECDSA, or RSA), not a different algorithm.
Cancel the connection when the fingerprint cannot be verified or does not match the trusted value.
Accepting an unverified host key can permanently trust the wrong server and expose passwords, sessions, or forwarded traffic.
Host key mismatch warnings can indicate server rebuilds or key rotation, but can also indicate an active man-in-the-middle attack; avoid updating cached keys without independent verification.