SSHFP SSH Fingerprint Common

What it's for

An SSHFP (SSH Fingerprint) record publishes a fingerprint of a server's SSH host key directly in DNS. Normally, the first time you SSH into a new host, you get the familiar "authenticity of host can't be established, are you sure you want to continue connecting?" prompt — your client has no way to verify the host key it's being shown is legitimate, so it just asks you to manually confirm (and most people just say yes without actually checking).

SSHFP solves this by letting your SSH client automatically look up the expected host key fingerprint via DNS and compare it against what the server presents — if they match, no prompt, no manual trust-on-first-connect step. This only provides real security benefit when the zone is DNSSEC-signed; otherwise an attacker could forge the SSHFP answer just as easily as they could forge the host key itself.

Format & syntax

host.example.com.    3600    IN    SSHFP    4 2 123456789abcdef67890123456789abcdef67890123456789abcdef123456

• Algorithm — the SSH key algorithm: 1 (RSA), 2 (DSA, deprecated), 3 (ECDSA), 4 (Ed25519)
• Fingerprint Type — the hash used: 1 (SHA-1, deprecated), 2 (SHA-256)
• Fingerprint — the hex-encoded hash of the public host key

A server can have multiple SSHFP records if it presents multiple host key types (common — most SSH servers offer both RSA and Ed25519, for example), and clients check the fingerprint matching whichever key type the server actually presents during connection.

How it's used in practice

• Automated/scripted SSH connections to dynamic infrastructure — in environments with frequently created and destroyed servers (auto-scaling groups, ephemeral CI runners), SSHFP lets automation trust new hosts based on DNS rather than needing a separate out-of-band host-key-distribution mechanism.
• Enabling VerifyHostKeyDNS in OpenSSH — client-side, setting VerifyHostKeyDNS yes (or ask) in ssh_config tells the SSH client to check SSHFP records and skip (or reduce) the manual trust-on-first-use prompt when the fingerprint matches.
• Reducing exposure to SSH MITM on first connect — the classic "TOFU" (trust on first use) SSH model has a real gap on that very first connection; SSHFP with DNSSEC closes that gap by giving the client an independently verifiable source of truth before it ever connects.

Common mistakes & gotchas

• Publishing SSHFP without DNSSEC — without DNSSEC signing, an attacker capable of manipulating DNS responses could forge the SSHFP record to match a malicious host key, completely defeating the purpose. SSHFP without DNSSEC provides essentially no additional security over the standard TOFU model.
• Forgetting to update SSHFP after regenerating host keys — if a server's SSH host keys get regenerated (a fresh OS install, a security rotation) but the SSHFP record isn't updated, clients relying on VerifyHostKeyDNS will see a mismatch and may refuse the connection or fall back to a manual prompt, which can look like a security incident when it's really just a stale DNS record.
• Only publishing one algorithm's fingerprint when the server offers multiple — if the SSH server presents an Ed25519 key by default but you only published the RSA SSHFP record, DNS-based verification will fail to match unless the client happens to negotiate the specific key type you did publish.
• Assuming most clients check SSHFP by default — VerifyHostKeyDNS is opt-in in OpenSSH, not the default, so publishing SSHFP records doesn't automatically protect every SSH client connecting to your server — the client also has to be configured to actually check.

Comparison & FAQ

Does SSHFP work without DNSSEC?

Not securely — like TLSA, SSHFP's security guarantee depends on the zone being DNSSEC-signed. Without DNSSEC, the SSHFP answer itself could be forged by an attacker in a position to manipulate DNS responses.

Do I need to configure anything on the client side to use SSHFP?

Yes — OpenSSH clients need VerifyHostKeyDNS set to yes or ask in their SSH config; it's not checked by default even when SSHFP records exist.

What happens if I regenerate my server's SSH host keys?

You need to update the SSHFP record to match the new key's fingerprint, or clients using DNS-based verification will see a mismatch and either refuse the connection or fall back to the normal manual trust prompt.

Can a host have multiple SSHFP records?

Yes, and it's common — one per host key algorithm the server supports (RSA, ECDSA, Ed25519), since a client's SSHFP check needs to match whichever specific key type the server actually presents during the connection.