openssh unix dev - Sep 2002 - [Bug 393] 'known_hosts' file should be indexed by IP:PORT, not just IP

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

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From markus at openbsd.org  2002-09-11 06:18 -------
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?




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

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





------- Additional Comments From carson at taltos.org  2002-09-11 06:57
-------
> 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.




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

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





------- Additional Comments From eric at addamark.com  2002-09-11 07:13 -------
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).



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

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





------- Additional Comments From markus at openbsd.org  2002-09-11 07:59 -------
but why does HostKeyAlias not help?



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

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





------- Additional Comments From markus at openbsd.org  2002-09-11 08:01 -------
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



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

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





------- Additional Comments From markus at openbsd.org  2002-09-11 08:04 -------
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?



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

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





------- Additional Comments From markus at openbsd.org  2002-09-11 08:09 -------
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.



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

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





------- Additional Comments From eric at addamark.com  2002-09-12 05:04 -------
I guess the basic issue is whether one views the problem from the perspective 
of the user or the programmer.

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





------- Additional Comments From mouring at eviladmin.org  2002-09-12 05:52
-------
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.



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