If you wanna skip to the TLDR, feel free to do that as long as you know what you're doing.

So I woke up today and ssh'd into a VM that I own on a network that isn't connected to the internet and with no access to it. I typed in my annoyingly long password to sudo !! as my non-root (but sudoer) user, and the thing happens where I know I typed in my password wrong and now I have to wait what feels like an eternity to type in a command after forgetting to use sudo in the first place.

So anyway this has been plaguing me for years and stealing precious minutes of my attention span so I decided to figure out and how to change it.

I only know this for this VM's specs, which is currently Ubuntu 16.04.6 LTS. It might be different from yours. If I do it for other distros I'll maybe update this post, but it should be similar.

Why have this in the first place?

If you haven't thought about this before, you should. We have timed lock-outs for failed authentication for security reasons for general things, mainly because it limits the number of times that a bot/hacker/script can brute-force your password.

Now, the implementation/practical effectiveness of the lock-out for sudo and general login (i.e via PAM) can be argued for and against, but I won't go into that here. I assume you know the following:

1. security should be an aspect of all layers
2. every approach to building things has pros and cons with different weights

Also, lastly, be aware that anything I write about PAM will be littered with these gifs and pictures.

Okay so how?

Pretty ready to not have this workflow.

btamayo@px01:~$ su deploy  
Password:  
<THREE SECONDS OF UGH>  
su: Authentication failure  

btamayo@px01:~$ sudo su -  
[sudo] password for btamayo:
<THREE SECONDS OF UGH>  
Sorry, try again.  

So the first google result I looked at told me to go to /etc/logins.defs and look for something called FAIL_DELAY which was commented out and didn't affect anything. I checked on just Debian and it was the same way as well.

So I skipped that part and went to the second part where it told me to go to /etc/pam.d/ and look in the configs there. I looked in the files /etc/pam.d/login, /etc/pam.d/su, and /etc/pam.d/sudo.

In login, there was a line that said:

...
# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the `FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth       optional   pam_faildelay.so  delay=3000000  
...

NOTE that said microseconds which I missed and wrongly assumed was in milliseconds the first time and was confused for five whole minutes as I didn't understand why it would be 50+ minutes long.

1. login, sudo, and su (and other files I assume) all included a file called common-auth, which I looked in and found the line that it told me to look for:

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure  
...

(The above is from /etc/pam.d/common-auth.)

Ok, so I just want to change sudo at this point because I really need to not get sidetracked in to learning PAM today, even though I'm curious and tempted because I love digging around stuff like this.

nullok_secure

I don't remember seeing this in the manpage I read, so looked it up, and it seems to be a Debian thing. I'm not sure whether it's supported in other distros, and if so, if it's just that it's the default in Debian. Let me know!

🔗 TLDR: Changing the delay

Change this line in /etc/pam.d/common-auth (Debian systems):

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure  
...

to

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure nodelay  
...

The nodelay removes the default 2-second delay, allowing other configs to possibly override this delay with something less than 2 seconds. All configs inheriting this file without adding their own delay, including sshd will have no delay.

To add in a delay now, (I assume that that minimum 2-second delay is built-in to pam_unix.so but lmk if that's not true! curious.) You can add a config to specify the delay by adding the following line to any file:

auth       optional   pam_faildelay.so  delay=1500000  

(You can read the man page of this module via man pam_faildelay.)

And change the value of the delay= (which is in microseconds) in any of the config files.

For example, my /etc/pam.d/sudo file is now:

auth       optional   pam_faildelay.so  delay=1000000

@include common-auth
@include common-account
@include common-session-noninteractive

Which gives me 1000000 microseconds of a delay when I password-authenticate with sudo and fail.

(If you mess around with PAM configuration on systems over the internet, you should also look into how PAM interacts with sshd. Read /etc/ssh/sshd_config's text info block on the UsePAM option, /etc/pam.d/sshd file, and do some Googling as well.)

You can also mess around with the control flags (optional in the case of pam_faildelay.so to something that better suits you. I won't go into that now, but you can find their meanings here: https://linux.die.net/man/5/pam.d

I hope this helps somehow. It's really interesting and I wish I had time today to fall into the PAM rabbit-hole but that's next time and we can write a blog post then too :)