I have got the well-known warning message when trying to ssh into a server:

$ ssh whateverhost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:xxxxxxxxxxxxxxxxxxxxxxxxxxx/xxxxxxxxx/xxxxxxx.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:10
ECDSA host key for ipofmyhost has changed and you have requested strict checking.
Host key verification failed.

And I know why because I changed the ip of such server. But if it weren't so, how could I check the fingerprint for the ECDSA key sent by the remote host?

I have tried to do so by:

echo -n ipofthehost | sha256sum

But I don't get the same fingerprint. I also tried "hostname,ip" kind of like in aws but I got no match.

If I delete the entrance from my known_hosts file and I try to ssh again, it succeeds and tells the following:

ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx/xxxxxxxxx/xxxxxxx.
Are you sure you want to continue connecting (yes/no)?

So to what is it applying the sha256sum to get the fingerprint and how I could check it?

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – mdpc, masegaloeh, MadHatter, Jenny D, mulaz

Without a known good value you can't check it. You only write it down the first time you start the SSHd and the keys are generated, and check against that known good value.
– user186340May 9 '15 at 20:37

I edited your question. This site accepts only questions about a professional business environment. Home networking questions are offtopic here, I tried to save your question with my edit. Currently there is a vote against your question to close that on this ground.
– peterhMay 11 '15 at 0:56

@user186340 It does seem to be true that "you only write it down the first time you start the SSHd". If you have access to the machine running SSHd you can do /etc/ssh/ssh_host_ecdsa_key.pub to get the fingerprint. I just did.
– jamadagniMay 25 '18 at 11:29

I'm confused why when connecting via SSH and forcing an ecdsa key for the first time (ssh -oHostKeyAlgorithms='ecdsa-sha2-nistp256' william@my.server) it gives me a 43-digit alphanumeric fingerprint (ECDSA key fingerprint is SHA256:sBKcTiQ5V.... etc.) yet when I run ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub I get 32 character hex??
– William TurrellMar 2 '16 at 12:36

1

@WilliamTurrell This is occurring because your server must have an older (likely pre- openSSH 6.8) version of ssh-keygen (or your server-provider hasn't kept up with the times and still only provides md5 hashes instead of the new SHA256). There are workarounds listed here: superuser.com/questions/929566
– SeldomNeedyApr 27 '16 at 23:52

A bit more in detail: Because the warning message refers to the fingerprint for the ECDSA key sent by the remote host we gather the info about the public (ecdsa) key of the host:

ssh-keyscan -t ecdsa ip_or_hostmane > ecdsa_file_to_compare

Then we can find out where in our known_hosts file that public (ecdsa) key is:

ssh-keygen -l -F ipofhost

If we want to compare the fingerprints we have to put the contents of our known_hosts file (just the entry related to this host), we can call it ecdsa_file_from_known_hosts and then compare them as follows:

Of course they don't match, that is why I got the warning message (ssh checks this matching internally). If we are sure about the ip change (so we are not suffering a man-in-the-middle attack) we can just delete the entry of that host in our known_hosts file and the next time we ssh into it a new fresh entry for it will be added to such file.