openvpn setup with username/password authentication does not work. By enabling a bit of debug in pam I can see in auth.log: Sep 20 09:40:02 vpn openvpn[2266]: pam_shells(login:auth): User has an invalid shell '/bin/false' By changing the shell of the user from '/bin/false' to '/bin/bash' make it working. After have discussed the issue with sam on irc, he asked to open a bug to drop the 'pam_shells' line from the /etc/pam.d/system-login file. NOTE: in rhel-like systems (RockyLinux-9) I didn't find a trace of pam_shells in /etc/pam.d
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pambase.git/commit/?id=ff997817fbbfcd7ff8277022791be60208eab6f0 commit ff997817fbbfcd7ff8277022791be60208eab6f0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-11-04 15:38:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-23 23:46:35 +0000 Make pam_shells optional Bug: https://bugs.gentoo.org/939892 Signed-off-by: Mike Gilbert <floppym@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> pambase.py | 1 + templates/system-login.tpl | 2 ++ tests/rendered/default/system-login | 1 - tests/rendered/minimal/system-login | 1 - tox.ini | 2 +- 5 files changed, 4 insertions(+), 3 deletions(-)
The option needs wiring up in the ebuild next.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7da1e379d6b9b162aee9326066408d052366fdfd commit 7da1e379d6b9b162aee9326066408d052366fdfd Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-23 23:49:27 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-23 23:52:32 +0000 sys-auth/pambase: add 20250223 Mike Gilbert (2): Make pam_shells optional tox: allowlist_externals = diff Thibaud CANALE (1): login.tpl: remove duplicated lastlog module call Bug: https://bugs.gentoo.org/939892 Closes: https://bugs.gentoo.org/950186 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/pambase/Manifest | 1 + sys-auth/pambase/pambase-20250223.ebuild | 118 +++++++++++++++++++++++++++++++ 2 files changed, 119 insertions(+)
(In reply to Sam James from comment #2) > The option needs wiring up in the ebuild next. .. so, I said this, and then I didn't end up adding --shells in the ebuild, which means it's always off now. Not sure if it's worth just quickly fixing it to always add --shells (note that it's been in ~arch for a month with no complaints), add a USE, or just leave it, or what. Another question is if the change needs a news item or not.
It appears pam_krb5 requires pam_shells if the Kerberos authentication succeeds, so I had to readd pam_shells to be able to login. Please add it back at least for USE=pam_krb5.
(In reply to Viorel Munteanu from comment #5) > It appears pam_krb5 requires pam_shells if the Kerberos authentication > succeeds, so I had to readd pam_shells to be able to login. Can you elaborate on that? Why/how is it needed?
Apr 3 09:50:35 gandalf login[7139]: pam_krb5(login:auth): pam_sm_authenticate: entry Apr 3 09:50:37 gandalf login[7139]: pam_krb5(login:auth): (user viorel) attempting authentication as viorel@CEAMAC.NIX Apr 3 09:50:37 gandalf login[7139]: pam_krb5(login:auth): user viorel authenticated as viorel@CEAMAC.NIX Apr 3 09:50:37 gandalf login[7139]: pam_krb5(login:auth): (user viorel) temporarily storing credentials in /tmp/krb5cc_pam_iLm2cD Apr 3 09:50:37 gandalf login[7139]: pam_krb5(login:auth): pam_sm_authenticate: exit (success) Apr 3 09:50:40 gandalf login[7139]: FAILED LOGIN (1) on '/dev/tty2' FOR 'viorel', Permission denied This is the log when login fails. It happens if I login at the console, or via ssh with password. I can login successfully as root, or as a user with no Kerberos credentials, or via ssh with key, or in gdm (where pam_shells is present). Since I didn't find this behavior documented anywhere I did some debugging to find out why it fails after pam_sm_authenticate returns success. We have this sequence: #auth required pam_shells.so auth required pam_nologin.so auth required pam_env.so auth [success=3 default=ignore] pam_krb5.so debug ignore_root try_first_pass And the logs contain: [../linux-pam-e634a3a9be9484ada6e93970dfaf0f055ca17332/libpam/pam_dispatch.c:_pam_dispatch_aux(197)] use_cached_chain=0 action=0 cached_retval=25 retval=25 [../linux-pam-e634a3a9be9484ada6e93970dfaf0f055ca17332/libpam/pam_dispatch.c:_pam_dispatch_aux(197)] use_cached_chain=0 action=0 cached_retval=25 retval=25 [../linux-pam-e634a3a9be9484ada6e93970dfaf0f055ca17332/libpam/pam_dispatch.c:_pam_dispatch_aux(197)] use_cached_chain=0 action=3 cached_retval=0 retval=0 The actions are: #define _PAM_ACTION_IS_JUMP(x) ((x) > 0) #define _PAM_ACTION_IGNORE 0 #define _PAM_ACTION_OK (-1) #define _PAM_ACTION_DONE (-2) #define _PAM_ACTION_BAD (-3) #define _PAM_ACTION_DIE (-4) #define _PAM_ACTION_RESET (-5) I'm not a pam expert, so I don't know what _PAM_ACTION_IS_JUMP is supposed to do or why pam_krb5 sets status to 3, but no module sets action to -1 (ok) before pam_krb5, so by default it fails. If I uncomment pam_shells, this module adds -1 to the log: [../linux-pam-e634a3a9be9484ada6e93970dfaf0f055ca17332/libpam/pam_dispatch.c:_pam_dispatch_aux(197)] use_cached_chain=0 action=-1 cached_retval=0 retval=0 And login succeeds. So my supposition is this: we need some module to return success prior to pam_krb5. It happened to be pam_shells. To check this I removed pam_shells again and added successok to pam_nologin: auth required pam_nologin.so successok With this change I can login without pam_shells. So in conclusion we need some module to return success and set the action to ok before executing pam_krb5, be it pam_shells or something else.
Forgot to mention, 25 is PAM_IGNORE, 0 is PAM_SUCCESS
Thanks, that debugging is very helpful. Could you attach your /etc/pam.d/system-login and /etc/pam.d/system-auth files for reference?
(In reply to Viorel Munteanu from comment #7) > So in conclusion we need some module to return success and set the action to > ok before executing pam_krb5, be it pam_shells or something else. We used to have pam_permit.so as the last module in the stack, which was probably responsible for making all the crazy skips work.
(In reply to Viorel Munteanu from comment #7) > I'm not a pam expert, so I don't know what _PAM_ACTION_IS_JUMP is supposed > to do or why pam_krb5 sets status to 3, but no module sets action to -1 (ok) > before pam_krb5, so by default it fails. That's coming from the "success=3" on the pam_krb5.so line in system-auth. Based on the docs, that means if pam_krb5 succeeds, we ignore its status and jump over the next 3 modules in the stack. While it makes sense to jump over modules like pam_unix, ignoring the status of pam_krb5 is likely a mistake here.
Created attachment 923555 [details] /etc/pam.d/system-login I added pam_shells.so commented at the beginning, the version installed by pambase does not have that line
Created attachment 923556 [details] /etc/pam.d/system-auth
Created attachment 923557 [details] emerge --info pambase
(In reply to Mike Gilbert from comment #10) > > We used to have pam_permit.so as the last module in the stack, which was > probably responsible for making all the crazy skips work. I tried pam_permit too, but I didn't keep it because its man page calls it "very dangerous"
Created attachment 923558 [details] /etc/pam.d/system-auth Uploaded the wrong file, fixing
(In reply to Mike Gilbert from comment #11) > > That's coming from the "success=3" on the pam_krb5.so line in system-auth. > Based on the docs, that means if pam_krb5 succeeds, we ignore its status and > jump over the next 3 modules in the stack. There are only 3 modules left after that, so it jumps over all of them and returns the last known status, which was IGNORE. Makes sense.
In this case replacing success=3 with success=done solves the issue. This also skips all remaining modules, but is equivalent to ok, not to ignore. Should I open a new bug about this? Turns out it had nothing to do with pam_shells, it was its own bug, only triggered by this change.
I suspect the pam_faillock module is what sets action=-1 and retval=0 on typical systems that do not have pam_shells or pam_krb5 enabled. As an experiment, please remove pam_shells again, and move this line above the pam_krb5 entry. > auth requisite pam_faillock.so preauth That might be a quick fix until we can rework the stack to be a bit more deliberate about returning a success code.
(In reply to Viorel Munteanu from comment #18) > Should I open a new bug about this? Turns out it had nothing to do with > pam_shells, it was its own bug, only triggered by this change. Yeah, this probably deserves a new bug.
(In reply to Mike Gilbert from comment #19) > I suspect the pam_faillock module is what sets action=-1 and retval=0 on > typical systems that do not have pam_shells or pam_krb5 enabled. > > As an experiment, please remove pam_shells again, and move this line above > the pam_krb5 entry. > > > auth requisite pam_faillock.so preauth > > That might be a quick fix until we can rework the stack to be a bit more > deliberate about returning a success code. I already tried that, it works. Also, without it pam_unix.so below fails.
