In the old days, if you logged in as ROOT, it was assumed that your terminal could not do
lower case, and everything was forced to uppercase. I think it used a \ as an indicator
for real upper case. Been a long time.
-----Original Message-----
From: Sumit Bose <sbose(a)redhat.com>
Sent: Thursday, November 5, 2020 1:03 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: user names in Match blocks in sshd_config (when using sssd with
AD back-end)...
EXTERNAL MAIL: sssd-users-bounces(a)lists.fedorahosted.org
On Wed, Nov 04, 2020 at 12:03:16PM -0600, Spike White wrote:
sssd professionals,
Interesting problem; seems to be an interaction with sshd daemon when
using an AD back-end.
When using sssd (with an AD back-end), what should my “Match” blocks in
/etc/ssh/sshd_config file look like for over-riding user values?
Right now, my Match blocks look like:
MaxSessions 10
....
Match User SERVICEPPTPRDVRA
MaxSessions 999
ClientAliveInterval 360
ClientAliveCountMax 3
Match User SERVICEPPTPRDDCA
MaxSessions 999
ClientAliveInterval 360
ClientAliveCountMax 3
And in the system log files, it looks like:
Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug2: parse_server_config:
config reprocess config len 1479
Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for
'User SERVICEPPTPRDVRA' user SERVICEPPTPRDVRA host 10.175.99.51 addr
10.175.99.51 laddr 10.174.120.203 lport 22 Nov 4 10:40:22 peplpc1mom01
sshd[2400354]: debug1: user SERVICEPPTPRDVRA matched 'User
SERVICEPPTPRDVRA' at line 158 Nov 4 10:40:22 peplpc1mom01
sshd[2400354]: debug3: match found Nov 4 10:40:22 peplpc1mom01
sshd[2400354]: debug3: reprocess config:159 setting MaxSessions 999 Nov
4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess config:160
setting ClientAliveInterval 360 Nov 4 10:40:22 peplpc1mom01
sshd[2400354]: debug3: reprocess config:161 setting ClientAliveCountMax
3 Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for
'User SERVICEPPTPRDDCA' user SERVICEPPTPRDVRA host 10.175.99.51 addr
10.175.99.51 laddr 10.174.120.203 lport 22 Nov 4 10:40:22 peplpc1mom01
sshd[2400354]: debug3: match not found
Here's where it gets weird. Because this is an AD back-end, by default
sssd is setting
case_sensitive = false
That is, it matches any case of user names. Examples:
SERVICEPPTPRDVRA
servicepptprdvra
ServicePPTPrdVra
However, I notice that sssd maps all the user names to lowercase once
you’re fully logged in. (this is what's desired.)
Example:
[root@peplpc1mom01 ssh]# su -l SERVICEPPTPRDVRA
Last login: Wed Nov 4 10:03:31 CST 2020 on pts/12
[servicepptprdvra@peplpc1mom01 ~]$ id
uid=3001425(servicepptprdvra) gid=3001425(servicepptprdvra)
groups=3001425(servicepptprdvra),1010(amerunixusers),2284221(puppetentr
p)
[servicepptprdvra@peplpc1mom01 ~]$
It looks like SSHD is looking at the raw “user name” input without any
processing for its match blocks. So I’m guessing this is before any
PAM or NSS processing.
Originally, I naively assumed that my Match blocks should be lowercase,
as that's what I see on the command line. But now I think it has to be
whatever raw input the user entered.
Hi,
yes, from looking at the OpenSSH code I would say that OpenSSH matches the names
case-sensitive and uses the name given at the client without any kind of canonicalization
on the server side.
This is not unexpected since it corresponds to what is typical on Unix/Linux systems and
might even be defined in POSIX, e.g. you cannot log in as 'ROOT', only as
'root'.
If this is only about single user it might be the most easy to just use a local user from
/etc/passwd. If this is about multiple users you might need to disable the
'case_sensitive = false' convenience feature in sssd.conf, since I guess OpenSSH
maintainers won't be happy to change the OpenSSH behavior here. But this would also
mean that all your AD users must know the right upper-lower case spelling of the login
names.
bye,
Sumit
Spike
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.
fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%7C
01%7CJ.McCanta%40F5.com%7C33a4920e0d9840b3dfa908d88169a708%7Cdd3dfd2f6a
3b40d19be0bf8327d81c50%7C0%7C0%7C637401638073051334%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C1000&sdata=3mlTxbYt52nplIIYHc1szz70Nkser3UmmTtCKWyfq0k%3D&re
served=0 List Guidelines:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedor
aproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7CJ.McCa
nta%40F5.com%7C33a4920e0d9840b3dfa908d88169a708%7Cdd3dfd2f6a3b40d19be0b
f8327d81c50%7C0%7C0%7C637401638073051334%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
;sdata=61Vl0d4AaU2bTek8OIz4CufoWO9UY%2BuWCHIBo%2BGegf4%3D&reserved=
0 List Archives:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists
.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.o
rg&data=04%7C01%7CJ.McCanta%40F5.com%7C33a4920e0d9840b3dfa908d88169
a708%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637401638073051334%7C
Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
WwiLCJXVCI6Mn0%3D%7C1000&sdata=SGMLmx59wJ%2BMqEpoMi34gzd96AzylSpKuk
I58LLFbSg%3D&reserved=0
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
List Guidelines:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
List Archives:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...