Jakuje
commented
2 years ago I am wondering if the pam_ssh_agent_auth is designed to be used with the su as you describe. Most of the guides here talk about configuring this in the sudo, where this behavior is expected. The pam_ssh_agent_auth reads PAM_RUSER and if it is not defined, it falls back to the getuid() syscall, which is usually the right thing to do to authenticate a user with sudo, but not with a su.
msantos
Tested on several versions from 8.8p1 right back to 7.4p1 and on different distros (RHEL, Ubuntu)
Issue: If you use su - to elevate privileges when using the auth suffucient pam_ssh_agent_auth .so authorized_keys_command=/usr/bin/sss_ssh_authorizedkeys parameters within /etc/pam.d/su-l it passes the logged on username instead of the user to be elevated to. The result of this is the wrong public key is returned by sss_ssh_authorizedkeys.
Debugging: It seems to be specific to authorized_keys_command within pam_ssh_agent as I've tried writing a simple bash script which outputs %u and that is returning the wrong user. If you use file=/%h/%u/.ssh/authorized_keys that does return the correct user which makes e think its specific to the command.
Scenario: User alice with standard privileges logs on from Windows using pageant/PuttyCAC and has a smart card inserted. To do any superuser commands, she has to elevate herself with su - adminalice.
SSH connects fine
Alice does su - adminalice
Authentication starts processing but rejects the authentication by smartcard (returns wrong smartcard inserted within Windows) and reverts to password (the next line down in the pam.d file)
When using "debug" in the pam.d/su-l file you can see the following output in /var/log/secure or /var/log/auth.log: pam_ssh_agent_auth: debug1: Running AuthorizedKeysCommand: "/usr/bin/sss_ssh_authorizedkeys" as "alice" with argument: "alice"
This should read pam_ssh_agent_auth: debug1: Running AuthorizedKeysCommand: "/usr/bin/sss_ssh_authorizedkeys" as "alice" with argument: "adminalice"