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.
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.
Use ssh-keygen to remove the offending key entry. This is the safest approach as it automatically removes only the specific host's key:
ssh-keygen -R hostname
ssh-keygen -R 192.168.1.100Replace 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.
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:
ssh user@hostnameYou'll see output like:
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.
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:
ECDSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdhIf 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.
If ssh-keygen -R doesn't work, you can manually edit ~/.ssh/known_hosts. The error message usually tells you the line number:
Offending ECDSA key in /home/user/.ssh/known_hosts:22Open the file and delete the offending line (in this example, line 22):
nano ~/.ssh/known_hosts
# Or use sed to remove a specific line:
sed -i '22d' ~/.ssh/known_hostsSave the file and retry the SSH connection.
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:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostnameA more balanced approach: accept only new keys and keep checking known keys:
ssh -o StrictHostKeyChecking=accept-new user@hostnameThis 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+.
SSH requires the known_hosts file to have correct permissions. If permissions are wrong, SSH may fail to read it:
ls -la ~/.ssh/The known_hosts file should be readable by your user. Fix if needed:
chmod 644 ~/.ssh/known_hostsAlso ensure your ~/.ssh directory itself has correct permissions:
chmod 700 ~/.sshAdvanced 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)
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH