$ rpm -q openssh-clients openssh-clients-7.8p1-2.fc28.x86_64 $ cat ~/.ssh/config Host * VerifyHostKeyDNS yes $ cat /etc/resolv.conf ; generated by /usr/sbin/dhclient-script search lan nameserver 192.168.1.2 $ ssh sky The authenticity of host 'sky.foo.org (2001:...)' can't be established. ECDSA key fingerprint is SHA256:xyeA7x2ocWL9AQyspMNVgMJQwwVwkoMFypbxWKpuLRw. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. # mcedit /etc/resolv.conf $ cat /etc/resolv.conf ; generated by /usr/sbin/dhclient-script search lan nameserver 192.168.1.2 options edns0 $ ssh sky Last login: Mon Sep 17 23:55:36 2018 from 2001:470:1f05:83e:227:eff:fe07:840 [root@sky ~]# logout Connection to sky.elentari.org closed. Not sure if this is a bug wrt. content of /etc/resolv.conf or ssh client.
(side note: I'm not sure if trusting the resolver in /etc/resolv.conf is even a good idea - what if it's relatively remote: I'd be far more comfortable with doing the full recursion from the roots ourselves...)
Trusting resolver with DNSSEC should be fine, but this means that you have to have local resolver verifying the signatures. Once you have any remote resolver, there is no reasonable way for the client application (ssh) to be sure where the answer came from and if it can be trusted. If I understand it right, this is exactly the behavior you see -- without the edns0 (DNS extensions), the SSH does not get any confirmation that the DNS response is secure and validated (so it will prompt you anyway). In the other case, the response was validated (even though remote resolver) so you are let in. The question is, why the dhclient does not allow the edns0 by default, but I am no expert on DNS so I can not comment on this.
Yeah the fact it doesn't set 'options edns0' is one thing... searching around it's not clear all dns resolvers in various CPEs actually correctly support it. Furthermore it's perfectly valid for the DHCP provided DNS resolver to be 8.8.8.8 and thus pretty distant, and thus inherently MITM-able. There's no crypto I'm aware of between the ssh client and the remote resolver. No DNS Curve or anything. I don't think you can actually 100% trust DNSSEC verification unless it's happening on the localhost. (possibly can trust something remote if your connection to it is ipsec or otherwise protected) It would be nice if this worked, but it does have to be rock solid... I take it SSH doesn't itself verify the trust chain up to the roots? (I have no idea how this is actually implemented... is all the crypto checking actually done at the resolver?)
> I don't think you can actually 100% trust DNSSEC verification unless it's happening on the localhost. Yes, you are right. > I take it SSH doesn't itself verify the trust chain up to the roots? No, SSH does only get a flags saying it was verified by the resolver: RRSET_VALIDATED from getrrsetbyname() [0]. > The RRSET_VALIDATED flag in rri_flags is set if the AD (authenticated data) bit in the DNS answer is set. This flag should not be trusted unless the transport between the nameserver and the resolver is secure (e.g. IPsec, trusted network, loopback communication). There was a patch adding a local DNSSEC validation in the OpenSSH code [1], but it was never accepted and it does not look like it is going to change. > (I have no idea how this is actually implemented... is all the crypto checking actually done at the resolver?) Yes. The applications don't don't do this usually, because it is awful lot of code even if you use some library to do the heavy-lifting (see the attached patch to the bug [1]). If you are interested in having this working reliably, using a local DNS resolver or resolver in trusted local network are probably the only ways to go now. [0] https://man.openbsd.org/freerrset.3 [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1672
The problem with that is that: (a) it requires quite a fair bit of extra setup (b) it prevents stuff like CPE (dhcp router) provided .lan/.local domains from working without additional setup. (c) possibly breaks captive portals for laptops and the like (d) gets rid of the benefits of caching It seems like this is something you don't want to do for all queries... just for those few like SSHFP checks where you really care about validation of the trust chain. Maybe SSHFP checking should be entirely outside of ssh client via some exec script? This might already be doable with some sort of Match exec script-that-always-returns-true-but-does-sshfp-checking-and-prepopulates-users-known-hosts-file stanza, as ugly as that would be, which could do something along the lines of 'wget https://dns.google.com/resolve?cd=false&type=sshfp&name=...' and parse the json, etc...
Been poking at this and something kind of like this can sort of be achieved via stunnel... Basically we forward a localhost tcp port to Google's dns-over-tls, and force edns to localhost forwarded port. Still not ideal though, since (a) you're trusting Google (b) you're trusting 8.8.8.8:853 cert wasn't spoofed by a CA belonging to someone besides Google (c) it's not all that pretty (d) it replaces *all* of ssh's dns lookups not just the sshfp ones. # dnf install stunnel # useradd -r stunnel # cat /etc/passwd | egrep stunnel stunnel:x:985:983::/home/stunnel:/bin/bash # id stunnel uid=985(stunnel) gid=983(stunnel) groups=983(stunnel) # cat /etc/stunnel/stunnel.conf setuid = stunnel setgid = stunnel pid = /var/tmp/stunnel.pid [dns-goog] client = yes accept = 127.8.8.8:53 connect = 8.8.8.8:853 verifyChain = yes CAfile = /etc/ssl/certs/ca-bundle.crt checkHost = dns.google sslVersionMin = TLSv1.3 --- # killall stunnel; stunnel # cat /etc/resolv-dns-goog.conf nameserver 127.8.8.8 options edns0 use-vc # chcon unconfined_u:object_r:net_conf_t:s0 /etc/resolv-dns-goog.conf # ssh foo.bar.org The authenticity of host 'foo.bar.org (2001:...)' can't be established. ECDSA key fingerprint is SHA256:QL7...Q. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. # unshare -m -- bash -c 'mount --bind /etc/resolv-dns-goog.conf /etc/resolv.conf; exec ssh foo.bar.org' [root@eonwe ~]# logout Connection to foo.bar.org closed. // Note: the unshare will need -U -r and probably other junk to make it work for non-root caller // resolv.conf options can be overridden with environment variable RES_OPTIONS, but not the dns servers themselves
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I'm not sure what should be done here... theoretically https://dnsflagday.net/ is behind us, which theoretically means it might perhaps maybe be safe to enable edns...
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.