[SOLVED] Sudo password not recognised (intermittently)

boogoose · 2021-02-08 19:52:06

System behaves as if I've entered an incorrect password when i attempt to issue Sudo command.

Arch installation is about 9 days old, and my typical usage is to launch a rather minimal Xorg server environment (with I3wm) using <startx>.

Problem first occurred yesterday, and appeared to have been solved after I re-added my user to the wheel group (although I did not initially check that membership of the group had in fact been lost).

Problem reoccurred today and seemed insoluble for several hours. During this time I double-checked password was correct, reset password anyway (despite being correct), removed user from wheel group and then added user again, and checked that /etc/sudoers was in order. During this time I also created an additional test-user account in an identical fashion to the primary user account. The sudo command functioned properly for this user without any problem with authentication of the password.

None of my efforts to solve the problem appeared to have had any effect today. At some point however the problem seemed to resolve itself - during which time I did a full system update (which I believe was only about 4 packages), Shortly after this, the problem re-arose and persists now.

Unsure how to proceed. Help would be appreciated.

Last edited by boogoose (2021-02-09 13:03:25)

Scimmia · 2021-02-08 19:55:33

Look up pam faillock. I'm betting that's what you're running into.

boogoose · 2021-02-08 22:41:28

Thank you Scimmia!

It really looks like it could be connected to this.

I'm very confident however that I am typing the password correctly, so it's not clear to me what could be responsible for triggering this mechanism.

To illustrate - prior to issuing <startx> I log in to the user account by typing the password accurately virtually every time. Once in the graphical environment however and faced with the sudo-pw-prompt, I am "apparently" entering the password incorrectly the vast majority of the time despite doing so with the utmost care.

Indeed, having researched pam- faillock a little, it seems to me that some process other than myself is triggering this (worryingly so).

Examining the tally-directory where the log-in failure records (or the last three of them) are kept with the command <faillock --dir /var/run/faillock/> I discover the following type of result;

user:
When Type Source Valid
2021-02-08 22:18:16 TTY V
2021-02-08 22:18:25 TTY V
2021-02-08 22:18:35 TTY V

All of this when i personally have most definitely not attempted any such log-ins. As I understand it this (and other results) indicate that some process or other is unsuccessfully attempting to login several times every minute! This is somewhat concerning to a noob like myself, and it's not clear to me how to identify the particular cause of all this even if I am understanding it correctly. Considering a re-install, but would like to know what's going on.

loqs · 2021-02-08 23:08:14

Check the journal see if the failures are for sudo or for login. sudo is more likely to be a script calling sudo that is improperly configured while login is more likely to be some device sending input to a tty.

seth · 2021-02-09 07:57:17

There's also https://bbs.archlinux.org/viewtopic.php?id=263257 and

I've tried logging out (close X, then use the command prompt login) then back in, and then my password is also not recognized and I get a "number of times till lock"

which doesn't sound like faillock and also the default faillock timeout is 10m, not "hours"

Open a root shell and keep that running, wait for the sudo block to occur, reset "faillock --user boogoose --reset" from the root shell, retry sudo.
If it still fails try

 echo mysupersecretpassword | sudo -S ls

