Bug 454 - SSH doesn't consider distinguish ports for host-key verification
Summary: SSH doesn't consider distinguish ports for host-key verification
Status: CLOSED DUPLICATE of bug 910
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: -current
Hardware: All All
: P2 enhancement
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
: 523 537 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-12-10 04:45 AEDT by James Knight
Modified: 2006-10-07 11:35 AEST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Knight 2002-12-10 04:45:19 AEDT
I have two SSH servers running on the same machine.
One is running on port 22 for standard logins; the other is running port 4005, and is not run by root.

They both must have different host keys, as the sshd on port 4005 cannot (and should not) be able to read the host keys for the standard sshd on port 22.

This all works fine, except that every time you connect, it complains that the host key is wrong. I see that there is a configuration option "hostkeyalias" that can be used to circumvent this problem, but that is rather inconvenient, as i now need to type something like 'ssh -o "hostalias=foo.bar.com:4005" foo.bar.com -p 4005'

What I think should happen:
Connecting on a non-standard port should include the port number in the hostname automatically for hostkey lookup purposes, as in 'foo.bar.com:4005'. It should probably also use the host:port name for host-specific configuration option lookup.
Comment 1 Markus Friedl 2002-12-10 20:14:24 AEDT
hm, i think about adding
	ManglePort=yes
to the options.  This option will create Hostkeyaliases on
the fly if the port is != 22, and use
	'foor.bar.com@portXXX'
as an alias.
Comment 2 James Knight 2002-12-12 09:49:38 AEDT
Sounds like a good solution, except that I'd use the host:port format instead of host@port, because host:port is more universally recognized/used, unless there is some reason that host:port cannot be used for some reason.

I'd prefer that the option default to on (since otherwise I need to instruct everyone connecting to set it on), but I can understand in the name of backward compatibility if you decide to default it to off.
Comment 3 Markus Friedl 2002-12-12 21:23:38 AEDT
: is used in IPv6 addresses

and i like to use a name that does not conflict with
hostnames (for hostbased and rhostsrsa authentication),
so a @ is suggested.
Comment 4 Björn Augustsson 2003-02-07 21:03:50 AEDT
This feature would be useful for another issue as well: 

I have a dlink nat/gateway/switch/dhcp thingy, and a static IP. Behind it are
about 3-5 machines. I can specify one IP on the inside that gets connections
made to port 22 from the outside.

But if I want to login to another machine from he outside, without going thru
the designated one, I'm stuck, since the obvious solution (telling the sshd on
the other internal boxen to listen for another port as well, and relaying that
port to them in the NAT thingy) fails because the host keys are wrong.
Comment 5 Damien Miller 2003-03-27 21:35:44 AEDT
*** Bug 523 has been marked as a duplicate of this bug. ***
Comment 6 Markus Friedl 2003-04-07 01:58:20 AEST
*** Bug 537 has been marked as a duplicate of this bug. ***
Comment 7 Robin Johnson 2004-06-11 15:34:54 AEST
will this ever be implemented, or is it waiting for somebody to send in code 
for it?

existing $HOME/.ssh/known_hosts file has the following format:
'host keytype keydata'
where host is a either an IP or a name that resolves to the IP of the machine 
in question.
/etc/ssh/ssh_known_hosts has the following format [according to ssh(1)]:
'host[,host]* keydata [comment]*'

since we need to support IPv6 addresses, we cannot use a ':' as the 
address/port seperator, and since a comma is used to seperate multiple items in 
the latter case, that is out as well. I'd like to suggest a '@'.

My vision of how it should work:
old style entries as above should continue to work as they do presently (all 
connections to a host with only an old entry should be subject to the check), 
but ssh should add entries in the new format only.
Comment 8 Damien Miller 2004-06-11 15:37:32 AEST
An implementation like Markus' description would have the most chance of being
accepted (see comment #1).
Comment 9 James Knight 2004-12-17 06:01:01 AEDT
See also bug 910 for a patch.
Comment 10 Damien Miller 2005-04-21 18:16:39 AEST
bug #910 is asking for the same thing, but it has the advantage of having a
patch attached

*** This bug has been marked as a duplicate of 910 ***
Comment 11 Darren Tucker 2006-10-07 11:35:35 AEST
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.