The current logic for using the 'known_hosts' file is broken with respect to NAT. The current logic assumes that there is a 1:1 relationship between an IP Address and a physical host. This is not true. The correct logic would be to associate each IP:PORT pair with a physical host. The current logic breaks if the SSH server is behind a NAT device that does port mapping. For example, 156.32.67.132:22 does not necessarily go to the same physical host as 156.32.67.132:1022. The problem one sees as a result of this is that the 'StrictHostChecking' and 'CheckHostIP' settings in ssh_config will cause 'ssh' to fail when it shouldn't. We ran into this today when I mapped a second SSH server through our firewall on a new port.
i don't think this will happen any time soon. what does ip:port mean for hostbased authentication? why does HostKeyAlias not help? why should i have 10 entries for the hostkey if i run sshd on 10 different ports on the same machine?
> what does ip:port mean for hostbased authentication? It means nothing. The IP of the host is irrelevant - the name is all that matters. > why does HostKeyAlias not help? Because it requires touching the config files of every possible user. > why should i have 10 entries for the hostkey if i run sshd on 10 different > ports on the same machine? Because they may not have the same keys. Disk space is cheap. If you really want to save disk space, allow a single key to have multiple ip:port indices.
Let me be specific then: I have two ssh server mapped through different port numbers on the same public IP address to the outside world: one is on Port 22, the other is on port 1022. The configuration breaks the ssh client when UseStrictHostChecking is active because the logic assumes that it can never see more than one host key from a given IP address. The CheckHostIP setting gives spurious warnings because it assumes that it can never see more than one host key from a specific IP address. Currently, my only work around is to disable both settings on everyone's client. This is neither practical nor desirable as it not only requires that everyone make a change to their local config's, but in addition, everyone has to turn run without the extra security that these settings provide. I'm assuming that the first feedback was from one of the developers in the OpenSSH team. Please reconsider your stance on this issue (or at least reopen the bug so that it doesn't drop through the cracks).
but why does HostKeyAlias not help?
if you don't want to use HostKeyAlias, you can even use the GlobalKnownHostsFile option, e.g. Host a Hostname gate port 1234 GlobalKnownHostsFile /etc/ssh/known_hosts_a Host b Hostbname gate port 5678 GlobalKnownHostsFile /etc/ssh/known_hosts_b
it's not about saving diskspace, why should ssh ask you to confirm the hostkey for every new ip:port pair? and: the entry matters for hostbased authentication: you have 10 entries for the same ip, what key is the correct key?
HostKeyAlias does not require more work than an up-to-date known hosts file. If you use port-forwarding to the 'real' ssh server, then the entries in the known hosts file should identify the 'real' ssh server, not just a random port on a gateway host, e.g. if i want to connect to cvs.openssh.com via a gateway host, i use Host cvs2 Hostname gate Port 2222 HostKeyAlias cvs.openssh.com so 'ssh -v cvs2' will look up the correct hostkey under a a name that refers to the 'real' server, and not to some random gate:2222 name, that has nothing to do with the server we connect to.
I guess the basic issue is whether one views the problem from the perspective of the user or the programmer. From the point of view of the user, the tool should simply work without requiring the user to do anything special. i.e. when they run "ssh gate -p 22" it just works and when they run "ssh gate -p 1022" it just works. Having to tell everyone who will remotely access our system (i.e. employees, contractors, customers, etc) that they have to go setup special configurations with special options in order to access our network just isn't practical. The tool is suppose to work for the user, not the other way around. As for disk space, each line in these files is a little over 200 bytes. if your file system is so tight that you can't put a couple extra KB on your disk, you've got bigger problems. As for the statement that the entries in the known_hosts file are suppose to represent "real" ssh servers, that is also not true. As an IT Manager, I explicitly want to control how my network appears to the outside world. The only points of contact (and knowledge) that the outside world has about my network are defined through my firewalls. Everything that the outside world knows about my network must be related the defined entry points to my network, not the internals of my network. As for verifying every IP:Port pair, the simple answer is "YES". Again, since every IP:Port pair could map to a completely separate system you actually have to verify each IP:Port pair because making the assumption that all ports on a particular IP go to a single host is simply wrong. Tell you what, if I patch up the code and send it to you, will you roll it into the next release?
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.
Mass change of RESOLVED bugs to CLOSED