This error appears when SSH detects that a host's key has changed since you last connected. It's a critical security check that prevents man-in-the-middle attacks, but is often triggered legitimately when servers are reinstalled, IP addresses are reassigned, or infrastructure is recreated.
SSH maintains a database of known host keys in your `~/.ssh/known_hosts` file. Each server has a unique public key that identifies it. When you connect to a server, SSH compares the server's presented key against what's stored locally. If the key doesn't match, SSH blocks the connection and displays this error to protect you from potentially connecting to a malicious imposter server that's intercepting your traffic. ED25519 is a modern elliptic curve algorithm that's more secure and faster than older RSA keys.
Before removing the old key, confirm that the change is expected:
- Did you recently rebuild or redeploy this server?
- Did the IP address recently change in your infrastructure?
- Is this a cloud instance that was recreated?
- Did you explicitly update SSH daemon configuration?
If you cannot confirm a legitimate reason, do not proceed until you've investigated. An unexpected host key change could indicate a security breach or network interception. Contact your infrastructure or hosting provider to confirm.
The safest method is to use ssh-keygen to remove just the old entry:
ssh-keygen -R hostname.example.comOr use the IP address if connecting by IP:
ssh-keygen -R 192.0.2.1This removes the old entry from ~/.ssh/known_hosts without affecting other hosts. You'll see output like:
# Host hostname.example.com found: line 5
/home/user/.ssh/known_hosts updated.
Original contents have been backed up to /home/user/.ssh/known_hosts.oldThe backup file (.old) is created automatically in case you need to restore it.
When you attempt to connect again, SSH will prompt you to verify and accept the new host key:
SSH displays:
The authenticity of host 'hostname.example.com (192.0.2.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?Type yes to accept and cache the new key.
Important: If you're unsure about the key, you can verify the fingerprint with your infrastructure provider or server administrator before accepting.
If you need more control, edit the file directly:
nano ~/.ssh/known_hostsFind the line containing your hostname or IP address and delete it entirely. The file format is:
hostname,ip ssh-ed25519 AAAAC3NzaC1lZDI1...Save and exit (Ctrl+X, then Y, then Enter in nano).
Alternatively, if the error message shows the line number (e.g., line 15):
sed -i '15d' ~/.ssh/known_hostsThis removes just that line without opening an editor.
In automated environments (GitHub Actions, GitLab CI, Jenkins), you may want to handle key changes gracefully:
ssh -o StrictHostKeyChecking=accept-new user@hostThe accept-new option automatically accepts new host keys (not yet in known_hosts) but still rejects changed keys. Other options:
- StrictHostKeyChecking=no - Accept any key (less secure, use only for trusted networks)
- StrictHostKeyChecking=yes - Reject unless key is in known_hosts (most secure)
- StrictHostKeyChecking=accept-new - Accept new keys, reject changed ones (recommended)
Add this to your script or CI configuration:
#!/bin/bash
ssh -o StrictHostKeyChecking=accept-new -i ~/.ssh/key user@host "your-command"If managing SSH for infrastructure deployments, you may need to reset known_hosts completely:
rm ~/.ssh/known_hostsThen let SSH rebuild it naturally as you connect to hosts. However, this removes keys for ALL hosts, so use only when:
- Spinning up entirely new infrastructure
- In isolated CI/CD environments that don't persist state
- You're comfortable re-validating all host keys
For production, use a more targeted approach:
ssh-keygen -R $(terraform output -raw instance_ip)This removes only the specific host's key after infrastructure recreation.
Advanced topics:
ED25519 vs RSA: ED25519 is a modern elliptic-curve algorithm offering better security than RSA at smaller key sizes (256 bits vs 2048-4096 bits). All modern SSH implementations support ED25519. If you're still seeing RSA keys, consider regenerating them.
Host Key Verification During SSH Setup: When bootstrapping new servers (Terraform, Ansible, cloud-init), you can pre-seed the known_hosts file:
# Get the public key before connecting
ssh-keyscan -t ed25519 hostname.example.com >> ~/.ssh/known_hostsThis populates known_hosts without requiring manual verification, preventing the "authenticate" prompt in automated workflows.
Security Best Practices:
- Always verify host keys in sensitive environments (production databases, payment systems)
- Use SSH certificate authentication for infrastructure at scale instead of known_hosts
- Implement host key pinning in critical applications
- Audit ~/.ssh/known_hosts periodically for unexpected entries
Network Interception Mitigation: If you suspect a man-in-the-middle attack:
1. Do NOT accept the new key
2. Connect to the server through an alternative path (VPN, bastion host, direct console)
3. Verify the actual host key using ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
4. Compare fingerprints with what SSH shows
5. Only proceed if they match
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH