PuTTY Warning: Potential Security Breach (How to Fix It)

What you're seeing

A dialog box before the login prompt:

WARNING - POTENTIAL SECURITY BREACH!

The server's host key does not match the one PuTTY has cached in
the registry. This means that either the server administrator has
changed the host key, or you have actually connected to another
computer pretending to be the server.

The new ssh-ed25519 key fingerprint is:
ssh-ed25519 255 SHA256:kfL4okDT1DspyHZQ4X3AQ8qLYbNL7cioZbGpiZTC5wo

with Accept, Connect Once, and Cancel buttons (older versions: Yes/No/Cancel). A related dialog with the same layout says "the server's host key is not cached" instead; that one is normal on a first connection and only asks you to confirm a key PuTTY has never seen. This page is about the breach warning, where a cached key stopped matching.

OpenSSH shows the same situation as REMOTE HOST IDENTIFICATION HAS CHANGED! followed by Host key verification failed. Same meaning, different client; see SSH Host Key Verification Failed for the command-line version.

What's causing this error

Every SSH server proves its identity with a host key. The first time you connect, PuTTY stores that key's fingerprint, filed under the host name and port. On every later connection it checks the server's key against the cache, and this warning means they no longer match.

The benign explanations, which cover nearly all real cases:

1. The server was reinstalled or rebuilt. A fresh OS install generates fresh host keys. Rebuilding a VPS, re-imaging a Raspberry Pi, or recreating a cloud instance all trigger it.
2. The IP address changed hands. You connect by IP, the cloud provider or your DHCP server gave that address to a different machine, and that machine has its own keys.
3. A load balancer with multiple backends. Each backend has its own host key unless the admin synchronized them, so the "server" legitimately answers with different keys on different days.
4. The admin regenerated the host keys, deliberately or via a tool that did it as a side effect.

And the malicious one, which is the entire reason the dialog exists:

1. A man-in-the-middle. Something between you and the server is terminating your SSH connection and presenting its own key. Rare, but this warning is the only thing standing between you and typing your credentials into an attacker's box.

The dialog can't tell these apart. Only out-of-band verification can.

How to fix it

Step 1: Verify the new fingerprint out-of-band

Get the server's real fingerprint through a channel that is not this SSH connection: the hosting provider's web console (DigitalOcean Console, AWS EC2 Serial Console, Proxmox/VMware console), or physically at the machine. There, print the host key fingerprints:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# The server has one key per algorithm; print them all if you're not sure which is in use:
for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$f"; done

Compare the SHA256:... value against the one in the PuTTY dialog. The dialog names the key type (ssh-ed25519, rsa2, ...), so you know which line to match.

Step 2: Accept if it matches, stop if it doesn't

• Fingerprints match: the change is legitimate. Click Accept and PuTTY updates the cache; the warning won't return until the key changes again. Connect Once connects without updating the cache, useful for a load-balanced host you'll hit again with a different key.
• Fingerprints don't match, or you can't verify: click Cancel and do not log in. Especially on a network you don't control (hotel or airport Wi-Fi, a new VPN), an unexpected key change is exactly what an interception looks like. Verify from a trusted network or contact the server admin before trying again.

Never accept just to make the dialog go away on a production server you didn't expect to change. The one time it matters, it really matters.

Step 3: Clear a stale cached key if needed

PuTTY caches host keys in the Windows registry, not in a known_hosts file:

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

Open regedit, navigate there, and each value is one cached key, named like ssh-ed25519@22:myserver.com. Deleting a value makes PuTTY treat that host as brand new: the next connection shows the normal first-time prompt instead of the breach warning. Useful when a host was rebuilt and you'd rather re-verify from scratch, or when scripting cleanup across machines (reg delete works too).

Note the entries are per host name and port, so myserver.com on port 22 and on port 2222 are cached separately, and the same machine reached by IP is a third entry.

For server admins: one rebuild, many warned users

If you rebuilt a server that other people connect to, every one of them gets this warning, and you don't want to train them to click Accept blindly. Publish the new fingerprints (from the ssh-keygen -lf command above) on a channel they already trust: the internal wiki, the deploy announcement, a pinned message. Better long-term: preserve /etc/ssh/ssh_host_* across rebuilds, or manage host keys with your provisioning tool so a rebuild doesn't change identity at all.

Common edge cases