How to fix The ED25519 host key for hostname has changed in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 410 views

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.

Quick fix

Fixes The ED25519 host key for hostname has changed

ssh-keygen -R hostname.example.com
  1. Verify the key change is legitimate
  2. Remove the old host key using ssh-keygen
  3. Accept the new host key on next connection
  4. Edit known_hosts directly (manual method)
ssh — error
ssh-keygen -R hostname.example.com
The ED25519 host key for hostname has changed

What this error means

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.

Typical symptoms

  • SSH connection blocked with warning about remote host identification changed
  • Connection attempt shows 'Offending key in ~/.ssh/known_hosts:N' (line number)
  • Error message warns about potential man-in-the-middle attack
  • Manual connection attempts fail until the cached key is removed
  • Only happens on first connection after server change; subsequent connections work
  • CI/CD pipelines fail when trying to SSH to hosts with changed keys

Common causes

  1. Server was reinstalled or replaced (most common legitimate reason)
  2. IP address was reassigned from one server to a different machine
  3. Cloud instance was terminated and new instance launched with same IP
  4. Actual man-in-the-middle attack (rare but possible)
  5. Server's SSH daemon was reconfigured to regenerate host keys
  6. DNS hostname points to a different IP address than before
  7. Network load balancer or proxy is intercepting the connection
  8. SSH server version was upgraded and regenerated keys during process

How to fix "The ED25519 host key for hostname has changed"

1Verify the key change is legitimate

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.

2Remove the old host key using ssh-keygen

The safest method is to use ssh-keygen to remove just the old entry:

bash
ssh-keygen -R hostname.example.com

Or use the IP address if connecting by IP:

bash
ssh-keygen -R 192.0.2.1

This removes the old entry from ~/.ssh/known_hosts without affecting other hosts. You'll see output like:

bash
# 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.old

The backup file (.old) is created automatically in case you need to restore it.

3Accept the new host key on next connection

When you attempt to connect again, SSH will prompt you to verify and accept the new host key:

bash
ssh user@hostname.example.com

SSH displays:

bash
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.

4Edit known_hosts directly (manual method)

If you need more control, edit the file directly:

bash
nano ~/.ssh/known_hosts

Find the line containing your hostname or IP address and delete it entirely. The file format is:

bash
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):

bash
sed -i '15d' ~/.ssh/known_hosts

This removes just that line without opening an editor.

5For CI/CD pipelines: Use StrictHostKeyChecking flag

In automated environments (GitHub Actions, GitLab CI, Jenkins), you may want to handle key changes gracefully:

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

The 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:

bash
#!/bin/bash
ssh -o StrictHostKeyChecking=accept-new -i ~/.ssh/key user@host "your-command"
6For Terraform/Infrastructure-as-Code: Recreate known_hosts

If managing SSH for infrastructure deployments, you may need to reset known_hosts completely:

bash
rm ~/.ssh/known_hosts

Then 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:

bash
ssh-keygen -R $(terraform output -raw instance_ip)

This removes only the specific host's key after infrastructure recreation.

Advanced notes

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:

bash
# Get the public key before connecting
ssh-keyscan -t ed25519 hostname.example.com >> ~/.ssh/known_hosts

This 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

Frequently asked questions

What does "The ED25519 host key for hostname has changed" mean?
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.
How do I fix "The ED25519 host key for hostname has changed"?
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.
What causes "The ED25519 host key for hostname has changed"?
Server was reinstalled or replaced (most common legitimate reason) IP address was reassigned from one server to a different machine Cloud instance was terminated and new instance launched with same IP
Is the "The ED25519 host key for hostname has changed" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading