#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