Package: openssh-client Version: 1:6.9p1-2+b1 Severity: wishlist File: /usr/bin/ssh
I am one of those people that think that StrictHostKeyChecking=yes should be on by default for its security benefit, but obviously it's a pain to connect to new nodes with this option turned on. Hopeful, I was looking at VerifyHostKeyDNS for relief, but I found none. No matter how I combine these options, I cannot reap any benefit from fingerprints stored in DNS. See the following examples. The first host does not have fingerprint information in DNS: % ssh -Snone -o StrictHostKeyChecking=yes -o VerifyHostKeyDNS=ask aika.krafftwerk.de uptime No RSA host key is known for aika.krafftwerk.de and you have requested strict checking. Host key verification failed. This is precisely what I'd expect. 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"? 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 -- .''`. martin f. krafft <madduck@d.o> @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
