SSH Public Keys & Fingerprints via DNSSEC

Highlevel:
When you SSH to a host/server, the host/server sends its Public Key, much the same as an SSL connection allows you to do with a web-based https connection. This allows you to encrypt data from your client and send it to the host/server which has the Private Key to decrypt it.

With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.

Now back to SSH. When you first SSH to a host/server that your client PC has never seen, you need some way to verify the host/server Public Key. The reason for this is that a Man-in-the-Middle (MitM) attack could present their Public Key to you, decrypt what you say, and then encrypt it with what the host/server Public Key and you'd never know. The fix for this is to have a trusted way to get the Public Key from the host/server, or to verify the Fingerprint of the Public Key to see that it matches. The Fingerprint is a shortened version based on some math, but it is something you could quickly write down and sneakernet over or get from a phone call. That's great, but it's slow, and when you have dozens or hundreds of hosts/servers to manage, this really doesn't scale.

The good news is that OpenSSH has a "VerifyHostKeyDNS" option. What this allows one to do is take a specific DNS-formatted version of a Fingerprint (FP) and place it in DNS. Now, DNS suffers from the same MitM attack problem as anything else. However, we can sign DNS with DNSSEC and we already have trusted equivalents of CA Roots, in the form of the DLV.isc.org system, and eventually with DNSSEC signed DNS roots.

So here is the technical nitty-gritty details:
From the host/server, you can obtain the SSHFP record:

# ssh-keygen -r Eagle.roysdon.net -f /etc/ssh/ssh_host_rsa_key
Eagle.roysdon.net IN SSHFP 1 1 3db9b33e322a607a7013ebd2ed45b13e87b647e5

Now I just place this record in DNS and sign the roysdon.net zone with DNSSEC and we're all set:

$ dig +adflag SSHFP Eagle.roysdon.net. @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net.

; <<>> DiG 9.6.1-P1-RedHat-9.6.1-6.P1.fc11 <<>> +adflag SSHFP Eagle.roysdon.net. @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1385
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2

;; QUESTION SECTION:
;Eagle.roysdon.net. IN SSHFP

;; ANSWER SECTION:
Eagle.roysdon.net. 86334 IN SSHFP 1 1 3DB9B33E322A607A7013EBD2ED45B13E87B647E5

Note that I requested this query from a DNSSEC resolver that also supports DLV.isc.org lookups, and I requested the +adflag be set if the data could be marked as Authenticated Data (meaning the DNS server verified the signature of the record with a key that was signed by DLV.isc.org).

Ok, one minor problem with this is that it means we have to trust that the DNS reply with the AD flag set from the DNS server wasn't MitM attacked (or worse, that the DNS server wasn't compromised). One work-around is to run a local DNSSEC-enabled resolver on a local LAN that you trust. And even more heavy-handed work-around for this is to run a local DNSSEC-enabled resolver on your local machine. I believe eventually stub-resolvers or client software that is DNSSEC enabled is going to have to come to the desktop, but we'll see, and at least DNS servers won't be able to be comprised with bad records.

You can also generate SSHFP records for hosts which you don't have access to the ssh-keygen command (say a Cisco router/firewall or hardened Linux host w/o the command set) using an add-on command for Fedora called simply sshfp which will attempt to connect to the host and get the Fingerprint and generate the SSHFP record for you. Of course you want to make sure this is done on a trusted local LAN and not done remote so as to not introduce a MitM attack that you're now going to be putting in your trusted DNS records and signing with DNSSEC.

$ sshfp Eagle.roysdon.net
Eagle.roysdon.net IN SSHFP 1 1 3db9b33e322a607a7013ebd2ed45b13e87b647e5

One last note is that as of Fedora 11 the SSHFP method will still prompt you that "Matching host key fingerprint found in DNS." and not just accept the Public Key automagically. If you turn on verboseness (-v) you'll see it report, "found X insecure fingerprints in DNS" even though DNSSEC may be there. The problem is with the current version of glibc not asking for the +adflag and therefore the DNS server not setting it on, so SSH doesn't think the DNS reply was vetted. Fedora 12 Alpha appears to have the fix in for this (RH BugID 205842).