On Thu, 2015-11-12 at 16:48 +1300, martin f krafft wrote: > I am one of those people that think that StrictHostKeyChecking=yes > should be on by default for its security benefit agreed > Hopeful, I was looking at VerifyHostKeyDNS for relief The default StrictHostKeyChecking isn't secure enough for you, but you'd trust DNSSEC here? ;-P > But there is fingerprint data in > DNS for the next host, yet…: > > % ssh -Snone -o StrictHostKeyChecking=yes -o VerifyHostKeyDNS=ask > diamond.madduck.net uptime > No RSA host key is known for diamond.madduck.net and you have > requested strict checking. > Host key verification failed. > > Couldn't it just say "hey, you wanted strict checking, but since > there's DNS info, I'll ask you and make your life a bit easier"? I think the point here is the semantics of these two options, or rather the semantics of OpenSSH in general: AFAIU, it will generally only accept a remote key, when that's found in one of the known_hosts files (or added automatically just now). That's even the case for StrictHostKeyChecking=no - it just adds it them automatically without asking. And the same for VerifyHostKeyDNS, regardless of what you set there, it wants the key in known_hosts. No when you set StrictHostKeyChecking=yes and VerifyHostKeyDNS=ask|yes the DNSSEC part would ask you whether to add the key (or add it automatically in the yes case)... but since StrictHostKeyChecking=yes, there is *NO* automatic adding of host keys. And here that semantics kick in, that OpenSSH wants the host key in known_hosts. Well.. that's at least how I'd understand it, and the documentation seem to back this. Whether that behaviour makes sense or not is a different question: The good thing on it is, that you have that guaranteed central place where keys need to be in and that one option which controls whether keys are ever auto-added to that file[0]. I guess the idea is to have some kind of a TOFU model... and that's why each key (even when retrieved via DNSSEC) needs to go to known_hosts first. I hate TOFU[1], but well... it's not real TOFU, as you still have the "trust path" via DNSSEC, Anyway... something like this should, if at all, only changed upstream, so could you perhaps report/request it there? But I would probably vote against it (not that I'd have any saying)... and I'd guess upstream would either. Actually I've already lobbied upstream to even do away with[0], but that was rejected either. Cheers, Chris. [0] Interestingly though, that's not completely true, even if StrictHostKeyChecking=yes it will auto add entries to known_hosts with the IP of a host, if that host has already a known key, say in /etc/ssh/ssh_known_hosts, but under a domain name. [1] http://www.metzdowd.com/pipermail/cryptography/2015-April/025342.ht ml > > For completeness, setting the two options to ask/yes (vs. yes/ask in > the above) > yields the following: > > % ssh -Snone -o StrictHostKeyChecking=ask -o VerifyHostKeyDNS=yes > diamond.madduck.net uptime > The authenticity of host 'diamond.madduck.net (2001:470:b46d::1)' > can't be established. > RSA key fingerprint is > SHA256:DiHbQd5xUBR9o0yDW3M6ZtbrOX945TKYPXXj3baAass. > Matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no)? ^C > > % ssh -Snone -o StrictHostKeyChecking=ask -o VerifyHostKeyDNS=yes > aika.krafftwerk.de uptime > The authenticity of host 'aika.krafftwerk.de > (2001:1620:2018:2::4d6d:8b5b)' can't be established. > RSA key fingerprint is > SHA256:N4lWu2fGy62l7T8KLTKnG41udQwkdFn0G321tNe/w3k. > No matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no)? ^C > > With ask/ask, it's exactly the same. > > With no/ask and no/yes, the login just happens and the key gets added > for both > hosts. > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages openssh-client depends on: > ii adduser 3.113+nmu3 > ii dpkg 1.18.3 > ii libc6 2.19-22 > ii libedit2 3.1-20150325-1 > ii libgssapi-krb5-2 1.13.2+dfsg-4 > ii libselinux1 2.3-2+b1 > ii libssl1.0.2 1.0.2d-3 > ii passwd 1:4.2-3 > ii zlib1g 1:1.2.8.dfsg-2+b1 > > Versions of packages openssh-client recommends: > ii xauth 1:1.0.9-1 > > Versions of packages openssh-client suggests: > pn keychain <none> > pn libpam-ssh <none> > ii monkeysphere 0.37-3 > ii ssh-askpass-gnome [ssh-askpass] 1:6.9p1-2+b1 > > -- debconf-show failed > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature