[MacPorts] #49007: openssh @6.9p1 +ldns SSHFP DNSSEC validation fails

MacPorts noreply at macports.org
Wed Sep 30 01:37:07 PDT 2015


#49007: openssh @6.9p1 +ldns SSHFP DNSSEC validation fails
------------------------------+--------------------------------
 Reporter:  scott-macports@…  |      Owner:  macports-tickets@…
     Type:  defect            |     Status:  new
 Priority:  Normal            |  Milestone:
Component:  ports             |    Version:  2.3.3
 Keywords:  haspatch          |       Port:  openssh
------------------------------+--------------------------------
 ssh performs SSHFP fingerprint lookup when VerifyHostKeyDNS is yes or ask.

 The +ldns variant support validating the SSHFP with DNSSEC.  SSHFP of host
 keys validated this way are implicitly trusted.  If the resolver has
 DNSSEC validation, and sets the AD bit on the DNS response, ldns will mark
 the SSHFP valid without further work.  If the resolver does not support
 DNSSEC, or is authoritative for the domain (eg internal DNS), then ldns
 must perform the validation locally (the AD bit is not set).  For this,
 ldns needs a trust anchor.

 I couldn't find anything in the ldns documentation, but the code in
 ldns/resolver.c looks for the keyword "anchor" in /etc/resolv.conf to
 locate a file containing a DS or DNSKEY RR, and loads it as a trust
 anchor.  Without a trust anchor, local DNSSEC validation always fails.

 Adding the "anchor" field to resolv.conf allows ldns validation to
 succeed.  However, OSX re-creates resolv.conf from scutil's DNS config
 whenever the network changes... edits to /etc/resolv.conf are lost.

 The only solution to get ldns validation to work on OSX is to add a trust
 anchor from a specific file (at least when it is needed for local
 validation)

 I've created a patch to openssh to do this... I chose a "well-known" file
 location for the trust anchor, /etc/trusted-key.key (used by dig, freeipa,
 etc).  The other option was drill's default: /etc/unbound/root.key, but
 that seemed rather "unbound specific."

 I wasn't sure if I should look for the file in /etc directly, or
 ${prefix}/etc, so the attached patch attempts to load from both locations.

 I was able to locate a bug filed upstream in 2013:
 https://bugzilla.mindrot.org/show_bug.cgi?id=2119 - but it's been stale
 for a long time, and could be worked around on platforms other than OSX by
 adding the "anchor" key to resolv.conf as discussed above (although again,
 that appears to be undocumented behavior on ldns's part).

 I plan to update my patch for upstream with an option to "configure" the
 trusted-key.key filename, but a patch for that would be overkill for
 macports -- and as the fix is very OSX specific, I'm not sure if it'll be
 accepted upstream.

 Relevant logs before the patch: (from ssh -vv <host>)
 {{{
 debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Server host key: ssh-ed25519
 SHA256:a13QzFT87p7agd2MuagyOn7QfsegaUrvgB/M+smt1Zx
 debug2: ldns: got 4 answers from DNS
 debug2: ldns: trying to validate RRset
 debug2: ldns: got 1 signature(s) (RRTYPE 46) from DNS
 debug2: ldns: RRset validation failed: General LDNS error
 debug1: found 4 insecure fingerprints in DNS
 debug1: matching host key fingerprint found in DNS
 debug1: Host '[myhost]:8222' is known and matches the ED25519 host key.
 debug1: Found key in /Users/test/.ssh/known_hosts:12
 debug2: bits set: 2062/4096
 }}}

 After the patch:
 {{{
 debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Server host key: ssh-ed25519
 SHA256:a13QzFT87p7agd2MuagyOn7QfsegaUrvgB/M+smt1Zx
 debug2: ldns: got 4 answers from DNS
 debug2: ldns: attempt to load trust anchor from file /etc/trusted-key.key
 debug2: ldns: new anchor added to trust chain
 debug2: ldns: attempt to load trust anchor from file /opt/local/etc
 /trusted-key.key
 debug2: ldns: file not found
 debug2: ldns: trying to validate RRset
 debug2: ldns: got 1 signature(s) (RRTYPE 46) from DNS
 debug2: ldns: RRset is signed with a valid key
 debug1: found 4 secure fingerprints in DNS
 debug1: matching host key fingerprint found in DNS
 debug2: bits set: 2062/4096
 }}}

 note: this port does not have a maintainer

-- 
Ticket URL: <https://trac.macports.org/ticket/49007>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list