Introduction

Host key verification failed means your SSH client already knows a host key for that name or IP, and the server is now presenting a different one. Sometimes that is expected after a rebuild or migration. Sometimes it is exactly the warning you must not ignore. The right response is to confirm whether the key changed for a legitimate reason before replacing the old trust record.

Symptoms

  • SSH refuses connection before password or key auth starts
  • The warning says remote host identification has changed
  • You recently rebuilt, reinstalled, or moved the server behind the same hostname
  • Multiple users start seeing the same warning at the same time

Common Causes

  • The server was rebuilt and generated a new SSH host key
  • DNS or IP changed and the hostname now points to a different machine
  • A stale entry remains in known_hosts from an older environment
  • A real man-in-the-middle or routing issue is presenting the wrong host key

Step-by-Step Fix

  1. 1.Decide whether the key change is expected
  2. 2.Check recent rebuilds, instance replacements, IP changes, or infrastructure cutovers before removing trust data.
  3. 3.Verify the new host key fingerprint from a trusted path
  4. 4.Compare the fingerprint from the server console or administrator with what SSH is reporting.
bash
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
  1. 1.Remove only the stale known_hosts entry
  2. 2.If the new fingerprint is legitimate, delete the old entry cleanly and reconnect.
bash
ssh-keygen -R server.example.com
ssh-keygen -R 192.0.2.10
  1. 1.Reconnect and validate the new fingerprint
  2. 2.Accept the new key only after it matches the trusted fingerprint you verified.

Prevention

  • Keep host key fingerprints documented for critical systems
  • Preserve host keys across rebuilds when possible
  • Validate DNS and host replacement workflows before cutover
  • Treat unexpected host key changes on production systems as security events until proven otherwise