The message
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:1
Host key for server has changed and you have requested strict checking.
Host key verification failed.A server proves its identity with its host key. Your computer saved that key the first time you connected. It has now received a different one, and ssh stopped before sending anything. The two details you need are the new fingerprint (the SHA256: line) and the place of the old entry (known_hosts:1 is line 1). On Debian and Ubuntu the message also suggests an ssh-keygen -R command: run it only after the check below.
Legitimate cause or attack?
Common harmless causes:
- The server was rebuilt, reinstalled or restored, which often creates new host keys.
- The address now belongs to another machine: a new VM on a reused cloud IP, or a moved Elastic IP.
- A load balancer or failover pair sends you to a machine with different keys.
- A forwarded port such as
localhost:2222now leads somewhere else. - An administrator or a service rotated the keys, as GitHub did with its RSA host key in March 2023.
- The server no longer offers the key type you saved. In our test, a server limited to RSA triggered this warning for a client that had saved its ED25519 key.
Be suspicious when nobody can explain the change, when it appears only on one network such as public Wi-Fi, or when it is a server nobody touched. Until you know, do not type a password or run anything on it. Trying from another network helps: if the fingerprints differ between networks, something on one of them is interfering.
Check the new fingerprint out of band
Out of band means through a channel an attacker on this connection cannot control: the provider's web console, a serial console, physical access, or a colleague with verified access. On the server, run:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub256 SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU root@server (ED25519)Use the file for the key type named in the warning: ssh_host_rsa_key.pub or ssh_host_ecdsa_key.pub for the others. The value must match the warning exactly. Some cloud images also print fingerprints to the console log at first boot.
The command below only shows what the server on your current network path sends. It is handy for reading a value out, but it proves nothing by itself, since an attacker would send the same fake key to it:
ssh-keyscan -t ed25519 server | ssh-keygen -lf -Remove the old key
ssh-keygen -R server# Host server found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.oldThis works even with hashed names, and you do not have to edit the file by hand. Use the same name you connect with. Some setups need more than one call:
ssh-keygen -R 203.0.113.10
ssh-keygen -R '[server]:2222'The second form is for a server on a port other than 22.
Connect again and compare
ssh user@serverThe authenticity of host 'server (203.0.113.10)' can't be established.
ED25519 key fingerprint is: SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?Compare, or better, paste the fingerprint you got from the console at this prompt. ssh then compares them for you, and it asks again if they do not match.
Why not StrictHostKeyChecking=no
This is the advice you will find most often, and it removes the protection altogether. We tried it against a changed key. It still prints the warning, then goes on:
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.Key login still went through, so you are working on a server you have not verified, and anything you type or copy there may reach an attacker. Setting UserKnownHostsFile=/dev/null does similar harm: nothing is ever remembered, so nothing can ever be checked.
For scripts that meet new hosts, use StrictHostKeyChecking=accept-new. It saves keys for new hosts and still refuses a changed key, as we confirmed. See known_hosts explained.
For scripts and CI that stop with a single line instead, see Host key verification failed in scripts and CI.
Stop seeing this warning for planned changes
- When you rebuild a server, restore its old host keys from your secure backup, if your policy allows it.
- For a pool of machines behind one name, use host certificates, so clients trust a CA rather than each key.
- To rotate keys, add the new key first and let clients learn it with
UpdateHostKeys, and only then remove the old one.
Questions
Is it safe to just run ssh-keygen -R?
Only after you have confirmed the new fingerprint through another channel. The command removes the warning, not its cause, so on its own it can hide an attack.
Why does the warning appear after I reinstalled the server?
A reinstall usually creates new host keys, so the key no longer matches the one saved in known_hosts. Compare the new fingerprint from the console, then remove the old entry.
Does StrictHostKeyChecking=accept-new get past this warning?
No. accept-new only saves keys for hosts it has never seen. A changed key is still refused.
Sources
- ssh(1), Verifying host keys
- ssh_config(5), StrictHostKeyChecking
- ssh-keygen(1), OpenBSD manual
- Troubleshoot connecting to an EC2 Linux instance, AWS