[PATCH] Allow matching HostName against Host entries

[Iain Morgan]

On Thu, Apr 11, 2013 at 21:50:54 -0500, Damien Miller wrote:
> On Wed, 10 Apr 2013, Markus Friedl wrote:
> 
> > I'm not sure if I like it....
> > I don't think it's that useful....
> 
> I can see why someone might want something like it for one particular reason:
> we don't do a fantastic job with unqualified hostnames right now. E.g. my
> resolv.conf might contain something like:
> 
> search mel.int.spectre.com int.spectre.com spectre.com
> 
> .. and I run "ssh www023". Without explicit configuration, I'd end up with
> an unqualified name in my known_hosts that isn't deduplicated with a
> partially, or fully qualified one that might also be in there or come later.
> 
> Furthermore, this makes hostkey certificates much less useful. When creating
> the certificates I have to chose whether to list only the FQDNs of a host
> as principals or whether I should also include unqualified names too. If
> I chose FQDNs that my certificates will not authenticate the host if I've
> connected using an unqualified name. If I chose to list un- and partially-
> qualified names then I open myself to host impersonation attacks (e.g.
> consider a certificate for a server named "www" or "proxy").
> 
> Much of the pain will go away if we have some option to allow
> ssh to canonicalise its hostnames. I thought we could do it using the
> AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
> users on DHCP networks to new attacks as a spoofed DHCP server can
> control the DNS search order.
> 
> A better option might be to allow specification of the suffix order in
> ssh_config itself. E.g.
> 
> HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com
> 
> to make ssh try resolution of unqualified names by appending each suffix
> in turn and stopping at the first successful lookup. The fully-qualified
> result would then replace the unqualified hostname for the purpose of
> ssh_config matching, known_hosts lookups and certificate name verification.
> 
> What do you think?
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The idea sounds interesting, and would address a variety of issues. I'm
a little concerned about "replacing" the unqualified name: Users could
be confronted by StrictHostkeyChecking messages despite the fact that
they have an entry for the unqualified name in their known_hosts files
and used the unqualified name. We would probably still need to match
against the unqualified name, but give preferrence to the FQDN.

It could also cause some consternation if users place the
HostnameSuffixes option at the beginning of their .ssh/config files;
matches against the unqualified name would then fail. This could be
avoided by using the option in a Host * section near the end of the
file, but I expect a lot of people would have to learn the hard way.

On a side note, this might have implications for bz#1169. Since we would
be resolving the hostname earlier, we would also get the IP address of
the target host and thus could apply options based upon that.

-- 
Iain Morgan