Description of problem:
OpenSSH 8.0p1-13 installed

with ChallengeResponseAuthentication set to yes in /etc/ssh/sshd_config

with sss configured for AD authentication

with pam_env entries in the pam setup

that the environment variables assigned via pam_env are not assigned the authorised user shell.

Version-Release number of selected component (if applicable):
OpenSSH_8.0p1, OpenSSL 1.1.1k FIPS 25 Mar 2021

How reproducible:
Always

Steps to Reproduce:

Customer goal: What can I do to ensure that the environment command is only run for users that authenticate via sss, regardless of which protocol is used?

1. With ChallengeResponseAuthentication in /etc/ssh/sshd_config set to yes
1.1. Test 1 - confirm sshd sssd authentication updates environment variables
I setup the auth section of password-auth to look like this:

auth required pam_faildelay.so delay=2000000

1. for users that authenticate via sssd
   auth required pam_env.so conffile=/etc/security/pam_env_sssd.conf debug
   auth sufficient pam_sss.so forward_pass domains=example.com
   auth required pam_deny.so debug
   Result from Test 1

the environment variables are set

as expected, only sssd-authentication works

1.2. Test 2 - make the sssd the first auth attempt
The auth section of password-auth was setup like this:

auth required pam_faildelay.so delay=2000000
auth [success=2 default=ignore] pam_succeed_if.so debug user notingroup examplegroup

1. for users that authenticate via sssd
   auth required pam_env.so conffile=/etc/security/pam_env_sssd.conf debug
   auth sufficient pam_sss.so forward_pass domains=example.com
2. for users that authenticate locally
   auth [success=1 default=ignore] pam_usertype.so issystem
   auth [success=ok ignore=ignore default=1] pam_localuser.so
   auth sufficient pam_unix.so nullok

auth required pam_deny.so debug
Result from Test 2

All ssh authentications (both sssd and local) get the env variables set - not what was expected

Only telnet sssd authentications get the env variables set - exactly as expected

1.3. Test 3 - try a fall-through setup with pam_unix tried first
The auth section of password-auth was setup like this:

auth required pam_faildelay.so delay=2000000

1. for users that authenticate locally
   auth sufficient pam_unix.so nullok
2. for users that authenticate via sssd
   auth required pam_env.so conffile=/etc/security/pam_env_sssd.conf debug
   auth sufficient pam_sss.so forward_pass domains=example.com
   auth required pam_deny.so debug
   Result from Test 3

No local auth (via ssh or telnet) have the environment variables set - as expected

The sssd ssh authentication does not set the environment variables - not what was expected

The sssd telnet authentication does set the environment variables - as expected

2. I made the requested changes to the /etc/ssh/sshd_config file

1. grep -E "^PasswordAuthentication|^KbdInteractiveAuthentication" /etc/ssh/sshd_config
   PasswordAuthentication yes
   KbdInteractiveAuthentication no

I had to add the setting KbdInteractiveAuthentication to the /etc/ssh/sshd_config file as it was not there.

2.2. After restarting sshd the setting for KbdInteractiveAuthentication was still yes:

1. sshd -T|grep authen
   hostbasedauthentication no
   pubkeyauthentication yes
   kerberosauthentication no
   gssapiauthentication yes
   passwordauthentication yes
   kbdinteractiveauthentication yes
   challengeresponseauthentication yes
   authenticationmethods any

So despite adding it to the conf file the running sshd daemon does not reflect the setting, which tells me that it cannot be directly set.

2.3. The man entry for sshd_config indicates that KbdInteractiveAuthentication defaults to ChallengeResponseAuthentication.
So I removed the KbdInteractiveAuthentication entry that I added and changed ChallengeResponseAuthentication to be no.

1. grep -E "^PasswordAuthentication|^KbdInteractiveAuthentication|^ChallengeResponseAuthentication" /etc/ssh/sshd_config
   PasswordAuthentication yes
   ChallengeResponseAuthentication no

