SSHFP Records: Pin SSH Host Keys in DNS

An SSHFP record publishes the fingerprint of a server's SSH host key in DNS, so an SSH client can verify it is talking to the right machine on the very first connection instead of asking you to eyeball a fingerprint you have no way to check. It turns the familiar "are you sure you want to continue connecting?" prompt into an automatic yes or a hard no. This guide explains how SSHFP records are structured, how to generate them, how a client uses them, and why DNSSEC is the piece that makes the whole thing trustworthy.

The problem SSHFP solves

The first time you SSH to a new server, the client has never seen its host key, so it prints the key fingerprint and asks you to confirm. Almost nobody verifies that fingerprint out of band, which means the single most dangerous moment, the first connect, is usually a blind trust-on-first-use. SSHFP records move that fingerprint into DNS where the client can fetch and compare it automatically. If the key the server presents matches the published fingerprint, the connection proceeds with no prompt; if it does not, the client warns or refuses.

SSHFP is defined in RFC 4255, extended by RFC 6594 for ECDSA and SHA-256, and by RFC 7479 for Ed25519 (all current as of November 2026).

Anatomy of an SSHFP record

An SSHFP record lives at the server's hostname and carries three parts: an algorithm number identifying the key type, a fingerprint type identifying the hash, and the hash itself in hex.

server.example.com.  IN SSHFP 4 2 abc123...def  ; Ed25519 key, SHA-256 digest

A server usually offers more than one host key type, so you will typically publish several SSHFP records at the same name: one per algorithm, each with the SHA-256 fingerprint. Publish SHA-256 (type 2) and skip the old SHA-1 (type 1) digests, which modern clients treat as insecure.

Generating the records

You do not hand-compute these. OpenSSH generates ready-to-paste SSHFP lines directly from the host keys on the server:

$ ssh-keygen -r server.example.com
server.example.com IN SSHFP 1 2 7f8a...   ; RSA, SHA-256
server.example.com IN SSHFP 3 2 2b19...   ; ECDSA, SHA-256
server.example.com IN SSHFP 4 2 c6d4...   ; Ed25519, SHA-256

Run that command on the server itself, because it reads the live host keys in /etc/ssh. Copy the output into your zone as individual SSHFP records. If you regenerate host keys, for example after rebuilding a box, you must regenerate and republish the records or clients will see a mismatch.

Turning on client verification

SSHFP lookups are off by default. The client only consults DNS when you ask it to, with the VerifyHostKeyDNS option:

• VerifyHostKeyDNS yes: trust a matching SSHFP record automatically and connect without a prompt, but only when the record is DNSSEC-validated.
• VerifyHostKeyDNS ask: show the matching DNS fingerprint in the prompt so you can confirm with more confidence.
• VerifyHostKeyDNS no: the default; DNS is ignored entirely.

Set it per host or globally in ~/.ssh/config or /etc/ssh/ssh_config. On the command line it looks like ssh -o VerifyHostKeyDNS=yes server.example.com.

Why DNSSEC is not optional here

This is the detail that trips people up. With VerifyHostKeyDNS yes, OpenSSH will only skip the prompt and trust the record if the DNS answer carries an authenticated-data signal, which means the zone is DNSSEC-signed and the resolver validated it. If the zone is unsigned, the client falls back to the normal prompt as though no record existed, because an unsigned SSHFP record could have been forged by whoever controls the network path. In other words, SSHFP without DNSSEC gives you convenience in logging but not real authentication. Sign the zone, confirm your resolver validates, and only then does automatic verification actually protect against an impostor host.

A quick checklist to deploy SSHFP safely

1. Confirm the zone is DNSSEC-signed and your query path validates.
2. Run ssh-keygen -r hostname on the server to produce the records.
3. Publish the SHA-256 (type 2) records for each key algorithm you serve.
4. Set VerifyHostKeyDNS yes on clients that will rely on it.
5. Test a fresh connection and confirm no fingerprint prompt appears.
6. Re-run and republish whenever host keys change.

Reading and checking a record

Pull the records with dig and request DNSSEC data so you can see whether they are signed:

$ dig SSHFP server.example.com +dnssec +short
4 2 c6d4b2...9af0
3 2 2b1977...1c3e

A connection made with ssh -v -o VerifyHostKeyDNS=yes logs a line such as "matching host key fingerprint found in DNS" when everything lines up. If you see "found but not trusted" or no DNS line at all, the usual cause is an unsigned zone or a non-validating resolver rather than a wrong fingerprint.

Where SSHFP fits

SSHFP is most valuable when you automate SSH at scale: provisioning fleets, running configuration management, or onboarding new machines where a human will never verify a fingerprint by hand. In those settings a signed SSHFP record is the difference between blind trust-on-first-use and genuine verification. For the signing side that makes it real, see DNSSEC basics, and if you want the lookups themselves to travel privately, our guide to encrypted DNS covers DoH and DoT.

After you publish, run the hostname through the Valla DNS DNS lookup tool to confirm the SSHFP records resolve as expected before you flip clients over to automatic verification.

Do I need DNSSEC for SSHFP to work?

For real security, yes. OpenSSH with VerifyHostKeyDNS set to yes only trusts the record automatically when the answer is DNSSEC-validated. On an unsigned zone the client ignores the record and falls back to the normal first-connect prompt.

Which fingerprint type should I publish?

Publish type 2, the SHA-256 digest. Type 1 is SHA-1 and is considered weak; modern clients disregard it. You can safely publish only the SHA-256 records and drop the SHA-1 ones entirely.

How do I generate SSHFP records?

Run ssh-keygen -r hostname on the server. It reads the live host keys and prints ready-to-paste SSHFP lines for each key type. Copy those into your DNS zone as separate records.

What happens if I rebuild a server and its host keys change?

The old SSHFP records no longer match the new keys, so clients will warn about a mismatch. Regenerate the records with ssh-keygen -r on the rebuilt server and republish them, replacing the stale entries.

Can I have multiple SSHFP records for one host?

Yes, and you normally will. A server offers several host key algorithms, so you publish one record per algorithm at the same name. The client matches against whichever key type it negotiates for the session.