Host key changed
What “Host key changed” usually means
When PuTTY reports POTENTIAL SECURITY BREACH, the client has already attempted a network or protocol step and failed before a normal interactive shell is available. This guide explains what the message usually means on Windows clients, which local settings to verify first, and when the problem is almost certainly on the server, firewall, or DNS path rather than inside the PuTTY GUI.
PuTTY previously cached a host key for this server identity, but the key presented during the current handshake differs. That can be a legitimate rebuild or IP reuse—or an active on-path attacker. The client treats the mismatch as a potential security breach for good reason.
Independent resource: Putty.info is educational only and is not affiliated with the official PuTTY project. Compare symptoms against the official documentation for your installed version.
Symptoms you will see
Operators usually notice this failure in one of a few repeatable ways. Capture the exact dialog text, the hostname and port from the Session panel, and whether the failure happens before or after a username prompt—those details decide which checklist below applies.
- A warning dialog referencing a potential security breach or changed host key.
- Fingerprints shown in the dialog do not match your out-of-band record.
- Connections that worked yesterday suddenly warn without password or key prompts completing.
Likely causes ranked by frequency
Several independent conditions can produce the same client-facing wording. Work from the outside in: reachability first, protocol selection second, authentication third. Changing key files will not fix a TCP refusal, and opening a wider firewall will not fix a rejected public key.
- Server OS rebuild regenerated /etc/ssh/ssh_host_* keys.
- DNS now points to a different machine behind the same hostname.
- Load balancer or jump host changed backend keys without documentation.
- Malicious interception presenting a different host key.
- You edited the wrong saved session and are hitting a different environment (staging vs production).
Step-by-step client checks
Use this ordered checklist on a workstation you control. Prefer saved sessions so Host Name, Port, and Connection type stay consistent while you isolate one variable at a time.
- Stop. Do not Accept until you verify the new fingerprint with the server owner through a trusted channel.
- Compare the fingerprint to automation inventory, cloud console metadata, or a prior known-good jump host.
- Confirm Host Name and Port in Session still match the intended environment.
- If verified legitimate, remove the old cached key carefully and store the new one; document the change ticket.
- If not verified, disconnect, preserve evidence, and follow incident process—do not send passwords.
- Review /security/host-key-changed/ and /learn/host-key-warning/ before changing cache entries on shared jump workstations.
Do not paste private keys, passphrases, or production passwords into Putty.info tools or contact forms. Diagnose locally with PuTTY, Plink, PSCP, or PSFTP from an official install.
When it is a server or network issue
Administrators should publish host key fingerprints in a trustworthy channel when rebuilding. Avoid casually deleting client caches across a whole helpdesk image without explaining the migration—operators will click through warnings and train themselves to ignore the only signal that catches many attacks.
If TCP connects from another network path but fails from yours, involve the network team with traceroute/path evidence rather than repeatedly regenerating keys. If authentication fails after a banner appears, collect the server sshd logs for the same timestamp and username—client-side retries alone rarely reveal AccountLocked, Match blocks, or AllowUsers denials.
Host keys authenticate the server; user keys authenticate you. Clearing a host key cache never fixes a rejected user public key, and rotating your PPK never fixes a changed host key warning.