In this guide, I explain the following daunting message that can occur when attempting an SSH connection to a remote server:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for 123.45.678.9 has changed and you have requested strict checking.
Host key verification failed.
To begin, I’m going to explain why this message is happening, and then I will explain how to fix it.
Why is this message happening?
This message can occur when there’s a mismatch between security keys used to authenticate connections with a remote server.
To understand this security key system, first note that whenever you attempt to communicate via SSH with a server you’ve never connected to before, you receive a message like the following:
> ssh user@123.45.678.9
The authenticity of host 123.45.678.9 can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
This message is effectively saying “I don't recognize the server you’re trying to connect to for the first time; do you trust it and want to continue the connection?”
If you say yes, the remote server sends a public key that correlates with a private key stored on their server. This public key is recorded on your system in the file ~/.ssh/known_hosts.
Then, for every subsequent connection you attempt to make with that remote server, they initiate a challenge-response authentication protocol. This means they first send a challenge, which is just a message encrypted with their private key.
Your system must decrypt this challenge message using the public key you have stored for that server, and send the unencrypted response back. If your system’s response matches the expected value, the connection is authenticated.
If your system’s response does not match, this indicates there’s some problem so the connection fails and you see the above failure message.
Why might the keys fail?
In the failure message, it lists two possible reasons the key authentication may be failing:
- “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 first reason, a man-in-the-middle attack, is a type of cyber attack where a hacker intercepts and tampers with the communication between two systems. The fact that your key and the remote server’s keys are failing to match up is a red flag that this kind of attack could be occurring.
More often than not, though, the cause for failure is actually the second reason - the host key has been changed.
As an example of this, in March 2023 Github.com reset their public key after it had been compromised.
Another example I’ve seen is when I attempted to connect to one of my own servers where I had just done a new install of an operating system, thereby changing the public key that had been on that server.
How do we fix it?
To fix the issue, you need to update the public key you have stored for the remote server you’re connecting to.
To do this, first open your ~/.ssh/known_hosts file and remove the existing public key for the remote server.
Then, initiate a connection with the remote server and you’ll again see the “Do you trust this server” message described above:
> ssh user@123.45.678.9
The authenticity of host 'domain.com (123.45.678.9)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
To be extra careful, you should verify the public key it’s reporting in this message (the key fingerprint) matches the actual public key used by the server you’re connecting to. Using Github has an example, you can see their public keys here....
Assuming everything checks out, type yes and hit enter, and the new public key will be written to your system’s ~/.ssh/known_hosts file and used to authenticate subequent connections.