known_hosts, IP, and port revisited

[Gregory Seidman]

I dug through the list archives to see if this had come up before, and I
see that a bug <http://bugzilla.mindrot.org/show_bug.cgi?id=393> was
submitted and subsequently closed (basically rejected) in 2002.

The basic issue, for those of you who don't feel like following the bug
URL, is that when one has ssh servers behind a NAT, each of which responds
to a different port on the NAT IP, they must all have the same host key to
avoid the ssh man-in-the-middle warning about a changed host key. In short,
because the known_hosts file is indexed only by name/IP and not port, there
is no way to distinguish between servers by port.

The discussion in 2002, which led to the bug being closed without a fix,
involved how different keys for the same name/IP would affect hostbased
authentication.

It's been over a year now, and the first issue (different servers behind a
NAT needing the same host key) keeps coming up. I have a proposal that I
believe wouldn't break hostbased authentication (which includes opening a
gaping security hole), but would allow different keys for servers on the
same IP but different ports.

The last comment on the bug, from Ben Lindstrom, is this:

	Your missing his point about 'hostbased' authentication. By
	allowing host/ip:port you run into a problem when you go to
	do hostbased authentication.  Instead of having a 1-to-1
	assocation you have a 1-to-many.  And randomly pick from
	the many is opening yourself up to potental spoofing. 

	if I have 10 keys all say 'etoh.eviladmin.org' but from 10
	different ports.  Do you really want to trust that the
	right random key will be used for hostbased auth?

	No, I agree with Markus.  Until one can show how
	host/ip:port format and hostbased auth can interact pinning
	it down to a 1-to-1 test then I doubt such a patch will be
	accepted.  When I stay 'show how'... I'm stating WITHOUT
	RFC modifications.  Full interop with existing installs.

My first problem with this is that I can't find any RFC on SSH at all. I
see http://www.ietf.org/html.charters/secsh-charter.html which doesn't seem
to deal with the details of hostbased authentication policy (mechanism,
yes, but not policy), but that's it.

My second problem with it is that it brings up a spurious security concern.
If I have 10 keys from (different ports on) 'etoh.eviladmin.org' it is
because I have made an ssh connection to each of those ssh servers and I
have some knowledge of them. I know which ones I trust. If we can
distinguish between different ports in known_hosts, we should also be able
to distinguish between different ports in .shost, and that allows me to
specify which hosts I trust. Of course an incoming SSH connection from
etoh.eviladmin.org isn't going to come from the port listed in
known_hosts/.shosts, but an entry in .shosts doesn't specify that that
hostname/IP is trusted but that the corresponding host key in known_hosts
is trusted.

I propose that both .shosts and known_hosts identify servers as name[:port]
where the default port is 22. When a connection comes in, hostbased
authentication tries the given host key against entries in known_hosts that
correspond to entries in .shosts (I'll give an example below). This means
that nothing changes with the protocol, and all existing .shosts and
known_hosts continue to work.

Here is an example known_hosts file:

etoh.eviladmin.org 1024 37 ...
etoh.eviladmin.org:23 1024 37 ...
etoh.eviladmin.org:80 1024 37 ...

And an example .shosts file:

etoh.eviladmin.org
etoh.eviladmin.org:23

When a connection comes in from etoh.eviladmin.org, we look at .shosts and
find that we trust two host keys. If the host key we are sent matches one
of the trusted host keys, we use it for authentication. Otherwise,
hostbased authentication fails.

Unless someone has a strong argument against it, I will reopen the bug with
this proposed solution.

--Greg