‹ Back
Deploy360 12 September 2013

FreeBSD 10 To Include OpenSSH With DNSSEC Support (for SSHFP records)

By Dan York Senior Manager, Content and Web Strategy

freebsd-logoVery cool news out of the FreeBSD team yesterday… the upcoming FreeBSD 10 will include support in OpenSSH for DNSSEC. The key point is this:

This means that OpenSSH will silently trust DNSSEC-signed SSHFP records.

What this means is this: when you go to ssh into an unknown system (i.e. one that is not in your “known_hosts” file), OpenSSH will do a query for a SSHFP record and use DNSSEC validation to ensure that the SSHFP record is indeed the one that the domain operator wants you to use.

This process of using a SSHFP record was defined in RFC 4255 back in 2006.  If you are familiar with how ssh (a.k.a. “secure shell“) works, when you connect to an unknown system for the first time you are presented with the “fingerprint” of the public key of the server to which you are connecting.  In theory you could verify this fingerprint through some out-of-band mechanism (perhaps seeing it on a web page or having received it separately in an email).  In practice, the vast majority of people just hit enter/return or type “yes” or something like that.

In the RFC 4255 mechanism, the operator of the server would publish a SSHFP record in DNS that would have the fingerprint of the SSH public key.  This is the same key fingerprint that would normally be presented to a user.  By using DNSSEC to sign the DNS zone that includes the SSHFP record, the server operator can provide a method for a DNSSEC-validating SSH client to verify that the SSH fingerprint is in fact the one that should be used to connect to the server.

This creates a higher level of trust and security in SSH connections.

It’s great to see this added to FreeBSD 10, which, according to the FreeBSD Release Engineering page, should be available sometime in November 2013.

For those curious, the SSHFP record is similar to what was defined six years later in RFC 6698 for the DANE protocol, which is really no surprise as they share a common author, Jakob Schlyter.  DANE’s TLSA record is a bit more complex and, for instance, allows for the inclusion of a complete SSL/TLS certificate rather than just a fingerprint.  In both cases, though, the idea is the same – use a DNS record to provide a means to verify a public key, and use DNSSEC to provide integrity protection so you know that you can trust the DNS record.

Great to see this being rolled out in an enabled state. Kudos to the FreeBSD team for doing this!

‹ Back

Related articles

How To Hack OpenSSH To Add DNSSEC Validation
Deploy36030 July 2012

How To Hack OpenSSH To Add DNSSEC Validation

Would you like to have SSH just automagically use DNSSEC to verify the authenticity of the SSH keys you are...

No, DNSSEC Would NOT Help Prevent Microsoft's Seizure Of Domains
Deploy3602 July 2014

No, DNSSEC Would NOT Help Prevent Microsoft's Seizure Of Domains

With a great bit of the tech media's attention this week on Microsoft's court-sanctioned seizure of 23 domains from dynamic DNS...

Want To Speak About Your DNSSEC Or DANE Work, Tool or Service? (ICANN52 CFP)
Deploy3604 December 2014

Want To Speak About Your DNSSEC Or DANE Work, Tool or Service? (ICANN52 CFP)

Will you be attending ICANN 52 in Singapore in February 2015?  If so, and if you work with DNSSEC or DANE ,...

Join the conversation with Internet Society members around the world