WhyPublishing of SSH key fingerprints using DNS record to allow verification of host authenticity.

See also
  • Requirement: DNS, DNS records, OpenSSH
  • Related: SSHFP in the records page: the zone-file form of what is generated here, and which algorithm and digest are worth publishing

A fingerprint is used to ensure that the server on which we are going to connect through ssh is the one expected and that its identity has not been altered. This fingerprint must be registered by the user in its list of known hosts (~/.ssh/known_hosts), by which means they get it and check its authenticity is usually left to them.

Here the DNS is used to solve the fingerprint transmission problem, but of course it is assumed that you trust the DNS for that. The SSHFP record is used to associate a hostname with its ssh fingerprint, revoking an obsolete or compromised key is as simple as removing the SSHFP record (its fingerprint).

TTL (Time To Live) associated with the record can delay its revocation.

That trust has to be earned by DNSSEC. An unsigned SSHFP answer can be forged by whoever is already in a position to forge the host key, so it protects against nothing an attacker of that kind cannot do — which is why VerifyHostKeyDNS set to yes only accepts a matching record silently when the answer is DNSSEC-validated, and still asks otherwise.

The following command, to be executed on the selected server, generates records to be placed in the DNS, the keys being taken into account are the one from the server (by default: /etc/ssh/ssh_host_*_key.pub).

Generating SSHFP records
ssh-keygen -r Computer hostname to insert into DNS

It remains to ask the ssh client to take into account the SSHFP records, for this, the following line is inserted either in the global configuration (/etc/ssh/ssh_config) or in the configuration of each user (~/.ssh/config).

VerifyHostKeyDNS yes