OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you disable LDNS in src.conf. If DNSSEC is enabled, the default setting for VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" (aka "train the user to type 'yes' and hit enter") and "no" (aka "train the user to type 'yes' and hit enter without even the benefit of a second opinion"). DES -- Dag-Erling Sm?rgrav - des at des.no
On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm?rgrav wrote:> OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you > disable LDNS in src.conf. If DNSSEC is enabled, the default setting for > VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust > DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" > (aka "train the user to type 'yes' and hit enter") and "no" (aka "train > the user to type 'yes' and hit enter without even the benefit of a > second opinion"). > > DESSo what happens when there is no dns server to consult? Will every ssh connection have to wait for a long dns query timeout? What if the machine is configured to use only /etc/hosts? What if a DNS server is configured but doesn't respond? For that matter, I just realized I'm a bit unclear on who is querying DNS for this info, the ssh client or the sshd? -- Ian
On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm?rgrav wrote:> OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you > disable LDNS in src.conf. If DNSSEC is enabled, the default setting for > VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust > DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" > (aka "train the user to type 'yes' and hit enter") and "no" (aka "train > the user to type 'yes' and hit enter without even the benefit of a > second opinion"). > > DESI just ran into a build error related to this: --- libssh.so.5 --- building shared library libssh.so.5 /local/build/staging/freebsd/wand/obj/arm.armv6/local/build/staging/freebsd/wand/src/tmp/usr/bin/ld: cannot find -lldns cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libssh.so.5] Error code 1 It only happens in one of my many build sandboxes, so I suspect it's related to the WITH/WITHOUT options in effect and perhaps also to the timing of parallel-build stuff. In the sandbox where it fails I have WITHOUT_KERBEROS and WITHOUT_PROFILE so I think that changes the timing of getting to the libssh build. I find that the attached patch fixes it for me. -- Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: libssh_build.diff Type: text/x-patch Size: 1213 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20130914/16b511ce/attachment.bin>
Ian Lepore <ian at FreeBSD.org> writes:> I just ran into a build error related to this: > [...] > I find that the attached patch fixes it for me. > [...] > @@ -1468,7 +1468,7 @@ lib/libcxxrt__L: gnu/lib/libgcc__L > lib/libradius lib/libsbuf lib/libtacplus \ > ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ > ${_cddl_lib_libzfs_core} \ > - lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ > + lib/libutil ${_lib_libypclnt} lib/libldns lib/libz lib/msun \ > ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ > ${_secure_lib_libssl} >That's not going to work, because libldns requires libcrypto. You should try the following: @@ -1470,8 +1470,8 @@ ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ ${_cddl_lib_libzfs_core} \ lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ - ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ - ${_secure_lib_libssl} + ${_secure_lib_libcrypto} ${_lib_libldns} \ + ${_secure_lib_libssh} ${_secure_lib_libssl} .if ${MK_ATF} != "no" _lib_atf_libatf_c= lib/atf/libatf-c Oh, wait, that's actually an excerpt from the commit that enabled LDNS in OpenSSH. What a coincidence! DES -- Dag-Erling Sm?rgrav - des at des.no