known_hosts, IP, and port revisited

[Ben Lindstrom]

Please discuss why:

     HostKeyAlias
             Specifies an alias that should be used instead of the real host
             name when looking up or saving the host key in the host key
             database files.  This option is useful for tunneling ssh connec-
             tions or for multiple servers running on a single host.

No one has yet explain why it does not work outside of.. "It is not what I
expect"

- Ben


On Thu, 18 Dec 2003, Gregory Seidman wrote:

> 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
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>