How to fix Host key verification failed. in SSH

SSHBEGINNERMEDIUMUpdated Jan 4, 2026· 663 views

This error occurs when SSH cannot verify the authenticity of a remote host's key because it doesn't exist in your known_hosts file or has changed. It's a security feature that prevents man-in-the-middle attacks but requires manual verification the first time you connect to a host.

Quick fix

Fixes Host key verification failed.

ssh-keygen -R hostname
ssh-keygen -R 192.168.1.100
  1. Remove the old host key from known_hosts
  2. Connect to the host to accept the new key
  3. Verify the host key fingerprint (for security)
  4. Manually remove the offending line (if ssh-keygen doesn't work)
ssh — error
ssh-keygen -R hostname
ssh-keygen -R 192.168.1.100
Host key verification failed.

What this error means

SSH maintains a file (~/.ssh/known_hosts) that stores the public keys of all remote hosts you've connected to. When you connect to a new host, SSH verifies that the host's presented public key matches the stored key. If the key is missing from known_hosts (first connection) or has changed (security concern), SSH refuses the connection to protect you from connecting to an impersonated host. This error appears when StrictHostKeyChecking is enabled (the default) and the host key cannot be verified.

Typical symptoms

  • SSH connection fails immediately with 'Host key verification failed'
  • Error message may include the line number in known_hosts: 'Offending line X'
  • First-time connections to new hosts fail unless you manually accept the key
  • Connections succeed after accepting the host key and rerunning SSH
  • Appears when connecting to a reinstalled or migrated server

Common causes

  1. Host key doesn't exist in ~/.ssh/known_hosts (first time connecting to host)
  2. Remote host's SSH key has changed (server reinstall, key rotation, or potential attack)
  3. IP address changed but ~/.ssh/known_hosts still has old key from different IP
  4. StrictHostKeyChecking enabled (default) requiring manual verification before connecting
  5. Corrupted known_hosts file with malformed entries
  6. known_hosts file has incorrect permissions preventing SSH from reading it

How to fix "Host key verification failed."

1Remove the old host key from known_hosts

Use ssh-keygen to remove the offending key entry. This is the safest approach as it automatically removes only the specific host's key:

bash
ssh-keygen -R hostname
ssh-keygen -R 192.168.1.100

Replace hostname or the IP address with your actual remote host. You can run both commands if you want to remove keys for both the hostname and IP. This command removes all RSA, ECDSA, and ED25519 keys for that host from ~/.ssh/known_hosts.

2Connect to the host to accept the new key

After removing the old key, attempt to SSH to the host again. SSH will now prompt you to verify and accept the new host key:

bash
ssh user@hostname

You'll see output like:

bash
The authenticity of host 'hostname (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdh.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes to accept. The new key is added to ~/.ssh/known_hosts and future connections won't prompt again.

3Verify the host key fingerprint (for security)

Before accepting a new host key, verify the fingerprint matches what the server administrator provided. This prevents man-in-the-middle attacks.

Get the host's SSH fingerprint from a trusted source (official documentation, console output, etc.), then when SSH prompts you, compare the fingerprints:

bash
ECDSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdh

If the fingerprint matches, type yes. If it doesn't match, type no and investigate why the key changed unexpectedly—this could indicate a compromised server.

4Manually remove the offending line (if ssh-keygen doesn't work)

If ssh-keygen -R doesn't work, you can manually edit ~/.ssh/known_hosts. The error message usually tells you the line number:

bash
Offending ECDSA key in /home/user/.ssh/known_hosts:22

Open the file and delete the offending line (in this example, line 22):

bash
nano ~/.ssh/known_hosts
# Or use sed to remove a specific line:
sed -i '22d' ~/.ssh/known_hosts

Save the file and retry the SSH connection.

5Accept the new key non-interactively (for automation only)

If you're running SSH in a script or CI/CD pipeline and can't interact with the prompt, temporarily disable strict host key checking. WARNING: This reduces security and should only be used with trusted hosts:

bash
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostname

A more balanced approach: accept only new keys and keep checking known keys:

bash
ssh -o StrictHostKeyChecking=accept-new user@hostname

This adds the key to known_hosts without prompting but still verifies it against known_hosts on future connections. This option is available in OpenSSH 7.6+.

6Check ~/.ssh/known_hosts file permissions

SSH requires the known_hosts file to have correct permissions. If permissions are wrong, SSH may fail to read it:

bash
ls -la ~/.ssh/

The known_hosts file should be readable by your user. Fix if needed:

bash
chmod 644 ~/.ssh/known_hosts

Also ensure your ~/.ssh directory itself has correct permissions:

bash
chmod 700 ~/.ssh

Advanced notes

Advanced troubleshooting:

Man-in-the-Middle (MITM) Attack Detection: SSH's host key verification is specifically designed to detect MITM attacks. If you see a "Remote Host Identification Has Changed" warning after previously connecting successfully, stop and investigate. This could mean:
- The server was legitimately reinstalled or migrated (contact administrator)
- DNS was hijacked to point to a different server
- You're behind a proxy that's intercepting connections
- A malicious entity is impersonating the server

Never blindly accept a changed key without verifying with the server administrator.

Automated Deployments and SSH: If you're deploying with SSH (Git, Ansible, etc.) and hitting this error:
1. For GitHub/GitLab/Bitbucket: Their public keys are already in most systems' known_hosts
2. For custom servers: Pre-populate known_hosts in your deployment image: ssh-keyscan hostname >> ~/.ssh/known_hosts
3. For Docker: Add the keyscan step to your Dockerfile before running deployment commands

Known Hosts Best Practices:
- Keep ~/.ssh/known_hosts backed up—it helps when setting up new machines
- Don't delete the entire known_hosts file; use ssh-keygen -R for specific hosts
- Consider using ssh-keyscan hostname > ~/.ssh/known_hosts.d/hostname to manage per-host files (requires Include ~/.ssh/known_hosts.d/* in ~/.ssh/config)

StrictHostKeyChecking Modes:
- yes (default): Refuse connections if host key is unknown or changed
- accept-new: Accept new host keys automatically but verify known ones
- no: Accept all host keys without verification (not recommended in production)
- off: Completely disable host key checking (dangerous, never use this)

Frequently asked questions

What does "Host key verification failed." mean?
ssh/known_hosts) that stores the public keys of all remote hosts you've connected to. When you connect to a new host, SSH verifies that the host's presented public key matches the stored key. If the key is missing from known_hosts (first connection) or has changed (security concern), SSH refuses the connection to protect you from connecting to an impersonated host.
How do I fix "Host key verification failed."?
This error occurs when SSH cannot verify the authenticity of a remote host's key because it doesn't exist in your known_hosts file or has changed. It's a security feature that prevents man-in-the-middle attacks but requires manual verification the first time you connect to a host.
What causes "Host key verification failed."?
Host key doesn't exist in ~/.ssh/known_hosts (first time connecting to host) Remote host's SSH key has changed (server reinstall, key rotation, or potential attack) IP address changed but ~/.ssh/known_hosts still has old key from different IP
Is the "Host key verification failed." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading