Log in

No account? Create an account


On the safety of SSHFP records.

« previous entry | next entry »
31st Jan 2012 | 12:30

Proper SSH hygiene is to go through a manual procedure the first time you log into a host to verify that its public key is the one you expect. RFC 4255 specifies a way to use the DNS to verify ssh host keys so you can skip the manual process. The host key fingerprint is published in an SSHFP record in the DNS and is authenticated using DNSSEC.

OpenSSH supports SSHFP lookups if you turn on the VerifyHostKeyDNS option (documented towards the end of ssh_config(5)). OpenSSH does not do any DNSSEC validation of its own, and instead relies on the "authenticated data" flag (the AD bit) in the response from a validating resolver. Its SSHFP checking logic is a bit more complicated than you might expect:

  • If the host key does not match then ssh puts up its usual scary banner, regardless of the AD bit.
  • If the host key matches and the AD bit is set in the DNS response, then ssh connects happily, bypassing the manual check.
  • If the host key matches but the AD bit is clear, ssh goes into the usual unknown host procedure, with an added note about the presence of a matching SSHFP record.

As the RFC explains, none of this is safe unless you are running a validating resolver on the same machine as ssh (or with some other secure communication channel), and the resolver has a chain of trust to your target host's zone.

I am not entirely sure that ssh's behaviour in the no-AD situation is wise. It won't happen in a correct setup, but it's the accidentally incorrect setups that worry me. In particular, if someone has configured their machine to use one of Cambridge University's central validating resolvers and they turn on VerifyHostKeyDNS, then ssh will see the AD bit in DNS replies but it will not be trustworthy because it travelled over the network between resolver and ssh client without verification. There are also quite a lot of non-validating resolvers in the University (e.g. used by the Linux timesharing servers, and handed out by the Eduroam WiFi DHCP servers) and users of those will get ssh's note about matching SSHFP records, and this might give them a false sense of security since it doesn't mention the lack of verification.

So I'm in two minds about deploying SSHFP records. If we add them for hosts such as hermes.cam.ac.uk we need to be confident that people who turn on VerifyHostKeyDNS also run their own validating resolver. However there is no warning in the OpenSSH manual pages that this is necessary - in fact no mention of DNSSEC at all, nor any explanation of the difference between secure and insecure DNS fingerprints.

These worries would not exist if OpenSSH did its own DNSSEC validation of SSHFP records, and if it did not do questionable things with untrusted SSHFP records.

| Leave a comment |

Comments {2}


It's still an improvement

from: mas90
date: 31st Jan 2012 13:51 (UTC)

To me, the question is not "is SSHFP verification absolutely secure?" but "is it better than the alternative?".

I know I—like many others—don't perform adequate manual verification of the host key when ssh asks me to. Any automatic host key checks can only reduce the likelihood that I will allow through a bogus key; SSHFP, even without a local validating resolver, will catch the situation in which the SSH server is being impersonated (perhaps by a very distant attacker) but the SSHFP record I receive has not been tampered with (perhaps because the attacker has no access to the relatively short stretch of network between me and the University's validating resolvers).

(Ultimately, though, this and many other issues would be entirely avoided if every OS were to ship a proper validating resolver. Why is nobody doing this?)

Reply | Thread


from: nonameyet
date: 1st Feb 2012 06:03 (UTC)

You can turn 2 into 3 by using VerifyHostKeyDNS=ask rather than VerifyHostKeyDNS=yes. I think that "yes" should only give you the functionality of "ask" (and the message should make clear whether the key in the DNS was securely validated or not).

If the key comes from the DNS it is not something I have verified, so should never be assumed OK.

Reply | Thread