Stop the “REMOTE HOST IDENTIFICATION HAS CHANGED!” error by cleaning ~/.ssh/known

Why the “REMOTE HOST IDENTIFICATION HAS CHANGED!” error appears

The message “REMOTE HOST IDENTIFICATION HAS CHANGED!” shows up every time you try to SSH into a host that reports a different key than the one you stored in ~/.ssh/known_hosts.
It’s a sanity check that protects you from man‑in‑the‑middle attacks, but it can also be a pain when you’re just redeploying a server or spinning up a VM that got a new IP.

What the message really means

When you first connect to a host, SSH stores its public key fingerprint in known_hosts.
On the next connection it compares the fingerprint it receives from the server with the one in the file.
If they don’t match, the client aborts and prints the warning.

You’re not seeing a “host key changed” because the key was altered – you’re seeing that the key you have on record no longer matches what the server is presenting.

Why it shows up

Server rebooted with a new key – Many cloud images generate a fresh host key on every boot.
IP reassignment – You connect to a different machine that happens to have the same IP.
DNS hijack or spoof – A malicious actor is pointing the hostname at a different machine.
SSH configuration changes – sshd_config was edited to use a different key file.
User error – You accidentally edited known_hosts or connected to the wrong host.

Common causes in practice

Docker / LXC containers: Each container starts with a new key unless you explicitly copy it.
KVM / VirtualBox: Snapshots that clone a running VM will duplicate the key, so the next boot looks “changed” to the client.
Bare‑metal redeploy: Reflashing a disk can replace the host key.
Managed hosts (AWS, GCP, Azure) often regenerate keys on instance recreation.

Fixing the issue

If you know the host is legitimate, just delete the old entry:

# Remove a specific host from known_hosts
ssh-keygen -R example.com

# Or delete the whole file and start fresh (be careful!)
rm ~/.ssh/known_hosts

After that, reconnect and accept the new key:

ssh user@example.com
# You'll see a fingerprint prompt; type "yes" to add it

If you’re unsure, compare the fingerprint you see with what the server actually reports (you can ask an admin or check the key file on the host). On the server side:

# View the current host key
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

Prevention: Make the change less painful

Use a fixed key
Copy a known good key into the container or VM image so it never changes.
Centralize key management
Store the host key in a version‑controlled config repo and inject it at startup.
Use SSH certificates
Instead of per‑host keys, sign a key with your own CA. The client trusts the CA, not each host.
Automate known_hosts updates
Tools like ssh-keyscan can fetch a fresh fingerprint and append it automatically:
```
ssh-keyscan -H example.com >> ~/.ssh/known_hosts
```
Lock the hostname/IP
In sshd_config set HostKey to a path that never changes, and avoid letting the OS generate a new one.

A quick sanity check

Before blindly accepting a new key, run:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

on the server, then compare the output to the one displayed by your client. If they match, you’re safe. If they don’t, investigate.

TL;DR

The error means your client’s stored key doesn’t match the server’s current key.
It usually shows up after a reboot, container start, or IP change.
Delete the offending line in known_hosts and reconnect.
For long‑term peace of mind, keep host keys stable or use SSH certificates.

Stop the “REMOTE HOST IDENTIFICATION HAS CHANGED!” error by cleaning ~/.ssh/known_hosts.