Host key verification failed means the SSH server’s fingerprint doesn’t match what’s stored in your ~/.ssh/known_hosts file.
Why this happens
SSH stores a fingerprint of every server you connect to in ~/.ssh/known_hosts. On subsequent connections, it compares the server’s key against the stored one. If the key changed — because the server was rebuilt, migrated, or (rarely) someone is intercepting traffic — SSH refuses the connection to protect you from man-in-the-middle attacks.
What causes this error
- First connection — the server isn’t in known_hosts yet
- Server was rebuilt — new server, new key, but same hostname
- Man-in-the-middle — someone is intercepting your connection (rare but serious)
Fix 1: Remove the old key and reconnect
ssh-keygen -R hostname.com
ssh user@hostname.comFix 2: Accept the key automatically (CI/CD)
ssh-keyscan -H github.com >> ~/.ssh/known_hosts
ssh-keyscan -H gitlab.com >> ~/.ssh/known_hostsFix 3: Skip verification (NOT recommended for production)
ssh -o StrictHostKeyChecking=no user@hostname.comOnly use this for throwaway environments. Disabling verification removes protection against MITM attacks.
Alternative solutions
Use ssh-keygen -F hostname.com to check if a host is already in your known_hosts before connecting. In Ansible or automation, use the ssh_known_hosts module to manage keys declaratively.
For GitHub/GitLab, you can verify the fingerprint against their published keys before adding:
ssh-keyscan github.com 2>/dev/null | ssh-keygen -lf -When to be concerned
If you get this error connecting to a server you’ve connected to before and nothing changed (no rebuild, no migration), investigate. It could indicate a security issue.
Prevention
- After rebuilding a server, proactively update known_hosts:
ssh-keygen -R host && ssh-keyscan -H host >> ~/.ssh/known_hosts. - Pin host keys in your SSH config with
VerifyHostKeyDNS yesif your DNS supports SSHFP records.
Related: How SSH Actually Works · SSH Connection Timed Out · Git: Permission Denied (publickey) · SSH cheat sheet