← Debugging Guides

阅读中文版本

SSH: Host key verification failed

Fix SSH "Host key verification failed" safely by comparing fingerprints instead of disabling StrictHostKeyChecking.

intermediatedebuggingsshsecuritylinux

Symptoms

  • WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
  • Host key verification failed
  • Connections in CI fail for a host that worked before

Possible causes

  • The server was rebuilt and generated a new host key
  • The known_hosts entry is stale after a host migration
  • A man-in-the-middle or IP reuse presents a different key
  • CI containers start with an empty known_hosts

Diagnosis steps

Compare the presented host key fingerprint

ssh-keyscan -t ed25519 host | ssh-keygen -lf -

Interpretation

Match the fingerprint against the value published by the server operators before accepting it.

Check the offending known_hosts line and its line number

Interpretation

The warning names the file and line so you can remove only the stale entry.

Confirm with the host owner that the key changed

Interpretation

A legitimate rebuild is documented; an unexplained change warrants investigation.

Root cause

SSH pins the server host key in known_hosts to detect impersonation. When the server presents a different key — after a rebuild, an IP being reassigned, or an actual interception — verification fails. This is a security feature working as intended, not a bug, so the fix is to verify the new key, not to disable checking.

Fix

Confirm the new fingerprint out of band, then remove the stale line with ssh-keygen -R host and let the client learn the new key. In CI, seed known_hosts with the verified key using ssh-keyscan into a controlled file. Avoid StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null, which remove protection entirely.

Verify the fix

Reconnect; the session opens without the warning, and the new fingerprint in known_hosts matches the one you verified with the host owner, confirming the key change was legitimate.

Symptoms

SSH refuses to connect with Host key verification failed or a REMOTE HOST IDENTIFICATION HAS CHANGED warning. It often happens after a server rebuild or IP reuse.

Diagnosis

Verify the fingerprint before changing anything:

ssh-keyscan -t ed25519 host 2>/dev/null | ssh-keygen -lf -

Compare against the fingerprint published by the server team; never accept a new key blindly.

Fix

Remove the stale entry and learn the verified key:

ssh-keygen -R host
# after confirmation, seed known_hosts
ssh-keyscan -t ed25519 host >> ~/.ssh/known_hosts

In CI, commit a controlled known_hosts rather than disabling verification.

Verification

Reconnect; the session opens with no warning, and the fingerprint now stored in known_hosts matches the verified value, confirming the key change was legitimate and the connection is trusted.