Unable to enter correct password

[kojq]

Operating System information: Arch Linux (on both GNOME and KDE)

Current sudo version: 1.9.12.p1

For the past few months (when I began using sudo), I have noticed that on rare occasion, sudo denies the correct password upon the first and subsequent attempts. This occurs on multiple devices and lasts for ~4 minutes. My observation is that the password is rejected in the console, tty, and display manager (used GDM and SDDM). I do not know how to consistently replicate the situation.

[millert]

If this happens again, check the system logs for errors from the PAM subsystem. That may shed some light onto the situation.

[kojq]

Here is what I have:

Here is the PAM configuration from /etc/pam.d/sudo:

#%PAM-1.0
auth		include		system-auth
account		include		system-auth
session		include		system-auth

[millert]

For some reason PAM is unable to get your authorization token, which should just be the encrypted password from /etc/shadow.

You might try adding the following to /etc/sudoers and see if it makes any difference:

Defaults !pam_setcred

That will prevent sudo from reinitializing the user's credentials but I'm not sure whether that will really make a difference for password authentication.

[kojq]

You might try adding the following to /etc/sudoers and see if it makes any difference:

Defaults !pam_setcred

I've done this; it will take time to see if this does make any difference.

In the meanwhile, is there anything else to check? As this occurs with each install of Arch Linux (with archinstall being used for consistency), is it plausible that any configuration from the Arch Linux distribution could interfere? Currently, the only archinstall configurations I had set in such regard were no root enabled and one superuser. For now, it is unlikely for me to be able to determine whether this is a distribution-agnostic issue.

[kojq]

The issue still occurs with 1.9.13.p3 regardless of having added Defaults !pam_setcred to /etc/sudoers.

[millert]

If you mistyped your password three times you could be getting locked out by the pam_faillock module for a period of time (defaults to 15 minutes). It is enabled by default in /etc/pam.d/system-auth on Arch.

[kojq]

Yes, but this issue has occurred on the first attempt as well (it can occur upon any attempt). After entering correctly three times, I would get locked out. The issue is not getting locked out. The issue is that I could enter correctly multiple times and get rejected although the password is correct.

[kojq]

To be more accurate, whenever the issue occurred, I never confirmed whether the first attempt was correct. I only confirmed subsequent immediate attempts.

[millert]

That is exactly the behavior I see when pam_faillock has locked me out. It doesn't matter whether you enter the password correctly or not, it will be rejected. For example, here I mistype the password three times, triggering pam_faillock.

$ sudo -v
[sudo] password for millert:
Sorry, try again.
[sudo] password for millert:
Sorry, try again.
[sudo] password for millert:
sudo: 3 incorrect password attempts

Now I see this in the logs:

Jul 29 16:54:06 6e91e9dd39b9 sudo: pam_faillock(sudo:auth): Consecutive login failures for user millert account temporarily locked

And if I try to use sudo with the correct password there is no way to tell that I am locked out.

$ sudo id
[sudo] password for millert:
Sorry, try again.
[sudo] password for millert:
Sorry, try again.
[sudo] password for millert:
sudo: 3 incorrect password attempts

And there is a file in the faillock directory:

# ls -l /var/run/faillock/millert
-rw-rw---- 1 millert millert 192 Jul 29 16:54 /var/run/faillock/millert

Removing that lets me authenticate successfully (waiting until the lock period is over would also work).

Can you check for pam_faillock messages in your logs?

[kojq]

I see what you are saying now, thanks for clarifying.

In the case of this occurring in the display manager, I believe it should mention the lock period, but it did not until entering the correct password three time, where it then proceeded to mention lock out.

I can do the same as you to see the pam_faillock messages in the logs. However, with the issue, I am quite certain the last/prior attempt was successful. I don't recall whether there were pam_faillock messages in the logs when I've had the issue.

I will check for the messages and the file in the faillock directory and return with results for when this occurs. I am currently using 1.9.14p3 with no issues. If I can't replicate or this doesn't go anywhere, you can close this.

