Open RandyParedis opened 1 day ago
adombeck
commented
1 day ago That's weird. I don't see anything out of the ordinary in the logs you provided. Is anything printed to the terminal when the SSH connection is disconnected? Please also check if the journal on the server shows any relevant messages (for example by running journalctl -f on the server before you try to connect via SSH with the Microsoft Entra user).
RandyParedis
commented
1 day ago Thank you for helping!
On the client side (from WSL), all I get is:
$> ssh USER@DOMAIN@SERVER_IP
MY VERY FUNNY BANNER TEXT HERE
== Broker selection ==
1 - local
2 - Microsoft Entra ID
Select broker: 2
Insert 'r' to cancel the request and go back
Enter your local password:
Connection closed by SERVER_IP port 22When I run journalctl -f, I get:
Dec 03 09:24:58 studento authd[7414]: 2024/12/03 09:24:58 WARN rpc error: code = NotFound desc =
Dec 03 09:24:58 studento authd[7414]: DEBUGgithub.com/ubuntu/authd/internal/log/log.go:53 github.com/ubuntu/authd/internal/log.init.logFuncAdapter.func1() User "USER@DOMAIN" is unknown
Dec 03 09:25:00 studento authd[7414]: DEBUGgithub.com/ubuntu/authd/internal/log/log.go:53 github.com/ubuntu/authd/internal/log.init.logFuncAdapter.func1() <REDACTED>: New session for "USER@DOMAIN"
Dec 03 09:25:01 studento CRON[11235]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Dec 03 09:25:01 studento CRON[11249]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Dec 03 09:25:01 studento CRON[11235]: pam_unix(cron:session): session closed for user root
Dec 03 09:25:06 studento authd[7414]: DEBUGgithub.com/ubuntu/authd/internal/log/log.go:53 github.com/ubuntu/authd/internal/log.init.logFuncAdapter.func1() <REDACTED>: Authentication result: granted
Dec 03 09:25:06 studento authd[7414]: DEBUGgithub.com/ubuntu/authd/internal/log/log.go:53 github.com/ubuntu/authd/internal/log.init.logFuncAdapter.func1() Updating entry of user "USER@DOMAIN" (UID: 1436533660)
Dec 03 09:25:06 studento authd[7414]: DEBUGgithub.com/ubuntu/authd/internal/log/log.go:53 github.com/ubuntu/authd/internal/log.init.logFuncAdapter.func1() <REDACTED>: End session "Microsoft Entra ID"
Dec 03 09:25:06 studento authd[7414]: 2024/12/03 09:25:06 WARN rpc error: code = NotFound desc =
Dec 03 09:25:06 studento unix_chkpwd[11251]: could not obtain user info (USER@DOMAIN)
Dec 03 09:25:06 studento kernel: audit: type=1400 audit(1733217906.084:207): apparmor="DENIED" operation="connect" class="file" profile="unix-chkpwd" name="/run/authd.sock" pid=11251 comm="unix_chkpwd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
Dec 03 09:25:06 studento sshd[11217]: error: PAM: User account has expired for USER@DOMAIN from CLIENT_IP
Dec 03 09:25:06 studento sshd[11217]: fatal: monitor_read: unpermitted request 104The same happens after clearing the cache with: sudo rm -rf /var/cache/authd/ && sudo rm -r /var/snap/authd-msentraid/current/cache && sudo snap restart authd-msentraid && sudo systemctl restart authd
Is this an issue in the PAM perhaps?
After talking to the team, it turns out someone tried to setup LDAP first through SSSD, but the service is disabled and turned off through pam-auth-update, so I don't think this should impact anything.
adombeck
commented
1 day ago Yes, looks like PAM is incorrectly configured. Please paste the output of:
for f in /etc/pam.d/gdm-authd /etc/pam.d/common-auth /etc/pam.d/common-account /etc/pam.d/common-password; do
echo "#### $f\n\`\`\`"
cat "$f"
echo \`\`\`
done
3v1n0
commented
1 day ago Other log that can help to see what's happening in PAM is /var/log/auth.log.
Also installing pamtester you could get more info on what's the final error by using pamtester sshd foo@domain.com authenticate, you can't see what each module returned without their own logging though (or without enabling pam debug at compile time).
RandyParedis
commented
23 hours ago My PAM config is as follows:
#%PAM-1.0
auth [success=ok user_unknown=ignore default=bad] pam_succeed_if.so user != root quiet_success
auth [success=1 ignore=ignore default=die] pam_authd.so
# If authd ignored the request => local broker is selected,
# then we continue with normal stack
auth substack common-auth
auth requisite pam_nologin.so
auth optional pam_gnome_keyring.so
account [default=ignore success=ok user_unknown=ignore] pam_authd.so
# This is potentially loading pam_authd.again but we've checks in AcctMgmt() to
# prevent this to happen when the gdm-authd service is used without GDM extensions.
# Plus the model used by the services is different, so there's no risk for this to happen.
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without this it is possible
# that a module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
# pam_selinux.so changes the SELinux context of the used TTY and configures
# SELinux in order to transition to the user context with the next execve()
# call.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_limits.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-session
session optional pam_mkhomedir.so
session optional pam_gnome_keyring.so auto_start
@include common-password#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth [success=2 ignore=ignore default=die] pam_authd_exec.so /usr/libexec/authd-pam
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
#
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account [default=ignore success=ok user_unknown=ignore] pam_authd_exec.so /usr/libexec/authd-pam
# end of pam-auth-update config#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.
# Explanation of pam_unix options:
# The "yescrypt" option enables
#hashed passwords using the yescrypt algorithm, introduced in Debian
#11. Without this option, the default is Unix crypt. Prior releases
#used the option "sha512"; if a shadow password hash will be shared
#between Debian 11 and older releases replace "yescrypt" with "sha512"
#for compatibility . The "obscure" option replaces the old
#`OBSCURE_CHECKS_ENAB' option in login.defs. See the pam_unix manpage
#for other options.
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
password [success=3 ignore=ignore default=die] pam_authd_exec.so /usr/libexec/authd-pam
password requisite pam_pwquality.so retry=3
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update configIn my /var/log/auth.log, I have:
2024-12-03T12:35:01.667149+00:00 studento CRON[12025]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
2024-12-03T12:35:01.672458+00:00 studento CRON[12025]: pam_unix(cron:session): session closed for user root
2024-12-03T12:36:39.262712+00:00 studento unix_chkpwd[12068]: could not obtain user info (USER@DOMAIN)
2024-12-03T12:36:39.263289+00:00 studento sshd[12050]: error: PAM: User account has expired for USER@DOMAIN from CLIENT_IP
2024-12-03T12:36:39.299408+00:00 studento sshd[12050]: fatal: monitor_read: unpermitted request 104The pamtester command just resulted in Authentication failure. Surprisingly, this time I got a QR code in the terminal, which does not show through ssh..
3v1n0
commented
22 hours ago Surprisingly, this time I got a QR code in the terminal, which does not show through ssh..
Yeah, that's expected: Sadly we can't reliably support qr codes through SSH as most of clients don't support it (see #497 and #500), so depending on the UI we may show it or not for now.
We've plans for using an #-rendered version in SSH in future, but that has not yet been defined.
RandyParedis
commented
22 hours ago Surprisingly, this time I got a QR code in the terminal, which does not show through ssh..
Yeah, that's expected: Sadly we can't reliably support qr codes through SSH as most of clients don't support it (see #497 and #500), so depending on the UI we may show it or not for now.
We've plans for using an
#-rendered version in SSH in future, but that has not yet been defined.
Ah, I see. Thanks! I just found it curious that I suddenly saw it. Not sure what differs between SSH and pamtester; but I assume it has to do with UTF-8 or something... Either way, that is a different topic.
3v1n0
commented
22 hours ago Dec 03 09:25:06 studento unix_chkpwd[11251]: could not obtain user info (USER@DOMAIN)
Dec 03 09:25:06 studento kernel: audit: type=1400 audit(1733217906.084:207): apparmor="DENIED" operation="connect" class="file" profile="unix-chkpwd" name="/run/authd.sock" pid=11251 comm="unix_chkpwd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0So this is due to apparmor blocking access to authd socket when doing getpwnames from NSS module, this is likely an issue to consider for other cases, but still it's not the bug here. Since the fact it fails it can't lead to the authentication to fail.
Now, looking at your pam configurations, /etc/pam.d/common-account seems to have authd in the wrong place, what if it would be:
#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
#
# here are the per-package modules (the "Primary" block)
account [success=2 ignore=ignore default=die] pam_authd_exec.so /usr/libexec/authd-pam
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# end of pam-auth-update configAs per the pamtester before, I've updated the comment to make clear that you should use an actual user name there and not mine :smile:. So test that again with pamtester sshd user@domain.bar acct_mgmt (after ensuring that using authenticate works too).
3v1n0
commented
21 hours ago If that works, go back to the default (by restoring the file or purging authd and installing it again), then modify /usr/share/pam-configs/authd so that (ignore the paths, only the changed lines):
diff --git a/debian/pam-configs/authd.in b/debian/pam-configs/authd.in
index 15528e92..808bbbda 100644
--- a/debian/pam-configs/authd.in
+++ b/debian/pam-configs/authd.in
@@ -5,7 +5,7 @@ Priority: 1050
Auth-Type: Primary
Auth:
[success=end ignore=ignore default=die] pam_authd_exec.so @AUTHD_DAEMONS_PATH@/authd-pam
-Account-Type: Additional
+Account-Type: Primary
Account:
[default=ignore success=ok user_unknown=ignore] pam_authd_exec.so @AUTHD_DAEMONS_PATH@/authd-pam
Password-Type: Primary
And run pam-auth-update --disable authd and enable it again pam-auth-update --enable authd (or just run pam-auth-update to rely on its UI to toggle it).
RandyParedis
commented
21 hours ago As per the pamtester before, I've updated the comment to make clear that you should use an actual user name there and not mine 😄. So test that again with pamtester sshd user@domain.bar acct_mgmt (after ensuring that using authenticate works too).
I figured :) ; but I forgot about the domain in my earlier tests... When I run the right command, I get:
#> pamtester sshd USER@DOMAIN authenticate
Enter your local password
pamtester: successfully authenticated
#> pamtester sshd USER@DOMAIN acct_mgmt
pamtester: Authentication failureThis happens both for the original file, and when I change the line in the file you shared. Changing the Account-Type in pam-configs/authd is no different.
I have reverted all these changes just to be sure.
3v1n0
commented
19 hours ago This happens both for the original file, and when I change the line in the file you shared. Changing the Account-Type in pam-configs/authd is no different.
Do you get the same with actual ssh authentication too?
As pam tester may still fail because of other reasons.
RandyParedis
commented
1 hour ago I get the following error when using SSH (after changing /etc/pam.d/common-account):
Can't set default broker ("2102147668") for "USER@DOMAIN": can't set default broker "2102147668" for user "USER@DOMAIN": no result matching USER@DOMAIN in UserByName
Is there an existing issue for this?
Describe the issue
I am running an Ubuntu 24.04.1 server for which I would like to allow SSO. I have followed the installation and configuration instructions in the Wiki, but I cannot log into the server. Whenever I have entered my local password, I get kicked out of the SSH connection. What am I missing?
Steps to reproduce
First SSH login:
Sequential SSH login:
System information and logs
authd version
authd-msentraid broker version
gnome-shell version
Distribution
Logs
authd broker configuration
/etc/authd/brokers.d/msentraid.conf
authd-msentraid configuration
Double check your logs