How do I verify my server's SSH fingerprint?

The first time you connect to a server over SSH, your client shows the server’s host key fingerprint and asks you to confirm it:

The authenticity of host 'lon002.arandomserver.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:abcdef0123456789...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Blindly accepting this prompt leaves you open to a man-in-the-middle (MITM) attack. To be safe, you need to compare the fingerprint against a known source. We publish our servers fingerprints publicly via SSHFP DNS records, which can be used to automatically or manually verify your SSH/SFTP connections upon connecting.

Want to look up your server's SSHFP record? Use the built-in lookup tool on this page — no software to install. Open the tool

What is a host key fingerprint?

Every SSH server has multiple host keys (one for each offered algorithm), which includes a public & private key pair. The fingerprint is a short hash of the public key being offered by the server. By comparing the fingerprint of the public key being offered to a known trusted value tells you whether you’re talking directly with the server, or if there is something standing in the middle.

Getting an SSH/SFTP host key fingerprint

There are two primary ways to get a hosts SSH/SFTP host key fingerprint:

1. When you first connect to a servers SSH/SFTP server, your client will offer a fingerprint of the servers public key and ask if you would like to trust it. Compare this fingerprint with a trusted value (EX, our SSHFP DNS records).

2. By ssh-keyscan & ssh-keygen you can retrieve a servers host public key and convert it to a fingerprint.

ssh-keyscan -t ed25519,rsa lon002.arandomserver.com | ssh-keygen -lf -

What these options do

ssh-keyscan -t ed25519,rsa tells the client to retrieve only the ed25519 & rsa key types. To retrieve all the supported keys, omit the -t switch entirely.

ssh-keygen -lf - the -l switch tells the client to print the fingerprint of the public key offered. The -f tells the client which public key to process. Since we’re piping the output of ssh-keyscan to it, we tell it to read from stdin by passing a dash (-).

What are SSHFP records?

SSHFP (SSH Fingerprint) records publish a server’s host key fingerprints in DNS. Because they’re retrieved from the DNS system rather than over your SSH connection, they give you an independent reference to check against. There are two ways to use them:

1. Automatically — tell your SSH client to look them up and do the comparison for you.
2. Manually — look the record up yourself with dig or using the the tool below.

Either way, protection is strongest when the server’s domain is signed with DNSSEC, which cryptographically guarantees the DNS answer itself wasn’t tampered with.

Method 1: Let your SSH client verify DNS automatically

Ask SSH to verify the host key against DNS when you connect:

ssh -o VerifyHostKeyDNS=yes lon002.arandomserver.com

If a matching, DNSSEC-validated SSHFP record is found, SSH accepts the host key automatically without showing the usual “are you sure you want to continue connecting?” prompt.

To make this the default for every connection, add it to your ~/.ssh/config:

Host *
    VerifyHostKeyDNS yes

What this option does

• -o VerifyHostKeyDNS=yes — tells SSH to look up the server’s SSHFP DNS record and use it to verify the host key. With a valid DNSSEC-signed record, SSH trusts the match automatically and skips the manual prompt. Use ask instead of yes to be shown the DNS result and prompted, rather than trusting it silently.

Automatic verification often fails silently

Many SSH clients and setups cannot perform this check reliably:

• Most graphical clients (PuTTY, WinSCP, FileZilla, Cyberduck, and similar) don’t support SSHFP lookups at all.
• OpenSSH will only auto-trust the record when your system’s DNS resolver performs DNSSEC validation and returns the ad (authenticated data) flag. Many ISP, router, and public resolvers don’t pass this flag through causing SSH to quietly fall back to the normal “are you sure you want to continue connecting?” prompt as if no record exist.

If you don’t see the message “Matching host key fingerprint found in DNS” when you connect, do not assume the connection was verified. Use the manual lookup in Method 2 with dig +dnssec instead, and confirm the ad flag is present.

Method 2: Look up the SSHFP record manually

If you’d rather inspect the record yourself — for example to confirm it exists, or to check it from a different, trusted network before you first connect — you can query DNS directly.

The quickest option — including on Windows — is to look the records up right here in your browser (this uses DNS-over-HTTPS, so it works without any tools installed):

Hostname

Look up SSHFP

On macOS, Linux, or WSL (dig)

With DNSSEC (recommended) — request DNSSEC data and confirm the answer was signed & authenticated (Hawk Host customers use this method):

dig +dnssec SSHFP lon002.arandomserver.com

Look at the flags line in the output. If it includes ad (Authenticated Data), your resolver validated the DNSSEC signatures and the record can be trusted:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...
lon002.arandomserver.com. 3600 IN SSHFP 4 2 abcdef0123456789...

Without DNSSEC - you can still retrieve the record, but this is not signed, and therefore there is no guarantee this is not spoofed.

dig +short SSHFP lon002.arandomserver.com

1 2 BDFF07413D77DEB077320097B35D05BB7F8B8EC3C8EB291962718472 16AA59D7
3 2 15A48EB5C8848A2963AAF8CDC598B110D7FB18B2FE7474935B22C6E2 AFEF27A5
4 2 9A0A28F191FA774AA47622CE2C748CF2A6EE11FAC7D4343145123493 13D96AD7

What these flags do

• dig — command-line tool for querying DNS records.
• SSHFP — the record type to look up.
• +dnssec — request DNSSEC signature data, so the resolver reports whether the answer is authenticated (the ad flag).
• +short — print only the record’s value instead of the full, verbose response.

On Windows

Windows’ built-in tools cannot query SSHFP records (DNS record type 44) — neither nslookup nor PowerShell’s Resolve-DnsName support them. The easiest path on Windows is the in-browser lookup tool above.

If you’d prefer a command line, run dig from WSL (Windows Subsystem for Linux) or manually check using the form below:

Hostname

Look up SSHFP

Confirming the match

The interactive SSH prompt shows the fingerprint as SHA256: followed by a base64 string, while the SSHFP record stores it as hexadecimal — so the two aren’t meant to be compared by eye. Instead, once you’ve confirmed an authentic record exists in DNS, let SSH do the byte-for-byte comparison for you:

ssh -o VerifyHostKeyDNS=yes lon002.arandomserver.com

If the key the server presents matches the SSHFP record, SSH reports “Matching host key fingerprint found in DNS” without prompting you, confirming you’ve reached the genuine server.

Caution

SSHFP verification is only as trustworthy as the DNS lookup behind it. Without DNSSEC, the SSHFP response could itself be spoofed by an attacker who controls your DNS. For meaningful protection the server’s domain must have DNSSEC enabled — see How do I enable and configure DNSSEC on my domains?.

Related Articles

• How do I log into SSH?
• Do you offer SSH access?
• How do I enable and configure DNSSEC on my domains?

If you have trouble verifying your server’s fingerprint, please submit a support ticket and our team will be happy to help.