How to fix: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" on Mac and Linux

SSH, or Secure Shell, is a very common way to securely access remote machines, typically via the command line. It aims at ensuring that your connection, and therefore all data passed, is free from eavesdropping. Because of this, there are quite a few checks built-in to the popular SSH clients, like OpenSSH, that ensure your connection can't be compromised.

An example of one of these checks is the following, which identifies when the fingerprint of a server has changed:

$ ssh [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:hotsxb/qVi1/ycUU2wXF6mfGH++Yk7WYZv0r+tIhg4I.
Please contact your system administrator.
Add correct host key in /Users/scott/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/scott/.ssh/known_hosts:47
ECDSA host key for ec2-192-168-1-1.compute-1.amazonaws.com has changed and you have requested strict checking.
Host key verification failed.

When you connect to a server via SSH, it gets a fingerprint for the ECDSA key, which it then saves to your home directory under ~/.ssh/known_hosts. This is done after first connecting to the server, and will prompt you with a message like this:

$ ssh [email protected]
The authenticity of host 'ec2-192-168-1-1.compute-1.amazonaws.com (192.168.1.1)' can't be established.
ECDSA key fingerprint is SHA256:hotsxb/qVi1/ycUU2wXF6mfGH++Yk7WYZv0r+tIhg4I.
Are you sure you want to continue connecting (yes/no)? 

If you enter 'yes', then the fingerprint is saved to the known_hosts file, which SSH then consults every time you connect to that server.

But what happens if a server's ECDSA key has changed since you last connected to it? This is alarming because it could actually mean that you're connecting to a different server without knowing it. If this new server is malicious then it would be able to view all data sent to and from your connection, which could be used by whoever set up the server. This is called a man-in-the-middle attack. This scenario is exactly what the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message is trying to warn you about.

Of course, this isn't always the case, and there are many reasons for the ECDSA key fingerprint to change for a server. In my case, I had an elastic IP address on AWS and assigned it to a different server after redeploying our application. The IP address and hostname I was connecting to were the same, but the underlying server was different, which is what tripped the SSH client to issue this warning.

Fixing the Issue

If you are 100% sure that this was expected behavior and that there is no potential security issue, you'll need to fix the issue before continuing.

The easiest ways I've found to fix this problem is the following two solutions.

Manually Resolve via known_hosts

• In the warning message find the line that tells you where the offending ECDSA key is located in the known_hosts file. In my example this line said "Offending ECDSA key in /Users/scott/.ssh/known_hosts:47", which refers to line 47.
• Open the known_hosts file specified in the warning message
• Delete the line specified in the warning message

By deleting this line, your SSH client won't have an ECDSA key fingerprint to compare to, and thus will ask you again to verify the authenticity of the server the next time you connect. Once done, you'll have a new fingerprint in our known_hosts file for this server, and the warning will be gone.

Resolve Using ssh-keygen

Another solution would be to use the ssh-keygen utility to delete the offending key from your known_hosts file, which can be done with the following command:

$ ssh-keygen -R [hostname-or-IP]

So in my example I'd use it like this:

$ ssh-keygen -R ec2-192-168-1-1.compute-1.amazonaws.com

This method is good if you don't want to manually alter the known_hosts file yourself, and the utility is easier to use if you have multiple hostnames and IP addresses to fix. It can also handle hashed hostnames in a known_hosts.old file.