[Bug 80] Host key conflict with two servers on one IP

[bugzilla-daemon at mindrot.org]

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

dan at doxpara.com changed:

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



------- Additional Comments From dan at doxpara.com  2002-01-26 10:54 -------
HostKeyAlias isn't just *a* solution, it's the right solution.  SSH connects to 
hosts, not to ports -- the port is just some address that may or may not lead 
to a specific desired host, possibly the machine listening on that port, 
possibly somewhere else.

We identify by destination, not by route.

Theory aside, what we want is for a given firewall to be able to remap a port 
on the external interface to an SSHD on the backend, with the client 
authenticating (and independently encrypting) against this forwarded link.

Instead of:

alice$  ssh -p 2022 user at firewall

either conflicting with the firewall's actual ssh key *or* somehow associating 
the key with the firewall itself(or, in the localhost variant involving 
127.0.0.1, just not authenticating at all), HostKeyAlias lets us inform the 
client of its expected cryptographically validated destination:  Bob.

alice$  ssh -o HostKeyAlias="Bob" -p 2022 user at firewall

I do have a better syntax for this that might someday actually work, but there 
is no bug beyond that.  It's as incorrect to see Bob's key associated with the 
firewall as it would be to see it associated with, say, MAE-West.  Firewall's 
just the route -- Bob's who we're looking for.

That being said -- you're generally correct about services mapping to IP:PORT.  
SSH escapes this general purpose simplification, because its services don't 
always remain on the same IP:PORT.  SSL makes a similar judgement, 
authenticating DNS names but not IPs or Ports.  You are you, no matter your 
phone number.  It's much the same for cryptographically verified identity.




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