Hide Forgot
Description of problem: After upgrade to RHEL 7.6 sudo was nolonger able to authenticate the backuppc user to do local server backup. Version-Release number of selected component: sudo-1.8.23-3.el7.x86_64 How reproducible: Fails everytime Steps to Reproduce: Backuppc user initiates call to sudo to launch rsync process as seen in test error output here: sudo: backuppc : PAM account management error: Authentication service cannot retrieve authentication info ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rsync -d /home /tmp/ The expected outcome is achieved after downgrading to the previous sudo version, in this case: sudo-1.8.19p2-14.el7_5.x86_64, as seen in the non-error output here: sudo: backuppc : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rsync -d /home /tmp/ Additional info: Selinux is not enabled on this machine.
Thanks for the report. I think we'll need more information about how your system is configured. Could you please show how your PAM stack and sudoers configration look like? Maybe we'll need also some debug logs from PAM and sudo, but let's start with just the configs.
Daniel, per your 1/18/19 request, is the diff of my sudoers edits with the distro version. Following is the backuppc config to allow use of rsync on the host machine. Permissions for both are 440 and root.root. # diff of /etc/sudoers edits # Defaults requiretty # /etc/sudoers.d/01_backupppc backuppc ALL=NOPASSWD: /usr/bin/rsync The Pam config for sudo is as follows here: # /etc/pam.d/sudo #%PAM-1.0 auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so The working version of sudo currently is: # rpm -qi sudo Name : sudo Version : 1.8.19p2 Release : 14.el7_5 Architecture: x86_64 Install Date: Mon 24 Dec 2018 02:03:45 PM EST And Pam is: # rpm -qi pam Name : pam Version : 1.1.8 Release : 22.el7 Architecture: x86_64 Install Date: Mon 28 May 2018 11:18:58 AM EDT /var/log/secure for Dec 18 2019 , for sudo-1.8.23-3.el7.x86_64, prior to downgrade Dec 18 01:00:04 localhost sudo: backuppc : PAM account management error: Authentication service cannot retrieve authentication info ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --one-file-system --exclude= --ignore-times . /
(In reply to Kelly-Rand from comment #4) > Daniel, per your 1/18/19 request, is the diff of my sudoers edits with the > distro version. Following is the backuppc config to allow use of rsync on > the host machine. Permissions for both are 440 and root.root. > > # diff of /etc/sudoers edits > # Defaults requiretty > > # /etc/sudoers.d/01_backupppc > backuppc ALL=NOPASSWD: /usr/bin/rsync > > The Pam config for sudo is as follows here: > > # /etc/pam.d/sudo > > #%PAM-1.0 > auth include system-auth > account include system-auth Could you please show the state of the system-auth PAM file as well? I tried to reproduce the issue but haven't succeeded yet. So far this looks like a normal configuration and works for me when replicated. Is the 'backuppc' a local user?
Here is the state of the system-auth-ac Pam file: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so State in Pam.d lrwxrwxrwx. 1 root root 14 Feb 4 2018 system-auth -> system-auth-ac -rw-r--r--. 1 root root 1031 Feb 4 2018 system-auth-ac Yes, the backuppc user is local. If this is insufficient to determine the cause of the issue I could reinstall the latest sudo version and see if the problem is still present. I need to coordinate this with the backup schedule which would delay any results till Jan 25, 26.
Jan 26, 2019 I yum updated to sudo-1.8.23-3.el7 today and was able to duplicate my earlier error as described in the first post. I also found that the file /etc/pam.d/sudo has an added line at the end as seen here: #/etc/pam.d/sudo #%PAM-1.0 auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so session include system-auth << this line does not exist in the prior sudo Deleting the last line does not change the outcome of the failed call to sudo by backuppc. So there does appear to be a policy shift within sudo that relates to the session authentication? I have to revert back to the earlier version of sudo for now.
Created attachment 1539149 [details] testing srpm
I've attached an SRPM with an upstream patch which might fix the problem you are seeing. Could you build the SRPM and test it in your environment? I can provide binary builds if you can't build it yourself.
Daniel, Could you provide a rpm for install? I'm not practiced at compiling nor do I know if I have the necessary libraries installed. I can test it this weekend. Regards, Jim KR
Created attachment 1539376 [details] testing build
(In reply to Kelly-Rand from comment #10) > Daniel, > > Could you provide a rpm for install? I'm not practiced at compiling nor do I > know if I have the necessary libraries installed. I can test it this > weekend. Attached.
I've installed and tested this most recent build. The result is still "Authentication service cannot retrieve authentication info" bash-4.2$ rpm -qi rpm: no arguments given for query bash-4.2$ rpm -qi sudo Name : sudo Version : 1.8.23 Release : 3.1551336486.el7_6 Architecture: x86_64 Install Date: Sun 03 Mar 2019 12:13:36 PM EST Group : Applications/System Size : 3196613 License : ISC Signature : (none) Source RPM : sudo-1.8.23-3.1551336486.el7_6.src.rpm Build Date : Thu 28 Feb 2019 01:49:12 AM EST bash-4.2$ sudo /bin/rsync -d /home /tmp/ sudo: PAM account management error: Authentication service cannot retrieve authentication info /var/log/secure does not show any additional information. I added these two lines to sudo.conf Debug sudo /var/log/sudo_debug all@debug Debug sudoers.so /var/log/sudo_debug all@debug But the only output in /var/log/sudo_debug is: Mar 3 13:07:02 sudo[27680] PAM account management error: Authentication service cannot retrieve authentication info: Unknown error -1 What next?
I've done a bugzilla search for similar terms as my own and do not see any, so my question would be what is different about my setup vs the expected. This server has been running since early 2000 starting with RH6 then migrating to early Fedora and then to SL 6.1 and now SL 7.6. Well?
(In reply to Kelly-Rand from comment #14) > I've done a bugzilla search for similar terms as my own and do not see any, > so my question would be what is different about my setup vs the expected. > This server has been running since early 2000 starting with RH6 then > migrating to early Fedora and then to SL 6.1 and now SL 7.6. > > Well? Maybe a strace log would give us more insight into what is happening: ``` # strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync ``` Does the backuppc user have an entry in both /etc/shadow and /etc/passwd?
Does the test RPM contain the patch from https://www.sudo.ws/pipermail/sudo-users/2018-December/006160.html, which seems to be related?
Created attachment 1541791 [details] testing build patch
(In reply to James Juran from comment #17) > Does the test RPM contain the patch from > https://www.sudo.ws/pipermail/sudo-users/2018-December/006160.html, which > seems to be related? Yes, that is the patch used in the testing build. I've attached the patch to this BZ so that is clear what is being tested.
I won't be able to get the strace results till around 3/16. I'm away and don't have access to the system.
Created attachment 1543045 [details] Sudo strace log for version 1.8.23-3.1551336486 Requested log info for command: # strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync -d /home /tmp/ sudo: PAM account management error: Authentication service cannot retrieve authentication info
The user backuppc has an entry in /etc/passwd but NOT in /etc/shadow
(In reply to Kelly-Rand from comment #22) > The user backuppc has an entry in /etc/passwd but NOT in /etc/shadow Ok, that might be the trigger of the issue. I'll try to reproduce it myself. If you'll have a chance to test it too -- i.e. adding the /etc/shadow entry and try sudo again --, then please do.
(In reply to Kelly-Rand from comment #21) > Created attachment 1543045 [details] > Sudo strace log for version 1.8.23-3.1551336486 > > Requested log info for command: > # strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync -d /home > /tmp/ > sudo: PAM account management error: Authentication service cannot retrieve > authentication info I've successfully reproduces this error by creating the backuppc user via useradd and then removing the /etc/shadow entry. So, if you want to fix the issue at your site, please add that missing /etc/shadow entry. Do you have an idea how did you end up with an entry in /etc/passwd but not in /etc/shadow? How was the backuppc entry created?
Adding backuppc via "pwck" fixed the issue. I am now running sudo version 1.8.3-23-3. As for why the user backuppc was not in shadow will be a mystery. I can guess that it happened during a distro version change, as retaining existing users and their existing UID/GID's is cumbersome. running 'pwck -r' after distro version changes will become part of my routine.
Ok, great to have this resolved. I'll close this as NOTABUG then.
I am now seeing the same thing on EL8, for user who DOES have an entry in /etc/shadow, but has no password set. We were using ssh keys to log user in, and it was working until I made some change to the krb5/sssd config, in order to authenticate vs a domain. Then suddenly hit this [someuser@implicit_files@somehost ~]$ sudo su - sudo: PAM account management error: Authentication service cannot retrieve authentication info "authselect check" and "pwck" report no relevant issues. Setting a password for the user resolved the issue, and also got rid of the "@implicit_files" nonsense. There is an *INFESTATION* of bugs here...
Nope, setting password is not resolving the issue. It did, briefly, but restarting sssd has brought the issue back. This is what i saw, after disabling sssd and setting password: [root@blah ~]# passwd meh Changing password for user meh. New password: BAD PASSWORD: The password is shorter than 8 characters Retype new password: passwd: all authentication tokens updated successfully. [root@blah ~]# exit logout [meh@implicit_files@blah ~]$ exit logout Connection to blah closed. [07-09 15:35:22 ~]$ [07-09 15:35:23 ~]$ ssh -i somekey -o StrictHostKeyChecking=no -X meh@blah Last login: Tue Jul 9 15:09:19 2019 from someip [meh@blah ~]$ sudo su - Last login: Tue Jul 9 15:10:06 AEST 2019 on pts/0 [root@blah ~]# Looked good. But after enabling sssd and rebooting, the problem is back, and now, resetting the password does not resolve the issue *at all*. Once again, Red Hat proves to be a massive PITA. Red Hat can't even put together an OS you can reliably login to, and sudo on. Just pitiful.
Ah, hangon, no, it seems that when sssd is off, i can login without seeing this unbelievably ugly @implicit_files garbage. And, i can sudo. So, this ridiculous behaviur i'm seeing looks like it is the a problem in SSSD. What a piece of garbage that thing is.
Nope, can't even reliably login with sssd off. I kid you not, it looks like starting sssd does something that causes this error, and stopping sssd does not fix it. But if I run "passwd" to set the password of the user in question, *after* stopping sssd, then that fixes the user's sudo problems& @implicit_file nonsense... at least until sssd is restarted. What an appalling mess.
In my case, on el8, I have narrowed this down to using: default_domain_suffix = somedomain in my /etc/sssd/sssd.conf I was doing this, because our hosts are joining one domain, but the admin users who most frequently login, are from another trusted domain, so I want those users to be able to login without specifying their domain. So now, on EL8, i have to disable this option, and they have to give their full domain when they login. Hopeless. Just hopeless.
Hi Can you please reopen this BUG. I'm having this same issue on CentOS 7 with users which are in TACACS+. Current system sudo rpm "sudo-1.8.23-3.el7.x86_64.rpm" --Broken Upgraded to sudo rpm "sudo-1.8.23-4.el7.x86_64.rpm" --Broken Downgraded to sudo-1.8.19p2-11.el7_4.rpm and it's working without any change. Following are the Step to Reproduce with TACACS+ Step to Reproduce ---------------------- 1. ssh to the target system 2. sudo su - - First time it will be successful --- 3. exit from sudo exit 4. In the same session of ssh, try to do the sudo again sudo su - Now you will start getting error until you close your ssh session or exit from ssh and do it again. Note: As User exists in TACACS+, it will have no entry in /etc/password or /etc/security ----Output------ [ root@Term1:~ ]# ssh isasu@mycentos TACACS+ Password: [isasu@centos.7.6.1810 ~]$ uname -a Linux centos.7.6.1810 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [isasu@centos.7.6.1810 ~]$ sudo su - TACACS+ Password: Last login: Wed Oct 23 21:38:13 UTC 2019 from 192.168.1.10 on pts/0 [root@centos.7.6.1810 ~]# exit logout [isasu@centos.7.6.1810 ~]$ sudo su - sudo: PAM account management error: Authentication service cannot retrieve authentication info [isasu@centos.7.6.1810 ~]$ exit [ root@Term1:~ ]# Logs ================================== [root@centos.7.6.1810 ~]# grep isasu /etc/sudoers isasu ALL=(ALL) NOPASSWD: ALL /var/log/secure Oct 23 21:51:02 centos.7.6.1810 sshd[13432]: Accepted keyboard-interactive/pam for isasu from 127.0.0.1 port 47926 ssh2 Oct 23 21:51:02 centos.7.6.1810 sshd[13432]: pam_unix(sshd:session): session opened for user isasu by (uid=0) Oct 23 21:51:07 centos.7.6.1810 sudo: isasu : TTY=pts/3 ; PWD=/home/qns-su ; USER=root ; COMMAND=/bin/su - Oct 23 21:51:07 centos.7.6.1810 sudo: pam_unix(sudo:session): session opened for user root by isasu(uid=0) Oct 23 21:51:07 centos.7.6.1810 su: pam_unix(su-l:session): session opened for user root by isasu(uid=0) Oct 23 21:51:08 centos.7.6.1810 su: pam_unix(su-l:session): session closed for user root Oct 23 21:51:08 centos.7.6.1810 sudo: pam_unix(sudo:session): session closed for user root Oct 23 21:51:10 centos.7.6.1810 sudo[13993]: pam_sss(sudo:account): Access denied for user isasu: 10 (User not known to the underlying authentication module) Oct 23 21:51:10 centos.7.6.1810 sudo: isasu : PAM account management error: Authentication service cannot retrieve authentication info ; TTY=pts/3 ; PWD=/home/qns-su ; USER=root ; COMMAND=/bin/su - /var/log/messages Oct 23 21:49:27 centos.7.6.1810 systemd: Started Session 1616 of user isasu. Oct 23 21:49:46 centos.7.6.1810 systemd-logind: Removed session 1616. Oct 23 21:49:46 centos.7.6.1810 systemd: Removed slice User Slice of isasu. Oct 23 21:49:53 centos.7.6.1810 systemd: Created slice User Slice of isasu. Oct 23 21:49:53 centos.7.6.1810 systemd: Started Session 1617 of user isasu. Oct 23 21:49:53 centos.7.6.1810 systemd-logind: New session 1617 of user isasu. Oct 23 21:49:57 centos.7.6.1810 su: (to root) isasu on pts/3 Oct 23 21:50:02 centos.7.6.1810 PAM-tacplus[11425]: user not authenticated by TACACS+ Oct 23 21:50:05 centos.7.6.1810 systemd-logind: Removed session 1617. Oct 23 21:50:05 centos.7.6.1810 systemd: Removed slice User Slice of isasu. Oct 23 21:51:02 centos.7.6.1810 systemd: Created slice User Slice of isasu. Oct 23 21:51:02 centos.7.6.1810 systemd: Started Session 1618 of user isasu. Oct 23 21:51:02 centos.7.6.1810 systemd-logind: New session 1618 of user isasu. Oct 23 21:51:07 centos.7.6.1810 su: (to root) isasu on pts/3 Oct 23 21:51:10 centos.7.6.1810 PAM-tacplus[13993]: user not authenticated by TACACS+ --------sudo and pam rpm info [ root@centos.7.6.1810:~ ]# rpm -qi pam Name : pam Version : 1.1.8 Release : 22.el7 Architecture: x86_64 Install Date: Tue 28 May 2019 04:03:41 PM UTC Group : System Environment/Base Size : 2630324 License : BSD and GPLv2+ Signature : RSA/SHA256, Wed 25 Apr 2018 11:33:49 AM UTC, Key ID 24c6a8a7f4a80eb5 Source RPM : pam-1.1.8-22.el7.src.rpm Build Date : Wed 11 Apr 2018 03:22:15 AM UTC Build Host : x86-01.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.linux-pam.org/ Summary : An extensible library which provides authentication for applications Description : PAM (Pluggable Authentication Modules) is a system security tool that allows system administrators to set authentication policy without having to recompile programs that handle authentication. [ root@centos.7.6.1810:~ ]# rpm -qi sudo Name : sudo Version : 1.8.23 Release : 3.el7 Architecture: x86_64 Install Date: Thu 17 Oct 2019 01:41:19 AM UTC Group : Applications/System Size : 3196629 License : ISC Signature : RSA/SHA256, Mon 12 Nov 2018 02:47:22 PM UTC, Key ID 24c6a8a7f4a80eb5 Source RPM : sudo-1.8.23-3.el7.src.rpm Build Date : Wed 31 Oct 2018 12:37:04 AM UTC Build Host : x86-01.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.courtesan.com/sudo/ Summary : Allows restricted root access for specified users Description : Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis. It is not a replacement for the shell. Features include: the ability to restrict what commands a user may run on a per-host basis, copious logging of each command (providing a clear audit trail of who did what), a configurable timeout of the sudo command, and the ability to use the same configuration file (sudoers) on many different machines. [ root@centos.7.6.1810:~ ]#
We have also had an issue with the new sudo package (in 7u7). We are using the pam-script module from https://github.com/jeroennijhof/pam_script, and have noticed a change in behaviour when using sudo. With sudo 1.8.19p2-10 (7u4), our scripts did not appear to be run at all, which I take to mean that sudo was not using PAM. With sudo-1.8.23-4 (7u7), we are finding that our PAM scripts ARE being run for the PAM "account" operation, and are run as the originating user. We expected that they would be run as root since sudo is, obviously, setuid to root. Has there been a change in the way sudo uses PAM between the two versions? A change in the defaults, perhaps?
Can someone please reopen this BUG as i reported earlier ? or do i need to open another one ?
There was definitely a change in the way how sudo call pam stack. Previously it did not do that. From the description I would say there's some issue with sssd configuration rather than with sudo. Can you provide us pam stack configuration, sssd configuration, and sudo configuration? There might be other configurations needed for the analysis, a sosreport tool might get handy here.