This is confirmed to work on Debian 11 (current stable), Debian testing, Fedora 34/35, CentOS 8, RHEL 8/9, so it does not smell like an upstream issue.
Ubuntu 20.04 LTS does not yet have pam_sss_gss, so this does not apply there. ** Description changed: I am trying to set up pam_sss_gss to authenticate to sudo with Kerberos. I am fairly sure that this worked in the past, but stopped recently. Reproducer: - - Join a FreeIPA domain, with "ipa-client-install". I use "COCKPIT.LAN" here in our tests. + - Join a FreeIPA domain, with "ipa-client-install". I use "COCKPIT.LAN" here in our tests. - - Enable GSS for sudo in sssd, as per pam_sss_gss(8) manpage: + - Enable GSS for sudo in sssd, as per pam_sss_gss(8) manpage: - sed -i '/\[domain\/cockpit.lan\]/ a pam_gssapi_services = sudo, + sed -i '/\[domain\/cockpit.lan\]/ a pam_gssapi_services = sudo, sudo-i' /etc/sssd/sssd.conf - - Enable pam_sss_gss in sudo itself, as per the same manpage: + - Enable pam_sss_gss in sudo itself, as per the same manpage. Enable + debug output: - sed -i '1 a auth sufficient pam_sss_gss.so debug' /etc/pam.d/sudo + sed -i '1 a auth sufficient pam_sss_gss.so debug' /etc/pam.d/sudo - - log in as domain user (ad...@cockpit.lan), validate with "klist" that + - log in as domain user (ad...@cockpit.lan), validate with "klist" that you have a kerberos ticket - - Run "sudo whoami" + - Run "sudo whoami" Expected result: On Fedora, I get: $ sudo whoami pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 33400000 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: ad...@cockpit.lan pam_sss_gss: User domain: cockpit.lan - pam_sss_gss: User principal: + pam_sss_gss: User principal: pam_sss_gss: Target name: h...@x0.cockpit.lan pam_sss_gss: Using ccache: KCM: pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Switching euid from 33400000 to 0 pam_sss_gss: Authentication successful root Note that this requires enabling local admins in FreeIPA, with - - ipa-advise enable-admins-sudo | sh -ex + ipa-advise enable-admins-sudo | sh -ex on the IPA server. However, it is fine for this to fail with a "normal" error like "permission denied". Actual result (on Ubuntu 21.04): $ sudo whoami pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 33400000 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: ad...@cockpit.lan pam_sss_gss: User domain: cockpit.lan - pam_sss_gss: User principal: + pam_sss_gss: User principal: pam_sss_gss: Target name: h...@x0.cockpit.lan pam_sss_gss: Using ccache: KEYRING:persistent:33400000 pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Communication error [3, 32]: Error in service module; Broken pipe pam_sss_gss: Switching euid from 33400000 to 0 pam_sss_gss: System error [32]: Broken pipe - [sudo] password for admin: + [sudo] password for admin: sudo: a password is required There is nothing *at all* in `tail -f /var/log/sssd/*` during this. With adding "debug_level = 9" to sssd.conf one can get a lot of output, but no error message. The journal has the same error message, apart from a bunch of apparmor ALLOWED and audit messages: - sudo[3917]: pam_sss_gss(sudo:auth): Communication error [3, 32]: + sudo[3917]: pam_sss_gss(sudo:auth): Communication error [3, 32]: Error in service module; Broken pipe Nothing else. - - Note: Either the packaging or ipa-client-install are misconfigured. They cause the socket-activated services to all fail: + Note: Either the packaging or ipa-client-install are misconfigured. They + cause the socket-activated services to all fail: $ systemctl --failed - UNIT LOAD ACTIVE SUB DESCRIPTION - ● user@33400000.service loaded failed failed User Manager for UID 33400000 + UNIT LOAD ACTIVE SUB DESCRIPTION + ● user@33400000.service loaded failed failed User Manager for UID 33400000 ● sssd-nss.socket loaded failed failed SSSD NSS Service responder socket ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket ● sssd-ssh.socket loaded failed failed SSSD SSH Service responder socket ● sssd-sudo.socket loaded failed failed SSSD Sudo Service responder socket with messages like sssd_check_socket_activated_responders[3498]: (2022-01-19 13:14:13:227270): [sssd] [main] (0x0070): Misconfiguration found for the sudo responder. sssd_check_socket_activated_responders[3498]: The sudo responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf. sssd_check_socket_activated_responders[3498]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the sudo's socket by calling: sssd_check_socket_activated_responders[3498]: "systemctl disable sssd-sudo.socket" systemd[1]: sssd-sudo.socket: Control process exited, code=exited, status=17/n/a systemd[1]: sssd-sudo.socket: Failed with result 'exit-code'. But I believe this is unrelated -- this has been the case for a *long* time already, and it does *not* break e.g. GSS kerberos authentication to ssh. - DistroRelease: Ubuntu 21.04 Package: sssd 2.4.1-2ubuntu4 ** Description changed: I am trying to set up pam_sss_gss to authenticate to sudo with Kerberos. I am fairly sure that this worked in the past, but stopped recently. Reproducer: - Join a FreeIPA domain, with "ipa-client-install". I use "COCKPIT.LAN" here in our tests. - Enable GSS for sudo in sssd, as per pam_sss_gss(8) manpage: sed -i '/\[domain\/cockpit.lan\]/ a pam_gssapi_services = sudo, sudo-i' /etc/sssd/sssd.conf - Enable pam_sss_gss in sudo itself, as per the same manpage. Enable debug output: sed -i '1 a auth sufficient pam_sss_gss.so debug' /etc/pam.d/sudo + + - Restart sssd to pick up the config change: + + systemctl restart sssd - log in as domain user (ad...@cockpit.lan), validate with "klist" that you have a kerberos ticket - Run "sudo whoami" Expected result: On Fedora, I get: $ sudo whoami pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 33400000 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: ad...@cockpit.lan pam_sss_gss: User domain: cockpit.lan pam_sss_gss: User principal: pam_sss_gss: Target name: h...@x0.cockpit.lan pam_sss_gss: Using ccache: KCM: pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Switching euid from 33400000 to 0 pam_sss_gss: Authentication successful root Note that this requires enabling local admins in FreeIPA, with ipa-advise enable-admins-sudo | sh -ex on the IPA server. However, it is fine for this to fail with a "normal" error like "permission denied". Actual result (on Ubuntu 21.04): $ sudo whoami pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 33400000 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: ad...@cockpit.lan pam_sss_gss: User domain: cockpit.lan pam_sss_gss: User principal: pam_sss_gss: Target name: h...@x0.cockpit.lan pam_sss_gss: Using ccache: KEYRING:persistent:33400000 pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Communication error [3, 32]: Error in service module; Broken pipe pam_sss_gss: Switching euid from 33400000 to 0 pam_sss_gss: System error [32]: Broken pipe [sudo] password for admin: sudo: a password is required There is nothing *at all* in `tail -f /var/log/sssd/*` during this. With adding "debug_level = 9" to sssd.conf one can get a lot of output, but no error message. The journal has the same error message, apart from a bunch of apparmor ALLOWED and audit messages: sudo[3917]: pam_sss_gss(sudo:auth): Communication error [3, 32]: Error in service module; Broken pipe Nothing else. Note: Either the packaging or ipa-client-install are misconfigured. They cause the socket-activated services to all fail: $ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● user@33400000.service loaded failed failed User Manager for UID 33400000 ● sssd-nss.socket loaded failed failed SSSD NSS Service responder socket ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket ● sssd-ssh.socket loaded failed failed SSSD SSH Service responder socket ● sssd-sudo.socket loaded failed failed SSSD Sudo Service responder socket with messages like sssd_check_socket_activated_responders[3498]: (2022-01-19 13:14:13:227270): [sssd] [main] (0x0070): Misconfiguration found for the sudo responder. sssd_check_socket_activated_responders[3498]: The sudo responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf. sssd_check_socket_activated_responders[3498]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the sudo's socket by calling: sssd_check_socket_activated_responders[3498]: "systemctl disable sssd-sudo.socket" systemd[1]: sssd-sudo.socket: Control process exited, code=exited, status=17/n/a systemd[1]: sssd-sudo.socket: Failed with result 'exit-code'. But I believe this is unrelated -- this has been the case for a *long* time already, and it does *not* break e.g. GSS kerberos authentication to ssh. DistroRelease: Ubuntu 21.04 Package: sssd 2.4.1-2ubuntu4 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1958392 Title: pam_sss_gss crashes with Communication error [3, 32]: Error in service module; Broken pipe To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1958392/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs