I have had a brief discussion with Damien Miller (below) about storing host port values in the known_hosts file so as to track multiple ssh sessions (with independant keys) that run on a single host but accept connections on different ports. If it were possible to state that a given key for a remote host belonged to that host's ssh session on port 23 and that another key belonged to that same host but the session available on port 22, it would take away some of the grief in managing such connections. I am presently using host aliases in the options file to handle this as Damien suggested but explaining this to my clients is difficult when SSH (commercial) has this seemingly simple feature built in.> On Fri, Feb 01, 2002 at 10:17:07AM +1100, Damien Miller wrote: > > On Thu, 31 Jan 2002, Michael T. Babcock wrote: > > > > > Without having looked at the config parsing code, does openssh care about > > > how long the line is? Could the additional information be stored after the > > > key string on the same line? > > > > No, that is used for key comments. > > If I may take up more of your time with this, the first pre-space > section is for hostname(s). What if the port were specified here? > > host,ipaddress,port:22 1024 35 keyvalue1 > host,ipaddress,port:23 1024 35 keyvalue2 > > As long as the port 22 entry comes first, there are no conflicts that I > can see and portable OpenSSH is quite happy to connect and validate the > key in version 3.0.2p1. The additional information can, however, be > used by more recent versions to select the correct line.PS, I am not subscribed to this list. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/
> I have had a brief discussion with Damien Miller (below) about storing > host port values in the known_hosts file so as to track multiple ssh > sessions (with independant keys) that run on a single host but accept > connections on different ports. If it were possible to state that a > given key for a remote host belonged to that host's ssh session on port > 23 and that another key belonged to that same host but the session > available on port 22, it would take away some of the grief in managing > such connections. > > I am presently using host aliases in the options file to handle this as > Damien suggested but explaining this to my clients is difficult when SSH > (commercial) has this seemingly simple feature built in.Would you name your web servers after the IP addresses they were on? Ever seen an https host named https://443.foobar.com? Of course not. How you got there is not where you are, when it comes to computer networks. (Yes, this is another divergence from the human experience. When teleporters become a reality, this may very well change.) 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: Take two hosts, a client and a server, that cannot establish outgoing sessions with eachother but may each send traffic to some broker over tcp/22 (or any other port). The server SSH's into the broker and reates a remote port forward from remote's 2022 to 127.0.0.1:22. Then the client SSH's into the broker and creates a local port forward on 3022 to be forwarded to the broker's 127.0.0.1:2022. Now, the client may SSH into the server by connecting to 127.0.0.1:2022, and by using the HostKeyAlias, will verify the identity of the server. This looks something like this: server$ ssh user at broker -R2022:127.0.0.1:22 client$ ssh user at broker -L3022:127.0.0.1:2022 [new window] client$ ssh -o HostKeyAlias=server -p 2022 user at 127.0.0.1 The reason I'm documenting this entire process is simple: The key the client receives from 127.0.0.1:2022 is the one of the server. It's not "the broker on port 3022". It's not "localhost on port 2022". It's not even "the server, oh on port 22." It's _the_ _server_. That's its identity. Now, it is certainly possible for multiple SSH daemons to be actually be run on the same machine. If they have identical keys, that's fine -- perhaps a newer revision of sshd_config is being tested on an alternate port, perhaps a backup sshd is live in case the primary one crashes, or perhaps it's the same actual daemon listening on multiple ports to assist in firewall piercing(like when sshd is told to listen on port 443). We don't care how we got that correctly hostkeyed SSH daemon, we just care we got it. But, ah, if the keys are different, the question is WHY. We have to presume that a host that is not providing its correct keying material in fact cannot. Any user can run an sshd on port 2022 just as easily as he can type ssh user at host -R2022:127.0.0.1:22. What separates his SSH-1.99-OpenSSH_3.0.1p1 from the real one isn't the route taken by the client but the key offered by the daemon. If he's offering a different key, he's effectively a different host, perhaps with some of the same services available but presumptively not an identical amount of trust to the legitimate identity. A daemon that cannot offer its correct host key is for all intents and purposes a different host, and needs to be treated as such. Don't get me wrong -- it can be really, really useful to create a separate sshd with highly restricted permissions, able only to administer the restricted level it lives at and even with a buffer overflow go no farther. We can do this by executing something like: server# su -l webuser -c "/usr/sbin/sshd -p 2022 -f /etc/sshd_config -h /home/webuser/sshd_user/userkey1 -h /home/webuser/sshd_user/userkey2" That fits fine in a rc.local script, or could even be directly executed over ssh or command line as the user. But the client *needs to know* that this account is of a different identity -- it's not a root owned key that's being hosted, but some restricted other identity host key. So we rename it. client$ ssh user at server -o HostKeyAlias="webserver" -p 2022 It's a different host we're trusting. It's a different server we're trusting. If the processes are accidentally running on the same machine, who cares. You don't trust IPs and you don't trust ports. Try, and you find yourself accepting keys you should -- after all, it's the right host, who cares if the network itself is redirecting the port -- and being unable to update your network infrastructure at will. If the Windows SSH daemons behave as you describe, there's probably some damaging hacks against them via corrupted ssh:// URLs. This all being said -- I actively dislike HostKeyAlias syntax and find it unwieldy. Cryptographically correct it may be, but we can -- and should -- do better. Bug me privately if you want to see what I was up to with this; suffice it to say, it's an uglier problem than I expected(as I found out at Defcon when I was trying to explain it to a crowd. That was pretty embarassing.) --Dan
if i connect to folly.openssh.com then i want the host key verified against the entry for folly.openssh.com if i connect to folly.openssh.com via a forwarded connection on somehost.example.bla, port 2222 then i want the host key verified against the entry for folly.openssh.com and not against somehost.example.bla, port 2222 because in both cases i really connect to folly.openssh.com storing the same key with different 'names' does not make sense to me. with "HostKeyAlias folly.openssh.com" i say: while the tcp connect is to "somehost.example.bla, port 2222" make sure that i really connect to folly.openssh.com moreover, with the current implemenation known_hosts is also used for hostbased authentication. if the client's hostkey is looked up in known_hosts what does 'port' mean? if "somehost.example.bla, port 2222" is stored in known_hosts, then folly.openssh.com can hide as somehost.example.bla. it has been suggested that the server tells the client: lookup the hostkey under this 'name'. does this really help? doesn't this mean the server binds name to key? shouln't the client do this instead? -m
If you want to bind identity to a server, you have only 2 valid options: - Pass the server's identity in-band, and have the client use that when validating keys. This avoids a layering violation. - Have the client validate the key against the layer 3/4 info - i.e. the IP:PORT pair. Nothing else is sane. Servers on different ports are different servers, that may, or may not, have the same keys. Requiring config file gymnastics is bogus. Sadly, after reading the RFC, it looks like the server never sends its name during the key exchange, making the first (and better) option impossible. I hope I'm wrong and just mis-understood the documents. -- Carson
On Fri, Feb 01, 2002 at 07:04:36PM +0100, Markus Friedl wrote:> > No, you're blaming that supposed behaviour incorrectly; that > > would happen already if the user connected to that machine that > > way. In fact, if I connect to my server on a different port, it > > tells me the key has changed -- which it hasn't; its just a different > > session. > > well, show should ssh know?SSH should know that a connection is a remote host + ip pair, the same as TCP does, which SSH rides on. Host+IP is how all connections in TCP are described; we all know that. How the user connects to the remote machine is what is important; if I connect using an alias "Comp1" then I configure that and go. If I connect using specified ports, that should work equally well. You're confusing user behaviour and software behaviour I think.> > This is fixed manually with the config file, but the behaviour you > > describe could happen _now_, with or without my proposed change. > > well, but your proposed change encourages this behaviour, while > HostKeyAlias does not.No, my proposed change simply decreases the need for HostKeyAlias which you seem to like (and I don't think should be necessary in many cases). My proposal means that users (who have situations like the one I described) don't have to contend with OpenSSH claiming their host key has changed; this leads to people just always saying "yes" to the verification prompt and decreases secure usage. I cannot think of a good reason _not_ to support the storage of keys on a host+ip basis. It does not, in any case described, decrease security from what we have now and I believe it increases security. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/