I'm stuck figuring out why ssh is unable to verify my SSHFP entries.
VerifyHostKeyDNS=yes is set in my ~/.ssh/config

  • The Zone is properly signed as verified with https://dnssec-analyzer.verisignlabs.com.
  • SSHFP entries have been generated with ssh-keygen -r myhostname
  • dig +dnssec myhostname.myzone.tld answers with the proper RSIG entries and the do flag set (tested with internal resolver (pfsense) and external (quad1, quad8, quad9))

I have tested everything with my Ubuntu 18.04 machine and can verify that it works (DNSSEC and SSH key verification), but my MacBook "thinks different"

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:tV75nOBtVSASQEc4Ruf3iwBDAokvusd8BnLsfIWrzPQ
debug1: found 6 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'myhostname.myzone.tld (' can't be established.
ECDSA key fingerprint is SHA256:tV75nOBtVSASQEc4Ruf3iwBDAokvusd8BnLsfIWrzPQ.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

I had the same issue on my Ubuntu Machine as systemd-resolved had DNSSEC not enabled. But macOS's mDNSResponder has no options at all.
Could it be that macOS Catalina has no DNSSEC support (yet?/enabled by default?)

  • System: macOS Catalina 10.15.1
  • Local Resolver: pfsense (unbound)
$ uname -a
Darwin MacBook.home 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:18 CET 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64
$ ssh -V
OpenSSH_7.9p1, LibreSSL 2.7.3
  • Does dig +dnssec include the ad flag in its answer? What do you mean when you say the Local Resolver is "pfsense (unbound)"? You don't have pfsense running on your Mac, do you?
    – Old Pro
    Nov 23 '19 at 0:32
  • @OldPro I dont see the ad flag, but the do flag in the answer, regardles which server I ask. And by local Resolver I mean, mDNSResopnder asks my LAN local resolver (unbound) running on my pfsense, which in turn asks quad1. And I tested with dig +dnssec ... @ and @ (and without @... to get results from al servers in down the line). What is de meaning of the ad flag (authorative answer) in contrast to the do flag (dnssec ok)?
    – Daywalker
    Nov 23 '19 at 6:18

As it appears you know, you have to get your DNS entries and resolver to support DNSSEC before VerifyHostKeyDNS can possibly work.

This line in your output

debug1: found 6 insecure fingerprints in DNS

tells us that ssh found the the DNSSEC entries but did not trust them. This is most likely because it correctly asked for Authenticated Data (otherwise it would not find fingerprints at all) but the DNS resolver did not indicate the results were authenticated (otherwise the fingerprints would be labeled "secure" not "insecure").

First thing to do is verify that dig can validate your DNS by looking for the ad flag in the results of dig, like this (parts of the reply omitted for brevity):

$ dig +dnssec @ icann.org

; <<>> DiG 9.8.3-P1 <<>> +dnssec @ icann.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17489
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 1452
;icann.org.         IN  A

icann.org.      587 IN  A
icann.org.      587 IN  RRSIG   A 7 2 600 20191202002438 20191110134355 8150 icann.org. W9PTVWEF4Dd6fQmPRmaq9n7IMCds3JSRks1GB+JBHzrL63OX2QMZ7o1X YSZb90Rr6m2Di7ckcBiZtp/JGwvwEN2xPfWc5XubFsfQ8Vxpdze3o6DK llilOoHxrdTtnvYQ2djV+pWBoIkmX+eIKJSEhofy/c5K95nLxQ51RYBB AfU=

Note that ad (Authoritative Data) appears in the list of flags. This tells you that dig was able to validate the integrity of the data via DNSSEC. From the comments on the question, it appears that you are not seeing the ad flag, and so you need to address that by verifying that your DNSSEC keys are all correctly set up and that your DNS server supports DNSSEC. This includes making sure that your local DNS server has the correct root keys for validating the DNSSEC chain of trust.

Some other notes

Once you get the ad flag from dig, you still need to be mindful of the fact that, as noted in the dig man page on the Mac, dig uses its own query system, not the system-wide one, so all dig can really verify is that you have your DNS entries correctly set up on your name server and that the DNS server you are contacting support DNSSEC. For that matter, ssh does not necessarily use the system DNS either, although in your case it appears to be.

Also, from a security perspective, you still have the issue of trusting the DNS server you are talking to. Unless you also set up some kind of authentication between your host and the DNS server, you remain vulnerable to a man-in-the-middle attack.

  • I still seem to miss something... Ubuntu 18.04 Host; dig +dnssecoffers NO ad flag (regardless of servers I use). So does my mac. But the Linux machine connects just fine with just trusting the DNSSEC SSHFP entries (checked for ip, hostname, and FQDN in known_hosts and in verbose output). So even thou I understand what you are saying, and aggree, the technical truth seems to be somewhere else. Also DNSSEC is trustworthy. The only thing you could do is to disable DNSSEC on the resolving side, but then ssh is also not trusting your keys (as in my case). Any other ideas to check for?
    – Daywalker
    Nov 25 '19 at 17:11
  • The security issue with DNSSEC is that your computer is not talking directly to the DNS server and verifying the key, it is sending a network request to what it thinks is your local resolver on your pfsense device, and trusting the response it gets when the response has the ad flag set. If someone can spoof that response (say with malware implanted on your pfsense) then they can send your computer a response with bad information that appears to have been validated via DNSSEC. Similar MITM attacks are possible with network DNS resolvers like without additional cryptography.
    – Old Pro
    Dec 1 '19 at 23:03
  • But that's why all the Devices Have Root keys installed locally. So they can verify the DNSSEC chain of trust from the root . Zone onward down to the rewuested RRSIG entry. That's so you can prevent a MITM attack as you described it, right? Which also implies that a client would have to to the recursion from top down to the specific entry to get that chain. So what am I missing here? Where is the security flaw in DNSSEC in this case? and where is my error? Or are you trying to tell me thas DNSSEC will never work on a (Mac) Client?
    – Daywalker
    Dec 6 '19 at 8:42
  • @Daywalker The DNS server on the pfsense device has (or at least should have) root keys and verifies the DNSSEC entries, but the DNS client on the Mac does not. The Mac queries the DNS server on the pfsense and trusts that when the response includes the ad flag that the DNS information has been authenticated via DNSSEC. Therefore someone spoofing/modifying the response from the pfsense server could return bad data with the ad flag set, subverting the security. You would need to install something special on the Mac to eliminate this vulnerability (not enough space here to explain).
    – Old Pro
    Dec 6 '19 at 19:15
  • ok, I get what you are trying to say. So the Mac does in deed not check the full chain by itself. Thanks again
    – Daywalker
    Dec 7 '19 at 20:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .