Sudo stops working (will not accept password) - reboot restores function

ARM Technical Assistance
1

Running Manjaro-ARM-kde-plasma-rpi4-21.04.img on an rpi4 and am experiencing something extremely peculiar. After some time (seems arbitrary; it happened after a few minutes once and then after several hours of it running another time) sudo stops accepting the correct password. I can still su in as root just fine and that functionality seems to work and then I can reboot as well without a problem. When the system reboots sudo works again for my primary user!

Clearly this is an intermittent issue that’s provoked by something and while a search yields some interesting results, I don’t see actual precise documentation for what’s going on or a solution. It is especially concerning that threads seem to go fairly far back in history.

Is this a known bug that’s being worked out presently and if so can you point me to the right thread or issue so as to contribute to resolution?

Side note: the main user with this problem is a member of wheel

2

do you remember the command you used before it went out.
in terminal: history | grep sudo

3

Was the password retry limit exceeded (3).

faillock --user THE_USERID # display failed attempts
journalctl --boot=0        # anything related in the journal (syslog),
4

I have experienced this on Plasma Mobile a couple of times. Not sure what the issue is. I work around it by sudo su. But I am a trained professional, don’t attempt this at home. :wink:

5

“this” as in locked out for 10 minutes after 3-failed attempts (logon, sudo, by user or automation) within 15 minutes. If that’s the case, it is PAM.

The issue that is suppose to be addressed is a brute force attack.

For the sake of this thread,

sudo - you enter your password so you can issue commands as root.
su - you enter root’s password so you can become root.

You might find something helpful in this bug report, although it isn’t a bug per se.
https://bugs.archlinux.org/task/67644?project=1&order=votes&sort=desc&order2=dateopened&sort2=desc

6

No, as in I am working in the terminal app and try to execute a command via sudo and it refuses to accept the password any more. Only a reboot “fixes” the issue.

7

@kerry_s unfortunately no - do not recall and we happened to have two bash shells open so history got skewed around the time that that happened.

@stargazer no and this seems to be repeatable in some fashion and neither of us entered the wrong password a single time. As to your 2nd point: again, not a single wrong password was attempted. This was repeated and I can assure and reassure that this is the case.

@0n0w1c yeah, we’re just using su right now as a “work around”… :wink:

8

Anything in the log. Since there’s a reboot involved, journalctl --boot=-1. Use journalctl --list-boots to confirm the ID number.

faillock and/or the journal confirmed this.

9

Did you check your hash algorythm ? In /etc/shadow tour hash must start with $6$. Use passwd to update it.

10