(make sure your password doesn't end up/remain in your shell history! Typical setups will not add commands w/ a leading blank)

In doubt also upload your /etc/sudoers

boogoose · 2021-02-09 12:40:34

seth wrote:

There's also https://bbs.archlinux.org/viewtopic.php?id=263257 ...which doesn't sound like faillock and also the default faillock timeout is 10m, not "hours"

Thank you- I might not have been as clear as I could have been in my original post. Although to most intents and purposes at the time, I was locked out for hours, I now believe that the faillock-lockout was being triggered roughly every ten minutes, or perhaps 20 seconds after it came off cool-down.

Querying the faillock tally of failed authentications with <faillock --dir /var/run/faillock/> would result in output of the type;

user:
When Type Source Valid
2021-02-08 22:18:16 TTY V
2021-02-08 22:18:25 TTY V
2021-02-08 22:18:35 TTY V

... and then the output would not change for roughly ten minutes at which point three new instances - approximately ten seconds apart would be recorded.

<journalctl -r> however appeared to record persistent failed "authentications" for the entire ten minutes, and every succeeding ten minute period. For example:

Feb 08 22:24:03 arch dbus-daemon[642]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.133' (uid=0 pid=37318 comm=>
Feb 08 22:24:03 arch sudo[37318]: pam_unix(sudo:auth): auth could not identify password for [UserID]
Feb 08 22:24:03 arch audit[37318]: UserID_AUTH pid=37318 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=failed'
Feb 08 22:24:03 arch kernel: audit: type=1100 audit(1612823043.755:226): pid=37318 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr>
Feb 08 22:24:03 arch sudo[37318]: pam_unix(sudo:auth): conversation failed
Feb 08 22:20:34 arch kernel: audit: type=1100 audit(1612822834.755:225): pid=36780 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr>
Feb 08 22:20:34 arch sudo[36780]: pam_systemd_home(sudo:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Feb 08 22:20:34 arch audit[36780]: UserID_AUTH pid=36780 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=failed'
Feb 08 22:20:34 arch dbus-daemon[642]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Feb 08 22:20:34 arch dbus-daemon[642]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.132' (uid=0 pid=36780 comm=>
Feb 08 22:20:34 arch sudo[36780]: pam_unix(sudo:auth): auth could not identify password for [UserID]
Feb 08 22:20:34 arch sudo[36780]: pam_unix(sudo:auth): conversation failed
Feb 08 22:20:24 arch kernel: audit: type=1100 audit(1612822824.755:224): pid=36481 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr>
Feb 08 22:20:24 arch sudo[36481]: pam_systemd_home(sudo:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Feb 08 22:20:24 arch dbus-daemon[642]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Feb 08 22:20:24 arch audit[36481]: UserID_AUTH pid=36481 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication grantors=? acct="UserID" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=failed'
Feb 08 22:20:24 arch dbus-daemon[642]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.131' (uid=0 pid=36481 comm=>
Feb 08 22:20:24 arch sudo[36481]: pam_unix(sudo:auth): auth could not identify password for [UserID]
Feb 08 22:20:24 arch sudo[36481]: pam_unix(sudo:auth): conversation failed

I did try "faillock --user boogoose --reset" as you suggested and after a reboot I thought this might have solved the problem. There were a number of other changes I'd made at the time however and it seems the solution emanated from one of these.

boogoose · 2021-02-09 12:45:37

loqs wrote:

Check the journal see if the failures are for sudo or for login. sudo is more likely to be a script calling sudo that is improperly configured while login is more likely to be some device sending input to a tty.

This was invaluable, thank you. In part this led me to try disabling i3blocks - which appeared to solve the problem. I've now narrowed it down to one particular "block" or module which I had activated but failed to configure - as it wasn't showing up on the bar I just forgot about it.

#!/bin/bash
# you will have to enable passwordless sudo ind sudoers file if you want to use this
# Left click
if [[ "${BLOCK_BUTTON}" -eq 1 ]]; then
sudo ufw enable
# Middle click
elif [[ "${BLOCK_BUTTON}" -eq 2 ]]; then
sudo ufw reload
# Right click
elif [[ "${BLOCK_BUTTON}" -eq 3 ]]; then
sudo ufw disable
fi
# to get the status without the dirty sudoers file hack, do this:
#status=$(pgrep -f "ufw" 2>/dev/null)
# else keep this
status=$(sudo ufw status 2>/dev/null)
if [[ $? -gt 0 ]]; then
exit
fi
if [[ "${status}" != *inactive* ]]; then
echo "on"
echo "on"
echo ""
else
echo "off"
echo "off"
echo ""
fi

Ironically I'd failed to configure it because "enabling passwordless sudo" for this script sounded rather reckless security-wise to my noob-sensibilities. It seems however that failing to do so resulted in what appeared to me at times as a real, potential, or attempted security breach,

Anyway - I'll mark the OR as "solved" or whatever after one more run-through of recreating the problem just to be sure I've got it right. Thanks to everyone for your help. I've learnt a lot in the process, and could not or would not have done it without you.

Arch Linux

#1 2021-02-08 19:52:06

[SOLVED] Sudo password not recognised (intermittently)

#2 2021-02-08 19:55:33

Re: [SOLVED] Sudo password not recognised (intermittently)

#3 2021-02-08 22:41:28

Re: [SOLVED] Sudo password not recognised (intermittently)

#4 2021-02-08 23:08:14

Re: [SOLVED] Sudo password not recognised (intermittently)

#5 2021-02-09 07:57:17

Re: [SOLVED] Sudo password not recognised (intermittently)

#6 2021-02-09 12:40:34

Re: [SOLVED] Sudo password not recognised (intermittently)

#7 2021-02-09 12:45:37

Re: [SOLVED] Sudo password not recognised (intermittently)

Board footer