You may recall my speaking about SSH fingerprints about a year and a half ago, and that the situation wasn't as clear-cut as I wished for. Well, yesterday I stumbled over a patch by Simon Vallet dated 2007 which adds ldns support to OpenSSH, thinking "why wasn't that ever applied?". Thankfully, Henk Jan Agteresch told me that it was indeed applied in April of this year.

The patch replaces the getrrsetbyname() function with one which uses ldns to obtain SSHFP records from the DNS. If the resolver responds with Authentic Data (+AD) processing continues as it did in Jakob Schlyter's original implementation of getrrsetbyname(). The major difference in the patch (as I see it) is that ldns can attempt autonomous validation by verifying the signatures (RRSIG) in the DNS response, obtaining DNSKEYs as required in order to do so.

I configured and built a copy of OpenSSH portable version 6.01P1, adding --with-ldns to ./configure and installed that.

I have corresponding SSHFP records for the host ubu.jpmens.org in the DNS, and the zone is signed as it was during the initial test.

I start off by configuring my workstation to use a non-validating DNS server. (I've truncated lots of debugging output in the following for brevity.)

$ rm ~/.ssh/known_hosts
$ ./bin/ssh -v -o VerifyHostKeyDNS=true ubu.jpmens.org
OpenSSH_6.0p1, OpenSSL 1.0.0c 2 Dec 2010
debug1: Connecting to ubu.jpmens.org [192.168.1.182] port 22.
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 73:d3:0c:07:df:16:2a:c4:80:14:3e:dd:49:04:59:27
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'ubu.jpmens.org (192.168.1.182)' can't be established.
RSA key fingerprint is 73:d3:0c:07:df:16:2a:c4:80:14:3e:dd:49:04:59:27.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Nothing has changed: the connection succeeds, ssh informs us it has found 2 insecure fingerprints in the DNS (and correctly ignores them because they haven't been validated), doesn't find the target host's fingerprint in known_hosts and asks me whether I really want to connect to that host (supposedly I'll verify the fingerprint out-of-band. Hah! :-).

Next attempt. This time I configure my workstation to use a validating DNS server.

$ rm ~/.ssh/known_hosts
$ ./bin/ssh -v -o VerifyHostKeyDNS=true ubu.jpmens.org
OpenSSH_6.0p1, OpenSSL 1.0.0c 2 Dec 2010
debug1: Connecting to ubu.jpmens.org [192.168.1.182] port 22.
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 73:d3:0c:07:df:16:2a:c4:80:14:3e:dd:49:04:59:27
debug1: found 2 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
jpm@ubu.jpmens.org's password:

The result is quite different: ssh finds SSHFP records in the DNS, compares those to the host's fingerprint (they match), determines the DNS response is authentic (found 2 secure fingerprints in DNS), and continues into the authentication phase to ask for my password. It doesn't ask me to validate the fingerprint because SSH trusts the authentic DNSSEC response. And SSH doesn't store the fingerprint in .known_hosts either, which is fine -- it doesn't have to.

That's the way SSHFP should work.

Dear OS vendors and distribution packagers: please add --with-ldns to OpenSSH ASAP. #kthxbye

Flattr this
SSH, DNSSEC, and SSHFP :: 27 Jul 2012 :: e-mail

Comments

blog comments powered by Disqus