[Bug 910] known_hosts port numbers

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=910





------- Additional Comments From devin.nate at bridgecomm.net  2004-09-20 07:45 -------
Interesting.. I read through bug 393. Thanks for the pointer, Ben.

I'm not sure if the question is up for consideration or not. There appear to be
2 different requirements, and having read through bug 393 it didn't seem like
either side was really understanding the requirements.

In particular, I didn't realize the impact this patch would have on
HostBasedAuthenciation. Definitely, the 1:many problem you mentioned is a
problem - which of several host keys to use. That is a very significant problem-
it would totally break Hostbaseauth.

The problem I have is several hundred ssh servers, located behind (fewer) dhcp
changing IP addresses that many of our Customers have. For each ip address
(approx 100), there are 3 or so ssh servers (running on different ports
forwarded from the single IP). On a daily basis, someone (or lots) are moving IP
addresses. I need to ensure our staff can connect safely and securely and ensure
our Customers are equally protected. To that end, our staff can accept new host
keys but cannot connect if an already known hostkey doesn't match what it should
(i.e. ssh StrictHostKeyCheck ask). We explicitely disable HostBasedAuth (and all
related auth tyes) on all of these installs. As per bug 393, maintaining a
ssh_config file with the necessary mappings is not a viable option,
commercially- we just have too many hosts changing too often. Our Customer base
is growing, so the problem is getting bigger.

The interesting thing is that these are quite different requirements. One is
hostbasedauth and one is MITM-mitigation.

I would still like to see this feature, but as you noted there needs to be a
method that ensures 1:1 for hostbasedauth to work properly. This is what I see:

1) For sites with multiple machines behind 1 IP address; only 1 of those
machines could connect to another ssh server using hostbasedauth, given openssh
3.9p1 unchanged. Assuming one of these hosts connects to a ssh server:

2) The server that is connected to is able to lookup the host pub key because it
knows the ip address of the connecting host (in this case, the NAT ip). Since
there's 1:1 match between ip/hostname and the key files, the ssh server knows
which key to select.

Therefore, the conclusion that I think I can draw is that hostbasedauth works
for all hosts that have the same ip address and host keys. Stated another way,
hostbasedauth does not work for hosts that share a common ip address but
different host keys.

If that is true, then assuming a patch similar to mine were accepted, causing
multiple keys with the same ip address to be in the known_hosts files, the
question is how to identify which of the potential lines hould be used to get
the host key from.

The answer to that could be to have a flag to tell the functions in auth.c (and
in particular check_key_in_hostfiles()) to know about the special flag so that
only one host line matches. Perhaps the easiest to impliment would be a special
indicator similar to a port number.

Potential example:
    ip.ip.ip.ip:hostbasedauth

In this way, a line in a known_hosts file with :hostbasedauth after the
hostname, ip, or alias, would be singled out for use by a ssh server for
hostbasedauth. This would maintain the 1:1. Also, since I'd venture to guess
folks using hostbasedauth are a little more fluent with Unix and ssh (since
they've at least had to know how to edit a rhosts or shosts file), they would
seem fairly well equiped to add a hostbasedauth flag.

The largest disadvantage that I see, which isn't so much a disadvantage for me,
is that the known_hosts entry with the :hostbasedauth is not shared for outgoing
connections - and therefore in situation where host A connects to host B using
hostbasedauth, and then from host B connects back to host A using whatever, host
B will have 2 entries for host A: 1 for the hostbasedauth and 1 for the standard
hostauth/MITM-mitigation.

Any comments, thoughts, chance of getting this bug un-wontfixed?

Thanks,
Devin Nate




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.