Introduction

When SSH detects that a server's host key no longer matches the key stored in ~/.ssh/known_hosts, it displays a stark warning: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! This is SSH's primary defense against man-in-the-middle (MITM) attacks. However, legitimate host key changes also occur during server rebuilds, OS reinstalls, SSH daemon reconfiguration, or key rotation. Administrators must distinguish between the two before removing the old key.

Symptoms

  • SSH connection refused with: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
  • IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  • Offending ECDSA key in /home/user/.ssh/known_hosts:42
  • Host key verification failed.
  • Fingerprint mismatch shown in the error message

Common Causes

  • Server OS reinstalled or VM rebuilt with new host keys
  • SSH host keys manually regenerated with ssh-keygen -A
  • Server IP address reassigned to a different machine
  • Actual man-in-the-middle attack on the network path
  • Load balancer or proxy changed, presenting a different host key

Step-by-Step Fix

  1. 1.Verify the key change is legitimate before proceeding:
  2. 2.Connect through an out-of-band channel (console, different network) and check the server's actual host key fingerprints:
  3. 3.```bash
  4. 4.# On the server (via console):
  5. 5.ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
  6. 6.ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
  7. 7.ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
  8. 8.`
  9. 9.Compare with the fingerprint shown in the SSH warning:
  10. 10.The warning message includes the new key's fingerprint. If it matches the server's actual key, the change is legitimate.
  11. 11.Remove the old offending key from known_hosts:
  12. 12.```bash
  13. 13.# Remove the specific line (shown in the error message)
  14. 14.ssh-keygen -R 192.168.1.100
  15. 15.# Or remove by line number
  16. 16.sed -i '42d' ~/.ssh/known_hosts
  17. 17.`
  18. 18.If using hashed known_hosts, remove by hostname:
  19. 19.```bash
  20. 20.ssh-keygen -R server.example.com
  21. 21.ssh-keygen -R 192.168.1.100
  22. 22.`
  23. 23.Reconnect and accept the new key:
  24. 24.```bash
  25. 25.ssh user@192.168.1.100
  26. 26.# Will prompt: "Are you sure you want to continue connecting (yes/no)?"
  27. 27.# Verify the fingerprint matches before typing yes
  28. 28.`
  29. 29.If you suspect a real MITM attack:
  30. 30.- Do NOT connect to the server
  31. 31.- Investigate the network path: traceroute 192.168.1.100
  32. 32.- Check for ARP spoofing: arp -a
  33. 33.- Use a different network (cellular, different WiFi) to verify
  34. 34.- Alert your security team immediately

Prevention

  • Use SSH certificate authorities (CA) for host key management in large environments
  • Pin host keys in configuration files: HostKeyAlgorithms ssh-ed25519
  • Monitor known_hosts changes with automated scripts
  • Use UpdateHostKeys in ssh_config to automatically accept rotated keys from trusted servers
  • Document host key fingerprints during initial server provisioning for future verification