WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! (SOLVED)

Contents

1. SSH remote host ID has changed
2. How to check that there is no man-in-the-middle attack on SSH, and the host ID was changed for legal reasons
3. Changing the SSH host fingerprint does not affect authentication in any way
4. How to fix the error “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”
5. Fixing “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” with ssh-keygen
6. How to connect with the StrictHostKeyChecking option
7. Conclusion

SSH remote host ID has changed

Once after updating packages on the server (including SSH), after restarting the SSH service on the server, when trying to connect to it, the following error message began to appear:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:FINGERPRINT_STRING_HERE.
Please contact your system administrator.
Add correct host key in /home/mial/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/mial/.ssh/known_hosts:31
Host key for [IP_HERE]:PORT_HERE has changed and you have requested strict checking.
Host key verification failed.

The message says that the fingerprint of the server has changed. This can be due to two possible reasons:

1. Man-in-the-middle attack
2. “Host key has just been changed”

A man-in-the-middle attack on SSH is possible, so you should not take it frivolously.

See also: How to intercept SSH password. Man-in-the-middle attack on SSH

But in most cases, the reason is still different. As I already said, the error message appeared after updating the SSH package.

How to check that there is no man-in-the-middle attack on SSH, and the host ID was changed for legal reasons

You can look at the official website and see what was changed in new versions: https://www.openssh.com/releasenotes.html

For example, I saw the following there:

OpenSSH 9.8/9.8p1 (2024-07-01)
...
OpenSSH plans to remove support for the DSA signature algorithm in early 2025. This release disables DSA by default at compile time.

That is, the DSA signature algorithm was disabled in this version.

By the way, you can find out the installed version of SSH using the -V option:

ssh -V
OpenSSH_9.8p1 Debian-8, OpenSSL 3.3.2 3 Sep 2024

Or using ssh-keyscan:

ssh-keyscan HOST
ssh-keyscan -p PORT HOST

Note how the port is specified and that HOST in this case comes after PORT – otherwise the command does not work.

You can also use another network connection and if you get exactly the same error, this will mean that the reason is most likely in your server, and not in a man-in-the-middle attack on SSH.

You may have noticed the line in the output:

SHA256:FINGERPRINT_STRING_HERE

You are probably wondering if there is a way to quickly and reliably match the FINGERPRINT_STRING_HERE string with your private and public SSH keys?

The short answer is no, or it is done in a rather non-trivial way.

The keys you use to authenticate on the SSH server (private and public keys) and the server keys (as well as their fingerprints) are different keys. When connecting to a host that is not yet known, SSH shows you the server fingerprint (which is the server's public key, unrelated to authentication), which is completely different and has no connection to your private and public keys. If you want to see the server keys used to quickly verify the host identity, look in the /etc/ssh folder on the server, there you will see, among others, the following files:

ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Files with the .pub extension are public keys and they are the ones written to the known_hosts file on the host that connected to the server.

Note: remember, the keys used to authenticate the user are stored in the .ssh/authorized_keys file

If you want to see the fingerprints of the server, then run the following commands on the server:

ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

So, if you have access to the server's file system in another way (not SSH), then you can get the fingerprint for the public key and compare it with the one that is shown to you in that scary warning that something bad and evil is happening.

Changing the SSH host fingerprint does not affect authentication in any way

From the previous section, you should have already realized that the server fingerprint is only used to quickly verify that this is the server you want to connect to. The server fingerprint can change without your intervention or even without you being notified, as happened when upgrading to OpenSSH 9.8.

In any case, after a quick check of the SSH server's identity, you will be prompted to authenticate using the key pair you created on your computer and saved to the .ssh/known_hosts file on the server.

How to fix the error “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”

So, how do you fix the warning “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”?

It’s pretty easy. Too easy, actually. That’s why a long introduction was needed, so that you could think about the security of your decision.

In fact, you can fix this error even without special tools, the algorithm is as follows:

1. Open the file ~/.ssh/known_hosts.
2. Find all the lines in this file related to the host that has changed its fingerprint. Delete all the lines found related to the host.
3. Reconnect to SSH in your usual way. In this case, there will no longer be a warning about the change in host identification. You will only see a message about connecting to a new SSH server and a request to save its public key. Agree to save the server fingerprint.

That’s it! It turns out that this complex problem can be solved quite trivially.

If you connect to a single SSH server, you can simply delete the ~/.ssh/known_hosts file:

rm ~/.ssh/known_hosts

Fixing “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” with ssh-keygen

If you don’t want to mess with files and prefer utilities, you can fix the problem with ssh-keygen. Run this program with the -R option and specify the host for which the identification has changed:

ssh-keygen -R HOST

If you are using a non-standard port, then use the following syntax:

ssh-keygen -R [HOST]:PORT

For hosts to which you connect using IPv6, the syntax is similar:

ssh-keygen -R [IPv6]:PORT

If you get an error that HOST was not found in the ~/.ssh/known_hosts file, then again refer to the error message and use exactly the same syntax as in that message. Also, to prevent the shell from interpreting characters that have special meaning for it, put the host and port in single quotes:

ssh-keygen -R '[HOST]:PORT'

How to connect with the StrictHostKeyChecking option

If you have disabled the StrictHostKeyChecking option in the configuration file (/etc/ssh/ssh_config) or on the command line as follows:

ssh -oStrictHostKeyChecking=no USER@HOST

Then new hosts will be added to the ~/.ssh/known_hosts file automatically. However, if the host identification has changed, the connection will fail.

Conclusion

The “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” error is quite easy to fix – just remove the information about the problematic host from the known_hosts file. But before you do that, make sure that there is no man-in-the-middle attack on SSH. The easiest thing to do is to try connecting to SSH using a different connection (for example, use a different Wi-Fi network, or switch to mobile data or a wired connection provided by a different Internet service provider).