[PATCH] Allow matching HostName against Host entries

[Damien Miller]

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