SSHFP: SSH host key fingerprint

Publishes an SSH host key fingerprint in DNS. With the zone signed under DNSSEC, a client verifies the fingerprint it gets from DNS instead of trusting the key on first connect.

In one line:

bastion.example.com.    SSHFP    4 2 9f8b76e2...
└── this host ──────┘   └type┘   └── has this SSH key fingerprint

What it holds#

Code assignments: IANA DNS SSHFP registry. A host typically publishes one SSHFP per key type it offers; the client fingerprints the key the server presents and compares it against whichever record matches.

When to use it#

• Servers that need unattended trust (CI runners, ephemeral instances) without an operator confirming an unknown fingerprint by hand.
• Any host in a zone that runs DNSSEC end to end.
• Fleets where distributing known_hosts by hand does not scale.

When not to use it#

• Without DNSSEC. RFC 4255 §2.4 requires a client that does not validate the signature itself to reach the validator over a secure channel; an unsigned zone gives it neither, so the record authenticates nothing.
• Single-host setups with one operator: known_hosts is simpler.

dig example#

$ dig @1.1.1.1 sshfp.example.isitdns.net SSHFP

The demo zone publishes a live SSHFP at sshfp.example.isitdns.net (Ed25519, SHA-256).

DoH query (HTTPS)#

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=sshfp.example.isitdns.net&type=SSHFP' \
  | jq '{AD: .AD, answer: .Answer}'

{
  "AD": true,
  "answer": [
    {
      "name": "sshfp.example.isitdns.net",
      "type": 44,
      "TTL": 300,
      "data": "4 2 ( 0766E147A76CEA6A5F9F098742FDF4E6229977DC84291F9D528990E5BE4A3A2D )"
    }
  ]
}

AD: true means Cloudflare's resolver validated the chain for this answer (RFC 4035 §4.9.3); you are trusting its validation, not doing your own.

Gotchas#

• SHA-1 (type 1) is deprecated. Publish SHA-256 (type 2) only, unless very old clients need SHA-1.
• ssh trusts the resolver's AD bit, not its own validation. OpenSSH does not validate DNSSEC itself: verify_host_key_dns() calls getrrsetbyname(), which marks a record validated only when the resolver's answer carries the AD bit (OpenSSH openbsd-compat/getrrsetbyname.c). That bit travels unauthenticated from the resolver to the client, so it only means something if the path to the resolver is trusted, in practice a validating resolver on localhost (RFC 4255 §2.4).
• VerifyHostKeyDNS defaults to no. yes trusts a validated match and skips the host-key prompt; ask shows the match but still prompts (ssh_config(5)).
• Host key rotation drives churn. Every host-key change requires updating SSHFP; ssh-keygen -r hostname -f keyfile regenerates the records for a key file.
• Multiple keys per host. Publish SSHFP for each key type the host offers; the client matches on whichever key the server presents.
• Wildcards skip names that exist. A host with its own A/AAAA gets no SSHFP from *.example.com (RFC 4592 §2.2.1).

See also#

• DNSSEC troubleshooting
• TLSA: the same idea for TLS certs (DANE)
• All record types: cheat sheet
• nslookup and dig: tool reference
• DNS over TLS and HTTPS