3

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[1126]: Accepted publickey for username from 111.111.111.11 port 52768 ssh2: RSA SHA256:<omitted>
Jan 31 10:46:48 izu sshd[1126]: pam_unix(sshd:session): session opened for user username by (uid=0)
Jan 31 10:46:48 izu systemd-logind[679]: 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[1126]: User child is on pid 1150
Jan 31 10:46:48 izu sshd[1150]: Starting session: shell on pts/0 for username from 111.111.111.11 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
  • 1
    Is rootpw or targetpw set in sudoers? – Jeff Schaller Jan 31 at 18:39
  • 1
    @JeffSchaller - neither is in sudoers - I added sudoers content listing for your perusal. The prompt [sudo] password for user: seems to indicate the default is for the users password. I also set and tried root password, but that didn't work. – Craig Hicks Jan 31 at 18:59
  • 1
    @steve - added. – Craig Hicks Jan 31 at 19:39
  • 1
    I agree with @steve /etc/pam.d/sudo is your next step. Also double check the file system and make sure that /usr/bin/sudo is set with owner root, group root permissions -rwsr-xr-x – Philip Couling Jan 31 at 20:32
  • 1
    @JeffSchaller - It turns out that a change I made long ago to /etc/pam/common-auth , which sent mail with a grep'd excerpt from the log file in case of bad login/sudo, was incompatible after the update. It still sent mail, but every login/sudo was bad. After restoring the original version, it is now functioning correctly. – Craig Hicks Jan 31 at 20:53
1

The advice from @steve about the problem being in /etc/pam.d was correct.

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

AFIR, that file and others in /etc/pam.d contains sequential instructions which push return values onto a stack - it's not simple to understand and it's fragile, and apparently sensitive to updates.

The point of putting the modification there was to capture both sudo and login (and ssh key login?) failures at one point. It was something I saw on Stack Exchange somewhere ... Now I will implement each of those functions separately in orthodox ways. Bad sudos are easy - I only had to have these two lines in /etc/sudoers

Defaults    mail_badpass
Defaults    mailerpath="/usr/local/sbin/sendmail"

In my case this sendmail is not standard - it sends via an API to a free mail service. An orthodox mail setup wouldn't require that line.

  • The instructions @CraigHicks followed to setup email sending upon bad login attempts is described in askubuntu.com/a/729841/21195 by me. I'm not sure what caused this behavior but your /etc/pam.d/common-auth is set with success=1 where it should be success=2. – Rodrigo Martins Jan 31 at 23:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.