openssh unix dev - Mar 2017 - 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).

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