Hi, as recently noticed by one of our customers, ssh tends to perform hostname matching in a case sensitive manner since the lowercasing has been delayed till after configuration parsing (by commits d56b44d2dfa093883a5c4e91be3f72d99946b170 and eb6d870a0ea8661299bb2ea8f013d3ace04e2024). Given that hostnames are ususally interpreted in a case insensitive way (and the code actually expects the input to be lowercased anyway) it might be good to perform the comparisons as such. We can either make sure match_hostname() receives a lowercased string indeed or perform the lowercasing there (carefully as not to introduce side effects). One question is, whether *any* hostname matching should be case insensitive or whether originalhost is better left alone (I can think of reasons for case sensitive matching there, yet they seem to be bordering on misuse of the code). I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685 (patch is attached there as well). Thanks Kind regards Petr -- Petr Cerny Mozilla/OpenSSH maintainer for SUSE Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-ssh_case_insensitive_host_matching.patch Type: text/x-patch Size: 1565 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170303/18824394/attachment.bin>
> -----Original Message----- > From: openssh-unix-dev [mailto:openssh-unix-dev- > bounces+rsbecker=nexbridge.com at mindrot.org] On Behalf Of Petr Cerny > Sent: March 3, 2017 8:07 AM > To: openssh-unix-dev at mindrot.org > Subject: case sensitive hostname matching > > Hi, > > as recently noticed by one of our customers, ssh tends to perform hostname > matching in a case sensitive manner since the lowercasing has been delayed > till after configuration parsing (by commits > d56b44d2dfa093883a5c4e91be3f72d99946b170 and > eb6d870a0ea8661299bb2ea8f013d3ace04e2024). > > Given that hostnames are ususally interpreted in a case insensitive way (and > the code actually expects the input to be lowercased anyway) it might be > good to perform the comparisons as such. We can either make sure > match_hostname() receives a lowercased string indeed or perform the > lowercasing there (carefully as not to introduce side effects). > > One question is, whether *any* hostname matching should be case > insensitive or whether originalhost is better left alone (I can think of reasons > for case sensitive matching there, yet they seem to be bordering on misuse > of the code). > > I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685 > (patch is attached there as well).While it might be theoretically a good idea, some security implementations have issues with multiple key pairs specified for a single delegate user (say 'git') on the same host. I'm not saying that this is the correct way to do it, but some ~/.ssh/config files differentiate the same user on the same host with different keys using Abc.domain vs. AbC.domain, allowing multiple key-pair identities. Moving to case-insensitive comparisons inside ~/.ssh/config would break this legacy behaviour for which there does not appear to be good work-arounds in some setups. Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much.
Randall S. Becker wrote:>> Given that hostnames are ususally interpreted in a case insensitive >> way (and the code actually expects the input to be lowercased >> anyway) it might be good to perform the comparisons as such. We can >> either make sure match_hostname() receives a lowercased string >> indeed or perform the lowercasing there (carefully as not to >> introduce side effects). >> >> One question is, whether *any* hostname matching should be case >> insensitive or whether originalhost is better left alone (I can >> think of reasons for case sensitive matching there, yet they seem >> to be bordering on misuse of the code). >> >> I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685 >> (patch is attached there as well). > > While it might be theoretically a good idea, some security > implementations have issues with multiple key pairs specified for a > single delegate user (say 'git') on the same host. I'm not saying > that this is the correct way to do it, but some ~/.ssh/config files > differentiate the same user on the same host with different keys > using Abc.domain vs. AbC.domain, allowing multiple key-pair > identities. Moving to case-insensitive comparisons inside > ~/.ssh/config would break this legacy behaviour for which there does > not appear to be good work-arounds in some setups.Interesting. I suppose this kind of setup uses the `Host` sections - if used as `Match originalhost` then the attached patch, which doesn't touch original host. Or, possibly better way - make this an option. Thanks Kind regards Petr