case sensitive hostname matching

[Randall S. Becker]

> -----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.