[sidkshatriya]

I experienced something similar described in this issue today. I too am using Arch Linux (aarch64 archlinuxarm flavor).

I updated my packages today via the usual pacman -Syu. This made my sudo version go from 1.9.14.p3 to 1.9.15.p1 . I did not restart my machine after updating the packages and continued using it.

What was instantly interesting was that I was presented with a "With great power comes great responsibility [...]" when I tried doing sudo subsequently.

This is funny because I have been using sudo for a very long time. I would have thought that this message only triggers for the very first time a sudoer uses sudo. Somehow, updating the package seems to have triggered this message for me again.

Then, I'm not sure if I genuinely typed my password 3 times wrongly or not. Could my password entry have been correct but due to the update of sudo version things went wonky ? Anyways after investigating later this seems to have triggered pam_faillock indeed as mentioned by @millert :

...
pam_faillock(sudo:auth): Consecutive login failures for user abcxyz account temporarily locked
   abcxyz : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/etc ; USER=root ; COMMAND=/usr/bin/su
...

Now I couldn't do sudo at all and this caused a slight panic. (I was not aware of pam_faillock ).

Question:
I logged out and my graphical desktop display manager SDDM refused to log me in too. Will this also be caused by pam_faillock ?

Only after restarting my machine I was able to log back in again.

[millert]

That does sound like pam_faillock. This is a PAM configuration issue, not a sudo bug. The reason you got the sudo lecture is that the path to the time stamp and lecture files changed in 1.9.15 so that is unrelated.

[sidkshatriya]

That does sound like pam_faillock.

Thanks for your comment, it was helpful. Yes, this is most likely a PAM issue it seems. I'm not really familiar with authentication on Linux. Would a pam_failock cause a failure to login on my graphical display manager also ? Of course, this is not related to sudo but I was wondering if that would be the case.

Thanks again !

[millert]

@sidkshatriya Yes, it would also prevent you from logging in via the graphical display manager.

[kojq]

pam_faillock messages are not in the logs.

[kojq]

Here are the logs:

[Ferdi265]

I'm experiencing this issue as well, though the name of the issue is not great. Something like "no way to distinguish between wrong password and locked account" would be a better name for the issue.

The reason why sudo does not display the "The account is locked due to N failed logins." is because sudo passes PAM_SILENT to the pam_authenticate() call in plugins/sudoers/auth/pam.c on line 321. If that flag is replaced with 0, sudo will display the account lock message correctly.

Of course, not displaying this can be seen as a "security feature" since an attacker would not immediately know whether the password was wrong or the account locked, though since sudo is usually used by users who are already logged in, they could instead run faillock --user $USER --reset anyway and bypass faillock.

I suggest that disabling the PAM_SILENT flag in sudo should be a configuration option or at least compile time flag, since some users would probably want to know when they have locked themselves out.

I already have a branch implementing a config option for this, though I still need to test it and clean it up a bit (especially the documentation changes to the man pages) before I can open a PR for it

[kojq]

I'm wondering why it is possible to lock on the first attempt.

[Ferdi265]

Faillock counts failed attempts over a configurable period, the default on Arch seems to be 15 minutes. The number of failed attempts counted by faillock is independent from the number of failed attempts counted by sudo (e.g. the "3 failed attempts" message). AFAIK, timeouts or canceled logins seem to also count as failed attempts. This combined can lead to situations where you only input one actually interactive attempt, and the others happen in a way that you don't notice.

[kojq]

This does seem plausible. However, I have had this issue occur a number of times with sudo whereas this has not happened with something else such as doas, in my experience.

[Ferdi265]

@kojq That could very well be.

In the meantime, I have created a PR that adds a config option to disable PAM_SILENT, so that the faillock messages can be displayed properly.

[Ferdi265]

@kojq That could very well be.

In the meantime, I have created a PR that adds a config option to disable PAM_SILENT, so that the faillock messages can be displayed properly.

This has now been released as of sudo 1.9.16. Just add Defaults !pam_silent to your sudoers file.