How to handle "WARNING: POSSIBLE DNS SPOOFING DETECTED!" and "REMOTE HOST IDENTIFICATION HAS CHANGED!" error at ssh login time?

botond published March 2022, 06, Thu - 16:17 time

Content

 

Introductory

When SSH access, your computer (client) will retrieve the ECDSA (Elliptic Curve Digital Signature Algorithm), which is also stored in the list of known servers during the first connection (by default, ~ / .ssh / known_hosts file). From here on, our machine will recognize the ECDSA fingerprint of the remote machine during future ssh connections, thus checking whether we are connecting to the exact same machine later. If the newly retrieved fingerprint does not match the previously stored version during the subsequent connection, the ssh program throws the following error: "WARNING: POSSIBLE DNS SPOOFING DETECTED!" and "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!". These error messages warn us that there is a possibility that DNS we may be victims of forgery (DNS spoofing), or the ECDSA fingerprint of the server, i.e. the public key of the SSH server, has just changed.

If it is already known to the public IP addresses If you receive such an error message when you connect to a live server that has a server, there is a real risk of a "man-in-the-middle" type attack (intrusion attack) when the server or client pretends to be listening to the channel. In this case, contact the server operator.

However, if you are experimenting with multiple Linux servers on a local network that have changed IP addresses, you can fix the problem with a simple step. In this short troubleshooter we will find a solution for this case.

 

 

The symptom

When connecting to an SSH server on a local network, the ssh command throws the following error:

SSH authentication error: WARNING: POSSIBLE DNS SPOOFING DETECTED!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for debian11 has changed,
and the key for the corresponding IP address 192.168.1.140
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/botond/.ssh/known_hosts:30
  remove with:
  ssh-keygen -f "/home/botond/.ssh/known_hosts" -R "192.168.1.140"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
SHA256:Vxt8eL9wH5B8hdoKscrLgujeCv3T4oR6xlhcEQbbr+k.
Please contact your system administrator.
Add correct host key in /home/botond/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/botond/.ssh/known_hosts:31
  remove with:
  ssh-keygen -f "/home/botond/.ssh/known_hosts" -R "debian11"
ECDSA host key for debian11 has changed and you have requested strict checking.
Host key verification failed.

 

The reason of the error

The error in this case for me was caused by setting my virtual machines to the same IP address per serial on my local network so that I could remember the addresses more easily. Therefore, if I use one after the other and access them via SSH, ssh will get another ECDSA fingerprint from the other machine at the same IP address, so it will issue "WARNING: POSSIBLE DNS SPOOFING DETECTED!" Instead of logging in. error message and that the ~ / .ssh / known_hosts how many lines in my file have the "fake" fingerprint. Then "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" also indicating that the fingerprint for the IP address has changed. Which is because I used to run another virtual machine with the same IP address, so no problem, we just need to fix it. ~ / .ssh / known_hosts our file.

 

 

The solution

The solution to this error is also included in the error message itself, which states that it is ssh-keygen Use the command to delete the incorrect line in known_hosts from our file. So in this example:

ssh-keygen -f /home/botond/.ssh/known_hosts -R debian11

Of course, run the one in our own home directory. So, more generally, using the command:

ssh-keygen -f ~/.ssh/known_hosts -R debian11

Delete a faulty ECDSA fingerprint using the ssh-keygen command

Where the switches are:

  • -F: the file name containing the keys must be entered here
  • -A: Removes all keys from the file that belong to the specified hostname.

After you run the command, it lists the number of lines in which you found the bad key you deleted from the file, and where you saved the backup you made before.

Then log in to the server again:

Store a new ECDSA fingerprint on first entry

Since our file no longer stores anything about this server, it considers it the first login and asks if the server is OK and if we want to continue connecting. Let's answer "yes" here, and then you will be logged in:

SSH - successful login

You will no longer be asked to do so until the fingerprint associated with your IP address changes.

 

Leaving the server, it is interesting to check the key on your machine ssh-keyscan command:

ssh-keyscan -t ecdsa <hosztnév>

Querying an ECDSA key with the ssh-keyscan command

You can find it in our known_hosts file:

 grep -n "<kulcs>" ~/.ssh/known_hosts

Check the ECDSA key in the known_hosts file

Here it is included twice in the file, one associated with the hostname and the other with the IP address.

 

 

Conclusion

So if you get this error message when logging in to ssh, make sure you are "in-house" scrambling with your internal IP addresses, because then you can easily delete the bad ECDSA fingerprint as above, but if you get the same when logging in to a live server , be careful because the public SSH keys on the servers will not change, so check with the administrator who is running the server.