user names in Match blocks in sshd_config (when using sssd with AD back-end)...

[Spike White]

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(puppetentrp)

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

Spike

[Sumit Bose]

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(puppetentrp)
>
> [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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...

[Jay McCanta]

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  
Sent: Thursday, November 5, 2020 1:03 AM
To: End-user discussions about the System Security Services Daemon 
Subject: [SSSD-users] Re: user names in Match blocks in sshd_config (when using sssd with AD back-end)...

EXTERNAL MAIL: [e-mail]

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 -- [e-mail] To 
> unsubscribe send an email to [e-mail]
> 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&amp
> ;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 -- [e-mail] To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor...
List Guidelines: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj...
List Archives: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...

[Spike White]

All,

In this particular case, it's an automation script that logs in (via SSH)
and performs activities as those two service accounts.  So we were able to
convert the automation to using lower case and then use lower case in our
sshd 'Match User' block.  So all is happy now.

But in the general case, is there a way to have sssd disallow users logging
in with upper case or mixed case?  I'd much prefer forcing the users to log
in with lower case, than not matching my sshd 'Match User' blocks.

I realize that sssd is mapping whatever entry the user types into lower
case.  But that's apparently too late (for sshd).

BTW, I realize this is not a sssd problem.  It's a sshd problem (when
relying on a case-insensitive back-end user auth, such as AD).

Spike

On Thu, Nov 5, 2020 at 3:03 AM Sumit Bose  wrote:
> 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(puppetentrp)
> >
> > [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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...

[Sumit Bose]

On Mon, Nov 09, 2020 at 12:06:05PM -0600, Spike White wrote:
> All,
>
> In this particular case, it's an automation script that logs in (via SSH)
> and performs activities as those two service accounts.  So we were able to
> convert the automation to using lower case and then use lower case in our
> sshd 'Match User' block.  So all is happy now.
>
> But in the general case, is there a way to have sssd disallow users logging
> in with upper case or mixed case?  I'd much prefer forcing the users to log
> in with lower case, than not matching my sshd 'Match User' blocks.

Hi,

currently there is only 'case_sensitive = True' but this does not force
lower-case names but names which match the spelling from the
server-side. So if the name is stored with all-caps on the server it
must be all-caps at login as well. If the names on the server are all
lower-case it would do want you want.

bye,
Sumit
> I realize that sssd is mapping whatever entry the user types into lower
> case.  But that's apparently too late (for sshd).
>
> BTW, I realize this is not a sssd problem.  It's a sshd problem (when
> relying on a case-insensitive back-end user auth, such as AD).
>
> Spike
>
> On Thu, Nov 5, 2020 at 3:03 AM Sumit Bose  wrote:
> > 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(puppetentrp)
> > >
> > > [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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct:
> >
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> >
> > https://lists.fedorahosted.org/archives/list/[e-mail].o...
> > _______________________________________________
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[e-mail].o...
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...

[Spike White]

Sumit,

Good info.

Unfortunately for us, that would not work.  A very high-level management
decision is to use camel-case in AD for names.  Windows doesn't care --
it's case-insensitive.  But as we see here, Linux and Kerberos client very
much cares.  Luckily, we're good -- for our one use case.

Spike

On Tue, Nov 10, 2020 at 12:23 AM Sumit Bose  wrote:
> On Mon, Nov 09, 2020 at 12:06:05PM -0600, Spike White wrote:
> > All,
> >
> > In this particular case, it's an automation script that logs in (via SSH)
> > and performs activities as those two service accounts.  So we were able
>
> to
> > convert the automation to using lower case and then use lower case in our
> > sshd 'Match User' block.  So all is happy now.
> >
> > But in the general case, is there a way to have sssd disallow users
>
> logging
> > in with upper case or mixed case?  I'd much prefer forcing the users to
>
> log
> > in with lower case, than not matching my sshd 'Match User' blocks.
>
> Hi,
>
> currently there is only 'case_sensitive = True' but this does not force
> lower-case names but names which match the spelling from the
> server-side. So if the name is stored with all-caps on the server it
> must be all-caps at login as well. If the names on the server are all
> lower-case it would do want you want.
>
> bye,
> Sumit
> > I realize that sssd is mapping whatever entry the user types into lower
> > case.  But that's apparently too late (for sshd).
> >
> > BTW, I realize this is not a sssd problem.  It's a sshd problem (when
> > relying on a case-insensitive back-end user auth, such as AD).
> >
> > Spike
> >
> > On Thu, Nov 5, 2020 at 3:03 AM Sumit Bose  wrote:
> > > 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(puppetentrp)
> > > > [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 -- [e-mail]
> > > > To unsubscribe send an email to
>
> [e-mail]
> > > > Fedora Code of Conduct:
> > >
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> > > sssd-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> > >
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...

[Grigory Trenin]

Hi Spike,

Though it's not directly related to SSSD, but your ssh config is a bit
weird. Especially these "MaxSessions 999" lines.
MaxSessions is not about simultaneous user sessions, it is about session
multiplexing. It is used only if you are going to open multiple SSH
sessions over a single TCP connection. This feature is not used often and
many people are unaware of its existence.
With this information in mind, maybe you don't need all these Match blocks
at all? :-)

Kind regards,
Grigory Trenin

ср, 4 нояб. 2020 г. в 21:03, Spike White :
> 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(puppetentrp)
>
> [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.
>
> Spike
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...