I'm stuck figuring out why ssh is unable to verify my SSHFP entries.
VerifyHostKeyDNS=yes is set in my
- The Zone is properly signed as verified with
- SSHFP entries have been generated with
ssh-keygen -r myhostname
dig +dnssec myhostname.myzone.tldanswers with the proper RSIG entries and the
doflag 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 (192.0.2.1)' 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.
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
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
tells us that
sshfound 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
digcan validate your DNS by looking for the
adflag in the results of
dig, like this (parts of the reply omitted for brevity):
ad(Authoritative Data) appears in the list of
flags. This tells you that
digwas able to validate the integrity of the data via DNSSEC. From the comments on the question, it appears that you are not seeing the
adflag, 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
dig, you still need to be mindful of the fact that, as noted in the
digman page on the Mac,
diguses its own query system, not the system-wide one, so all
digcan 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,
sshdoes 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.