← All posts

That host key prompt: how to verify an SSH fingerprint

To verify an SSH host key fingerprint, get the same fingerprint from a source an attacker on the network cannot tamper with, and compare the two. The best source is the server itself: log in through your provider's web console and run ssh-keygen -lf on the host key files. If that is not possible, run ssh-keyscan from a different machine on a different network. A match means the key you are about to trust really belongs to the server.

That prompt is easy to click past, and it is the only point at which SSH can catch someone sitting between you and the server. Here is how to treat it properly.

What the fingerprint is

Every SSH server has one or more host key pairs, usually in /etc/ssh/ssh_host_*_key. During the handshake the server proves it holds the private half. Your client cannot know on the first connection whether that public key is genuine, so it shows you a fingerprint: a hash of the public key, short enough to compare by eye.

Modern OpenSSH shows SHA-256 fingerprints in Base64, without the trailing padding:

256 SHA256:Kv0rT0b1kVhsVq2xM7m4d3c8yJXq9Gq3h7mKp1dQe2Y example.com (ED25519)

That line gives the key size, the fingerprint, a comment and the key type. The fingerprint above is an example, not a real server's. Older tools show MD5 fingerprints as colon-separated hex (MD5:3b:9f:...). If you are handed one of those, ask ssh-keygen for the same format with -E md5.

Get the fingerprint from the server itself

This is the strongest check, because it does not travel over the connection you are trying to verify. Use your hosting provider's browser console, a serial console, or an existing session you already trust, and run:

for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$f"; done

You will see one line per key type, typically Ed25519, ECDSA and RSA. Many cloud images also print host key fingerprints to the instance's console log on first boot (cloud-init does this), which your provider's dashboard or API can show you. If someone else runs the server, ask them to send you the output through a channel other than the one you are verifying.

Check from another machine with ssh-keyscan

When you cannot reach a console, ssh-keyscan fetches the server's public keys and ssh-keygen turns them into fingerprints:

ssh-keyscan -p 22 example.com | ssh-keygen -lf -

Add -t ed25519 to ssh-keyscan to fetch only one type. Change -p if the server listens on a different port.

Be clear about what this proves. ssh-keyscan does no verification of its own, so it only helps if it runs somewhere an attacker on your current network cannot reach: a server you already trust, a machine on another network, or your phone's hotspot instead of the café Wi-Fi. Running it on the same laptop over the same network as the suspicious connection proves very little. See the ssh-keyscan manual for its options.

How to verify the host key fingerprint matches

  1. Match the key type first. A server usually has several keys and your client shows the one it negotiated. If the prompt says ssh-ed25519, compare against the line ending in (ED25519); ssh-rsa corresponds to (RSA) and ecdsa-sha2-nistp256 to (ECDSA).
  2. Compare the whole string. Attackers can generate keys whose fingerprints share the first and last few characters with yours. Checking the whole value is what makes the check worth doing.
  3. Ignore grouping. Some apps split the fingerprint into blocks of four characters to make it easier to read. The spaces are cosmetic.

Publishing fingerprints in DNS

If you run many servers, SSHFP records (RFC 4255) publish host key fingerprints in DNS. Generate them on the server with:

ssh-keygen -r example.com

Clients using VerifyHostKeyDNS can then check keys automatically. Without DNSSEC on the zone the records can be forged like any other DNS answer, so only rely on them where DNSSEC is in place.

When a known server's key changes

A changed key after you have trusted one is the warning that matters most. There are innocent explanations:

The other explanation is that something is intercepting the connection, and from the client side the two look identical. So do not accept the new key until you know which it is. Find out whether the server was changed, then verify the new fingerprint exactly as you would for a first connection. With OpenSSH, once you are satisfied, remove the old entry with ssh-keygen -R example.com and connect again.

How Wharf handles host keys

The first time Wharf connects to an SFTP server it stops with an Unrecognised server prompt. It shows the key type and the SHA256 fingerprint, grouped in blocks of four, and the exact ssh-keyscan -p … | ssh-keygen -lf - command for that host and port so you can paste it into Terminal elsewhere. If the server presents a DSA key, Wharf warns that the key type is deprecated. You then choose Trust or Cancel.

Trusted keys are remembered per host and port, in Wharf's own list rather than your ~/.ssh/known_hosts. Later connections compare the full public key the server presents, not just its fingerprint. If it differs, Wharf does not offer a quick way through: it refuses to connect and shows both the expected and the received fingerprint, so you can investigate before going any further. When you connect through a jump host, each server's key is checked on its own (see SFTP through a jump host).

The same advice appears on the support page, and the rest of Wharf's security approach is summarised in its privacy section. Whatever client you use, the fingerprint prompt takes thirty seconds to check properly. It is worth those thirty seconds every time.