After system update/upgrade, I cannot escalate with sudo using correct password:
user $ sudo -s [sudo] password for user: ******************** Sorry, try again. [sudo] password for user: ******************** Sorry, try again.
(It is a VPS, and login is done via ssh without password - password is only needed for sudo)
Group is set correctly.
$ groups user user : user sudo docker
This line is in /etc/sudoers :
# Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL
In rescue mode, reset the password, double checked the contents of /etc/shadow against an independent program:
mkpasswd --method=sha-512 --salt=GiHwtvMC Password: ******************** $6$GiHwtvMC$pONfZo5...<omitted>...Vg5c0
The output matches exactly the hash shown in /etc/shadow. Still sudo escalation fails.
Are there other system settings that could prevent sudo escalation with a correct password?
(It occurred to me that the upgrade could have contained a targeted deliberate hack to persuade me to allow sudo escalation without a password, but that seems most unlikely).
Contents of /etc/sudoers , comments removed
Defaults env_reset,timestamp_timeout=-1 Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:" root ALL=(ALL:ALL) ALL %admin ALL=(ALL) ALL %sudo ALL=(ALL:ALL) ALL
excerpt from /var/log/auth.log
Jan 31 10:46:48 izu sshd: Accepted publickey for username from 188.8.131.52 port 52768 ssh2: RSA SHA256:<omitted> Jan 31 10:46:48 izu sshd: pam_unix(sshd:session): session opened for user username by (uid=0) Jan 31 10:46:48 izu systemd-logind: New session 1 of user username. Jan 31 10:46:48 izu systemd: pam_unix(systemd-user:session): session opened for user username by (uid=0) Jan 31 10:46:48 izu sshd: User child is on pid 1150 Jan 31 10:46:48 izu sshd: Starting session: shell on pts/0 for username from 184.108.40.206 port 52768 id 0 Jan 31 10:47:16 izu sudo: pam_unix(sudo:auth): authentication failure; logname=username uid=1000 euid=0 tty=/dev/pts/0 ruser=username rhost= user=username
The problem was in a previously working modification to /etc/pam.d/common-auth enabling logfile excerpts to be sent by email.
# here are the per-package modules (the "Primary" block) auth [success=1 default=ignore] pam_unix.so nullok_secure # ADDED HOOK NOW REMOVED auth optional pam_exec.so seteuid /etc/local/lib/pam_auth_fail_notify.sh # 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) # end of pam-auth-update config