A Calm SSH Host Key Check
Handle an SSH host-key warning without training yourself to delete the evidence and try again.
Photo: Unsplash.
REMOTE HOST IDENTIFICATION HAS CHANGED is not an instruction to erase a line. It is SSH telling you that the server presented a different identity than the one previously trusted.
Sometimes the explanation is harmless: the VPS was rebuilt, its SSH host keys were regenerated, or an IP address was reassigned. Sometimes the warning is exactly what protects you from connecting through the wrong machine or an interception attempt.
First, stop and identify what changed. If you control the server, obtain its fingerprint through a separate trusted path: the provider’s console, a management network, or someone already logged in.
On the server, print the public key fingerprints:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pubOn the client, see the stored entries without editing the file manually:
ssh-keygen -F server.example.com
ssh-keygen -F 203.0.113.24Compare the fingerprint shown by the new connection with the value obtained from the trusted console. Only after they match should you remove the stale entry:
ssh-keygen -R server.example.com
ssh-keygen -R 203.0.113.24Reconnect and verify the fingerprint one more time before accepting it.
Do not use StrictHostKeyChecking=no as a permanent fix. It trades a visible interruption for silent trust in whatever answers at that address. For automated fleets, host certificates or a deliberately managed known_hosts file scale better than disabling verification.