SSH: Host key verification failed
Fix SSH "Host key verification failed" safely by comparing fingerprints instead of disabling StrictHostKeyChecking.
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.