SSH says “REMOTE HOST IDENTIFICATION HAS CHANGED” — how to fix it safely
Usually it means the server was rebuilt and the fix is ssh-keygen -R. When it isn't, it matters. Both cases, plus the accept-new pattern for provisioning scripts.
“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” means the server at that address presented a different host key than the one saved in your ~/.ssh/known_hosts. If you just rebuilt, recreated, or reinstalled that server — the overwhelmingly common cause — the fix is ssh-keygen -R <host> to forget the old key, then reconnect and accept the new one. If you didn’t change anything, stop and investigate before connecting.
What SSH is actually checking
Every SSH server has a host key — its cryptographic identity. The first time you connect, your client saves it to ~/.ssh/known_hosts; on every later connection it checks the server still presents the same one. Per the OpenSSH manual, when a host’s identification changes, ssh warns and disables password authentication, because a changed key is exactly what a man-in-the-middle attack would look like. The scary formatting is deliberate. The check is doing its job — your only decision is why the key changed.
The benign cause: the server is genuinely new
A host key lives on the server’s disk, so anything that replaces the disk replaces the identity: deleting and recreating a cloud server, reinstalling the OS, restoring some kinds of images. The address stays; the machine behind it doesn’t. Cloud IP recycling makes this dramatic — providers reuse addresses fast. We provision and delete agent servers constantly, and during one day of testing, Hetzner handed us the same IP for three different servers in a row — three “identification has changed” warnings, all correct, all harmless. You can even inherit the address of a stranger’s dead server and see the warning on your very first connect.
The fix, when you know the server changed:
ssh-keygen -R <hostname-or-ip>That removes the stale entry; reconnect and verify-accept the new key. Belt-and-braces (and genuinely worth it the first time you do this): compare the fingerprint you’re accepting against the one shown in your cloud provider’s console for the new server.
When not to shrug it off
If the key changed and you have no explanation — no rebuild, no reinstall, no provider maintenance notice — treat the warning as real until proven otherwise: don’t connect and type credentials, check from a second network (a hostile Wi-Fi gateway is the classic MITM position), and verify the fingerprint out-of-band via the provider console. The warning is annoying precisely so that the one time it matters, you can’t miss it.
For people scripting server builds
Automation hits this warning constantly, because recreating servers is what automation does — and a strict-checking failure will kill a set -e provisioning script at the first connect. The clean pattern we settled on for fresh builds: clear the old entry (ssh-keygen -R) at create time, then connect with StrictHostKeyChecking=accept-new — which accepts an unknown host’s key on first contact but still hard-fails if a known key ever changes. Never ship StrictHostKeyChecking=no anywhere durable: it waves through changed keys silently, which converts the one warning that can save you into nothing at all. (More on what an agent’s server should look out of the box: the login-attempt noise in your logs and the safe-hosting checklist.)