[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