SSHFP records to verify SSH host keys

The SSHFP record, meaning SSH fingerprint, is a DNS record that stores the cryptographic fingerprint of an SSH host key. It gives SSH a way to verify that the key your client just received really belongs to the server you meant to connect to, using the domain name system and the trust chain of DNSSEC, instead of asking you to accept the key on first use and remember it forever.

What SSHFP solves

When you connect to an SSH server for the first time without SSHFP or a pre-seeded known_hosts entry, the client has no way to know the key it receives is genuine. It shows you the fingerprint and asks you to trust it, a practice called trust on first use. If an attacker on the route has already swapped their key in, you may approve the wrong host and only discover it later.

An SSHFP record, defined in RFC 4255 and extended for SHA-256 and elliptic curve keys in RFC 6594, removes that guess. The server operator publishes a fingerprint of the server's public host key in DNS. When the DNSSEC-signed zone is trustworthy, an SSH client that is configured to check can compare the key the server presents against the fingerprint from DNS and reject a mismatch automatically, with no first-use prompt.

For the lookup to be secure, the zone must be signed and validated with DNSSEC. An SSHFP record in a plain, unsigned zone proves nothing, because an attacker who can alter the connection can also alter the DNS answer, which is why the trust ends at the DNSSEC chain.

Generating the record

To build an SSHFP record, generate a fingerprint of each host's public key, then publish it under the host's name in DNS. There is a dedicated SSHFP record type, and the format is:

<hostname>.  IN SSHFP <algorithm> <fingerprint-type> <hex-fingerprint>

The first number names the public key algorithm and the second names the digest type. For an RSA host key with a SHA-256 fingerprint, that is algorithm 1 and fingerprint type 2, and for an ECDSA key the algorithm index differs. The safest way to produce the value is a tool that knows the indices, but you can compute a SHA-256 over the public key bytes yourself and record it with the matching algorithm number; the SSHFP value is the hex digest of the SSH public key blob.

A common way to generate the record text on a Linux server is to ask the local OpenSSH tooling for the hashed key and format it as the record, then copy that into your DNS provider as an SSHFP record along with the algorithm and fingerprint-type numbers. If you manage several servers, add one SSHFP record per host key so clients can match any that are in rotation.

Enabling client verification

On the client, tell SSH to check SSHFP records and to accept a host only when the DNS fingerprint and the presented key agree. An example ~/.ssh/config entry:

Host myserver
  HostName server.example.com
  VerifyHostKeyDNS yes

With VerifyHostKeyDNS yes, the client prefers the DNS-obtained fingerprint. Set it to ask to prompt only when the fingerprint is missing from known_hosts and the host key looks uncertain. Adding the argument -o VerifyHostKeyDNS=yes on a one-off connection does the same without changing the config file.

Keep the zone signed and validated for this to be meaningful, and remember that SSHFP describes the server's host key, not the account, so it protects against a wrong or spoofed server, not a stolen password or a compromised account. See the DNS record types reference for where SSHFP sits, DNSSEC zone signing for making the zone trusted, and DS record validation for the chain that proves it.