SSHFP Anchors SSH Host Key Fingerprints in DNSSEC
An SSH client has to decide whether the host key presented by a server belongs to the intended host. A previously stored key can provide that reference on later connections, but the first connection needs another basis for authentication. SSHFP places a fingerprint of an SSH host public key in DNS so a client can compare the server key with independently retrieved data. The DNS record alone is not a trust anchor. RFC 4255 ties trusted SSHFP verification to authenticated DNS data. DNSSEC protects the lookup path and lets a validating client distinguish signed data from an unauthenticated DNS answer. The useful security property comes from that combination: SSH supplies the host key, SSHFP carries its fingerprint, and DNSSEC authenticates the DNS record used for comparison.