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
