OpenSSH Key Storage

Michael T. Babcock mbabcock at fibrespeed.net
Sat Feb 2 03:30:14 EST 2002


> Would you name your web servers after the IP addresses they were on?  Ever
> seen an https host named https://443.foobar.com?

That is not an equivalent comparison.  Would I use a different SSL certificate
on www.fibrespeed.net:443 and www.fibrespeed.net:444?  Yes.  Would I expect the
browser to know the difference?  Yes.

> Of course not.  How you got there is not where you are, when it comes to

Actually, the name you used to get there is all that matters if you're going to
allow connecting to secure sites by name at all.  We don't force people to use
ssh 1.2.2.3 , we allow them to say ssh myhost.mydomain.com -p 1234 and so they
should be allowed to expect ssh to know that they're on "myhost.mydomain.com on
port 1234".

> Look.  Just because a daemon exists on a host doesn't mean it's necessarily
> that host's daemon, especially if it's not on the standard port, even more
> especially if that port is less than 1024.  Port forwarding is a *really
> useful thing*.  To wit:

Excuse me, but my server runs SSH on several ports and some of them are actually
TCP redirects to internal servers.  That is why I care about this feature; how I
get to those servers is not consistent, but their keys should all be stored in
a way that if I repeat my actions, I'll get no key warnings.

ssh -p 22 site.domain.com
ssh -p 23 site.domain.com (redirects to site2.domain.com)
ssh -p 22 site2.domain.com

Just because 2 and 3 are the same and have the same key doesn't mean SSH shouldn't
know about the difference between 1 and 2.
 
I'm ignoring the rest of your rant for the above reasons ...
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/



More information about the openssh-unix-dev mailing list