The first time I connect via SSH, a "fingerprint" appears. How can I be sure that it belongs to my server/router/etc. and has not been tampered with by a fraudster (MITM)?

For example, for key-based authentication, I decide to send the public key to the remote router.

ssh-copy-id -f [email protected] < /dev/null

In response, the router gives me a "fingerprint" to confirm. BUT the "man in the middle" might as well query the router and get the same fingerprint and then forward it to me as if it were a real router. I then send the public key and establish a connection to it and it to my router.

How does a "fingerprint" protect against MITM?

2 Answers 2


You need to verify out-of-band.

As you correctly stated, SSH is Trust-On-First-Use (TOFU), so if you are being intercepted on first use, then you would trust the attacker's key.

Depending on your setup, you could connect to the machine via a local network, where interception is unlikely (e.g. your home server) or have the fingerprint displayed somewhere on a web page, which is secured via HTTPS.

Back when I was in school, our admin would, for instance, print the fingerprint of every SSH host onto a sheet of paper and have it outside his office. Of course, most students wouldn't bother verifying it, but it was handy in case keys ever changed.

  • In my example, I was just interested in the fingerprint question. After all, the fingerprint can also be obtained by an intruder and then provided to me for verification, as if it were a real server. That is, the "man in the middle" will put the correct fingerprint and I will think that this is the real server.
    – Serg90
    Oct 15, 2021 at 13:55
  • 1
    @Serg90 The "fingerprint" is calculated from the public key. So an attacker would need the corresponding private key. If the attacker steals the real private key off your server, they don't need any tricks - they can impersonate your server perfectly and there is nothing they can do.
    – user163495
    Oct 15, 2021 at 14:28
  • 1
    With AWS you get this option.
    – x-yuri
    Nov 8, 2021 at 11:14
  • @x-yuri Yes, that's another out-of-band verification. I assume that the transmission via that CLI application is secured via HTTPS.
    – user163495
    Nov 8, 2021 at 11:21
  • Also, you might want to elaborate on how public and private keys of the server are used, since "fingerprint is calculated from the public key" doesn't make much sense otherwise. I mean, enough details to make it clear that an attacker needs them to forge a fingerprint.
    – x-yuri
    Nov 8, 2021 at 11:23

All of the following assumes you've already verified the server's fingerprint via some out-of-band method.

The server doesn't send a separate fingerprint. The fingerprint you see is calculated by your ssh client from the public key that the server presented when you connected. That same public key is used by your client to encrypt data before sending it to the server in such a way that it can only be decrypted using the server's private key.

That means that even if an attacker tricked you into connecting to a machine they control and presented the correct public key for the server you intended to connect to (so that you would see the fingerprint you expect), they wouldn't be able to decrypt the data you sent them if they don't have the real server's private key.

Of course, if the attacker does have your server's private key then you're pwned. They can impersonate your ssh server. That's why it's important to keep your private keys private.

You must log in to answer this question.

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