14

What are the possible causes of a changed ssh fingerprint?

Some context: after finding a sensitive vulnerability in a governmental system and disclosing it to them, something happened which I don't remember happening before. When connecting to the VPS I used to verify the vulnerability, my ssh client complained about the key; the fingerprint did not match the one saved. I verified the one saved was still there, and after immediately rebooting the VPS it matched again.

What are the chances this is due to malicious interference?

Improve this question
2
  • Did you save the old key before reboot ? It may have been a path problem. The keys suppose to be in .ssh/known_hosts.
    – Overmind
    Nov 28, 2017 at 6:41
  • In this case I used putty on Windows, the fingerprint was saved in a registry key so that might not be applicable
    – J.A.K.
    Nov 28, 2017 at 10:25

3 Answers 3

Reset to default
16

The correct assumption in this case is that you are connecting to a different server.

  • Maybe a MitM attack or
  • maybe your DNS is spoofed or
  • maybe your data center has just removed your machine for a second because they got a call from the government and you are accidentally trying to connect to their "server unreachable" catchall machine or
  • maybe your server has crashed under the sudden load and the aforementioned holds or ...

There are plenty of reasons you might be connecting to the wrong machine and you should definitely not proceed.

There are a couple of harmless reasons as well, false positives that make people sometimes connect anyway.

False positives I can think of right now:

  • The server has removed an old ciphersuite which it doesn't want to support anymore.
  • The server IP has changed and you have "CheckHostIP yes" in your config (default on many systems).
  • You have connected to the same server using a different hostname (think about something like gitlab) since the default ciphersuites have changed. (This is really obscure but I have run into it.)
  • The server has multiple SSH servers installed, and you're connecting to the same machine running a different SSH server (e.g., due to improperly configured startup behavior), which has its own separate keys.

Do note that as described here public key authentication prevents MitM attacks. It does of course not prevent you from simply logging into the wrong machine and then typing in your sudo password. So caution is still required.

Improve this answer
4
  • Great enumeration of the possible causes, it might very well be the hosting company redirecting to a catch-all. That would definitely be a more likely explanation than some infrastructure-level tampering by a state actor. Thanks!
    – J.A.K.
    Nov 28, 2017 at 10:59
  • "This is really obscure" not so much for me. I often connect to a machine in my network at home by its local name, then I go outside of the house and connect to the same machine through my house's DNS name (at the appropriate port with port forwarding). Also, I recently changed DNS names, so that adds more of this type of false positive.
    – lmat - Reinstate Monica
    Sep 16, 2020 at 22:51
  • Another common false positive is client SSH changes. E.g. SSH client upgrade makes it more secure by making it require SSH port number verification (real life story)
    – Oleg Mikheev
    May 2, 2021 at 20:02
  • Or, you changed your /etc/hosts file to test something, and forgot to change it back, and /etc/hosts is pointing at something that is different from what you think it should be!... (I'll try not to repeat that mistake!)
    – Yannick Wurm
    Oct 3, 2021 at 14:14
1

After upgrading my client to Ubuntu 22.04 (from 20?) I got an error like this:

The authenticity of host '[foo.bar]:22 ([1.2.3.4]:22)' can't be established.
ED25519 key fingerprint is SHA256:lotsOfChars.
This key is not known by any other names

The first ever time I logged into the server it said:

ECDSA key fingerprint is SHA256:lotsOfOtherChars.

Note how the algorithm has changed. I am assuming that is the reason that the fingerprint is now different. If that is true, then in addition to the answer by @Elias that "The server has removed an old ciphersuite which it doesn't want to support anymore" it can also be that the client has removed an old cipher suite.

Improve this answer
2
  • Hello and welcome to Information Security Stack Exchange! If you feel like your answer comes in addition with Elias', you may edit it to add your scenario.
    – Yuriko
    Sep 11, 2022 at 9:14
  • 1
    Just FYI, OpenSSH 8.5 (released in between Ubuntu 20.04 and 22.04) changed the default settings to prefer Ed25519 over ECDSA. Older and newer versions support both algorithms. :-)
    – Matt Nordhoff
    Sep 11, 2022 at 11:38
0

This could absolutely be caused by an on-path attacker launching a man-in-the-middle attack and attempting to impersonate your VPS's SSH server. They wouldn't have the host key, so they would just present their own, which would trigger a warning. Another common reason this error triggers is when the IP address of the server you are SSHing to has changed. The known_hosts file essentially encodes IP,SSH Host Key Fingerprint,host name. If the IP or SSH Key Fingerprint change for a hostname, you will get a warning.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .