[tlug] SSH Issues

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > If you set up bind9

BIND is normally not installed on Linux boxen configured as
workstations.  I would guess that the standard resolver in glibc is
based on BIND 8.  It's hard to be sure because both glibc's resolv.h
and my Mac's resolv.h have a SCCS keyword referring to to BIND 8.1.
However, the glibc file uses #define _RESOLV_H_ to prevent multiple
inclusion, while Apple uses _RESOLVE_9_H_, and optionally includes
resolv8_compat.h.

 > (e.g., with dig and possibly the +dnssec option at the end of the
 > command line) the "ad" bit is now set, indicating that the records
 > have been authenticated.

Not on Gentoo.  (By "set bit", you mean either the "flags" in the header
or the "flags" in the OPTIONS PSEUDO-SECTION, I assume.)  There's no
ad flag in either list of flags.  The +adflag option doesn't help either.

BTW, you apparently need to use "dig @ns1.cynic.net".  With +dnssec I
get a bunch of spew (ie, RRSIG records) from ns1, but I don't get that
stuff when I use a recursive query via our local server.

I assume the spew means that for some reason (probably linking against
the BIND 8 resolver) dig is unable to authenticate, and so just
returns all the resource records it received.

 > For whatever reason, the Debian folks or the Gnu libc folks or
 > whomever have not for the last several years seen fit to include the
 > RES_USE_DNSSEC bit in their /usr/include/resolv.h or add to their
 > resolver the ability to turn this bit on in the request. So, despite
 > distributing a version of ssh that supports this functionality, many
 > (most? all?) Linux users can't use it.

I don't know what happens if I install BIND 9 on my system.  I'll
check later, I guess.  But on Gentoo there doesn't even seem to be a
USE flag for resolver v9 for bind-tools (ie, the package that provides
dig).  Maybe configure handles that, I dunno....

 > One thing that would be very cool would be to have a stand-alone program
 > with a working resolver library (or one just calling dig, which uses its
 > own non-broken resolver code, even under Ubuntu)

Er, that doesn't seem to be true on Gentoo.  At least, I couldn't get
authentication to happen, even with an explicitly specified +adflag.

 > look up SSHFP records, ensure that they're validated, and generate
 > known_hosts entries for them. Unfortunately, I don't see how to do
 > this.

Borrow enough of the OpenSSH code to get the host's public key, say
"thank you", maybe-replace the key into the known_hosts file, and call
SSH for real, maybe?  That much of the protocol can't be all that hard
to get "good enough", can it?

 > Any other thoughts? Has anybody got enough influence with all of the
 > various groups responsible for the Gnu libc issue to get this fixed and
 > deployed in any reasonably short period of time.

Getting it fixed is hard enough, but forget about getting it
deployed.  A real fix would involve a full move to BIND 9 resolver in
glibc, and that is not going to get into Debian or Ubuntu stable very
quickly.  A halfway fix would be to provide the BIND 9 resolver as an
optional library.

 > It's particularly frustrating because if there were an issue like this
 > in NetBSD, I could have a fix commited to the NetBSD-current branch
 > immediately,

>From the "Throwing cold water on hot heads" Department:

If you're serious, you just cost me a lot of faith in NetBSD.

Geez, Curt, you of all people should know that that is presumably
exactly the braindamaged process that led to the current impasse:
people unwilling to wait for a full move to BIND 9 adding a few
features *they* thought were "critical bug fixes" (because they'd been
personally inconvenienced) to the resolver code, eventually resulting
in a full-blown fork.  But a move to BIND 9 is not the kind of thing
you can do in a quickie patch, especially not if you want to claim the
security stuff is going to work.