2.4. After re-starting sshd the running daemon now reports these authentication settings:

1. sshd -T|grep authen
   hostbasedauthentication no
   pubkeyauthentication yes
   kerberosauthentication no
   gssapiauthentication yes
   passwordauthentication yes
   kbdinteractiveauthentication no
   challengeresponseauthentication no
   authenticationmethods any

So the KbdInteractiveAuthentication setting can only be adjusted by changing ChallengeResponseAuthentication in the conf file.

2.5. Logging in as user exampleuser using AD credentials results in the pam_env activity showing up in the /var/log/secure log file (as expected):

Aug 2 11:19:02 hostname sshd[7245]: Connection from <IP address> port 30302 on <IP address> port 22
Aug 2 11:19:07 hostname sshd[7245]: Failed publickey for exampleuser from <IP address> port 30302 ssh2: RSA SHA256:UC8pVsdsEtrR5YjFeXNof
Aug 2 11:19:11 hostname unix_chkpwd[7249]: password check failed for user (exampleuser)
Aug 2 11:19:11 hostname sshd[7245]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<IP address> user=exampleuser
Aug 2 11:19:11 hostname sshd[7245]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<IP address> user=exampleuser
Aug 2 11:19:11 hostname sshd[7245]: Accepted password for exampleuser from <IP address> port 30302 ssh2
Aug 2 11:19:11 hostname sshd[7245]: pam_env(sshd:setcred): pam_putenv("AUTH_USER=exampleuser")
Aug 2 11:19:11 hostname sshd[7245]: pam_env(sshd:setcred): pam_putenv("AUTH_ENV=sssd")
Aug 2 11:19:11 hostname systemd[7258]: pam_unix(systemd-user:session): session opened for user exampleuser by (uid=0)
Aug 2 11:19:11 hostname sshd[7245]: pam_unix(sshd:session): session opened for user exampleuser by (uid=0)
Aug 2 11:19:11 hostname sshd[7245]: User child is on pid 7267
Aug 2 11:19:11 hostname sshd[7267]: pam_env(sshd:setcred): pam_putenv("AUTH_USER=exampleuser")
Aug 2 11:19:11 hostname sshd[7267]: pam_env(sshd:setcred): pam_putenv("AUTH_ENV=sssd")
Aug 2 11:19:11 hostname sshd[7267]: Starting session: shell on pts/2 for exampleuser from <IP address> port 30302 id 0
So disabling the ChallengeResponseAuthentication setting allows the pam_env updates to proceed.

This is good, and bad.

Without the ChallengeResponseAuthentication setting our attempts to use Google Authenticator for 2FA are broken.

3. I have been able to get both the pam_env environment variables being set for appropriate users as well as enabling the google authenticator by configuring the sshd_config file with these settings:

1. main settings section
   PasswordAuthentication yes
   ChallengeResponseAuthentication yes

1. Match section
   Match Group era User *,!rr
   KbdInteractiveAuthentication no
   The members of the unix user group all need to have the environment variables defined IF they trigger the pam_sss.so module, and for that to happen the KbdInteractiveAuthentication setting (which appears to be the equivalent of the ChallengeResponseAuthentication entry in the main settings area).

With this in place, the appropriate users who need google authenticator 2FA get it, and those that need environment variables defined for the pam_sss module get them set as well.

I find the relationship between KbdInteractiveAuthentication and ChallengeResponseAuthentication very confusing.

Actual results:
there is a real problem within sshd when ChallengeResponseAuthentication / KbdInteractiveAuthentication is set to yes and the pam stack includes pam_env and pam_sss, resulting in the pam_env outcomes not being applied to the resulting user shell.

Expected results:
ChallengeResponseAuthentication / KbdInteractiveAuthentication option in sshd_config should not affect pam_env outcomes for AD users authenticated via pam_sss

Additional info: