Fix 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!' SSH Error on Linux

The Full Error

You try to SSH into a server you've connected to before, and get slapped with this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:abc123xyz...
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:42
ED25519 host key for 192.168.1.100 has changed and you have requested strict checking.
Host key verification failed.

Connection blocked. You're locked out until you sort this.

What's Actually Happening

SSH keeps a fingerprint for every server you've connected to, stored in ~/.ssh/known_hosts. On a busy sysadmin's machine, that file can have hundreds of entries. Each time you connect, SSH compares the server's current key against the stored one. Mismatch? Blocked.

The most common legitimate reasons this happens:

The server was rebuilt or reimaged — a fresh OS install generates a brand-new SSH host key
The server's IP was reassigned to a different machine
An admin manually regenerated the SSH host keys
You're hitting a load balancer and landing on a different backend node than last time
The server migrated to a new cloud instance (AWS EC2 replacement, GCP rebuild, etc.)

And yes — in rare cases — it could be a real man-in-the-middle attack. If you're unsure what changed on the server, check with your team before proceeding.

Fix 1: Remove the Offending Key (Quick)

The error tells you exactly which line in known_hosts is causing trouble. In the example above: line 42. Nuke it with ssh-keygen -R:

# Remove by hostname
ssh-keygen -R hostname

# Remove by IP address
ssh-keygen -R 192.168.1.100

# Remove by hostname:port (non-standard port)
ssh-keygen -R [hostname]:2222

The old entry gets deleted. A backup lands at ~/.ssh/known_hosts.old. Now reconnect — SSH will ask you to accept the new fingerprint:

ssh user@192.168.1.100

The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:newfingerprint...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.100' (ED25519) to the list of hosts.

Fix 2: Edit known_hosts Manually

No access to ssh-keygen -R, or need more surgical control? The error output gives you the line number — say, line 42. Delete it directly:

sed -i '42d' ~/.ssh/known_hosts

Or just open the file in your editor and remove the line starting with the server's hostname or IP. Same result.

Fix 3: One-Time Connection Without Updating known_hosts

Need in right now without touching known_hosts? Two flags handle it:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@192.168.1.100

This skips host key verification entirely — for this session only. Don't make it permanent. It defeats the whole point of host key checking. Use it only when you're certain you're hitting the right machine and need to move fast.

Fix 4: Automation Scripts and Ansible

Running Ansible playbooks or scripts against multiple servers with rotating keys? Disable strict host checking per-host in ~/.ssh/config:

Host 192.168.1.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Better yet, scope it to a specific environment with a safer setting:

Host staging-*.example.com
    StrictHostKeyChecking accept-new
    UserKnownHostsFile ~/.ssh/known_hosts_staging

StrictHostKeyChecking accept-new auto-accepts keys for hosts you've never seen before, but still blocks if a known key changes. That's the sweet spot for staging environments.

Verify the Fix

Once you've removed the old key and accepted the new one, run a quick sanity check:

ssh user@192.168.1.100 'hostname && uptime'

Confirm the new key is stored correctly:

ssh-keygen -F 192.168.1.100

# Host 192.168.1.100 found: line 42
192.168.1.100 ED25519 AAAAC3NzaC1lZDI1NTE5AAAA...

Want to manually verify the fingerprint? Console into the server (not via SSH) and run:

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

That fingerprint should be byte-for-byte identical to what SSH showed during the connection prompt.

If It Keeps Happening

Getting this error every single reconnect? That points to a structural problem, not a one-off key change:

Load balancer with multiple backends — each backend has its own host key. Fix: configure all backends to share the same host key, or use a floating IP pinned to one backend.
Docker containers restarting — every new container spawns a fresh SSH host key. Fix: mount /etc/ssh as a persistent volume so keys survive restarts.
Cloud autoscaling — AWS Auto Scaling, GCP managed instance groups, and similar services spin up fresh instances with new keys. Fix: bake the SSH host keys into your AMI or machine image, or restore them from a secrets manager (AWS Secrets Manager, HashiCorp Vault) at boot.

Prevention

Got servers you manage yourself? Back up their host keys right after the initial setup:

sudo tar czf /root/ssh-host-keys-backup.tar.gz /etc/ssh/ssh_host_*

Next time you rebuild that server, restore the keys before starting sshd. Your clients' known_hosts entries stay valid. Nobody sees the scary warning.