This article describes a solution to the problem where people answers ‘yes’ on the question if they are sure they want to continue connection to a new/unknown SSH server. The solution is to publish SSHFP records in DNS.
Have you ever blindly answered yes to something like this?
The authenticity of host 'framkant.org (52.16.239.146)' can't be established. ECDSA key fingerprint is 42:f9:b3:40:17:61:89:e4:80:cf:d5:ae:bb:bb:7d:75. +--[ECDSA 256]---+ | ....o+o | | . oooo. | | o .=.. | | oo o. | | o.S | | .o o . E | | .. . . | | .. . | | ++.. | +-----------------+ Are you sure you want to continue connecting (yes/no)?
Well, dont. Of course its very important to know WHERE you are connecting. In a directed attack the attacker could have set up a server of their own to fool you to reveal important passwords or other information. But most people dont think to much about this and just answers yes to get rid of the message.
The problem is, HOW do you distribute the correct fingerprint and check it? In a datacenter there are many was to do this (configuration orchestration, ldap and so on) but to end users and home computers this is a probem. Of coruse you could post your fingerprints on a webpage secured with https, but the chances a user would really sit down and compare the numbers are slim.
The solution is DNSSEC. When your zone is signed and the chain of trust is complete a client can really trust the correctness of the information present in the DNS tree. Publishing your ssh host key fingerprints here sounds like a great idea. The new record type SSHFP solves this problem and the good news is that OpenSSH have support since a few years back. Its even so simple that ssh-keygen can generate the new records for you:
> ssh-keygen -r framkant.org framkant.org IN SSHFP 1 1 d6a64454a9a559ec35f59994c2e5f8376ff86ac8 framkant.org IN SSHFP 1 2 99d78eff62823561bab2661a72250f1e8344c1c6a4e8903f0d5d8ebce6d819b7 framkant.org IN SSHFP 2 1 9572024308e542074768bbfd6a3ff8b30e940ce2 framkant.org IN SSHFP 2 2 ab63e4ebe5ba0b9eb12a9735a533cfdf5e2807bac852e8b019dedfb630841896 framkant.org IN SSHFP 3 1 fe1160646ac00872d269ebd7ddaa07cb83d7d6af framkant.org IN SSHFP 3 2 6580debbe37b4a2f32eed78aec2e2f943de6559f24f2b6d7671e78a0ca469728
The first digit represent the key type and the second represent the hash used. You can read more about this in RFC 4255. If your zone is signed by DNSSEC and the chain of trust is complete you will see something like this when connecting to a server with SSHFP records attached to it.
debug1: Server host key: ECDSA 42:f9:b3:40:17:61:89:e4:80:cf:d5:ae:bb:bb:7d:75 debug1: found 6 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS debug1: ssh_ecdsa_verify: signature correct
OpenSSH uses two different methods to find out if the records are secured by DNSSEC. If compiled with ldns-support it will perform the DNSSEC-validation itself. If not, it will trust the resolvers in resolv.conf to do the validation. The resolver will set a special bit, the AD-bit (Authenticated Data) if dnssec validates. If the AD-bit is set on the response from the resolver ssh will assume that the records can be trusted.
If you want ssh to always try to use information found in DNS add this to your ~/.ssh/config
Host *
VerifyHostKeyDNS yes
References
RFC 4255