3

Why does adding this line to /etc/pam.d/common-auth:

auth        required      pam_tally2.so deny=4 unlock_time=1200 even_deny_root

and adding this line to /etc/pam.d/common-account:

account     required      pam_tally2.so

prevent all logins to my Debian 10 system? All of my other pam configuration files (login, common-session, and common-password are unchanged from the defaults, but I can post those too if necessary).

I've seen a couple of other questions that discuss pam_tally, e.g. this one, this one, and this one, but they either don't have answers specific to pam_tally or don't have any answers at all.

(For background, I'm trying to adapt this updated guide for Debian systems)

EDIT: The libpam-modules package is installed.

From common-auth:

auth    [success=1 default=ignore]  pam_unix.so nullok_secure
auth    required      pam_tally2.so deny=4 unlock_time=1200 even_deny_root
auth    requisite     pam_deny.so
auth    required      pam_permit.so

From common-account:

account required      pam_tally2.so
account [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so 
account requisite     pam_deny.so
account required      pam_permit.so
2
  • @roaima I don't have an SSH server installed on this machine, if that's the part of your answer that you're referring to. I don't have an sshd_config file at all.
    – Michael A
    Jan 17, 2020 at 20:41
  • Thanks again, I updated the question. I'm sure I'm just getting confused with the ordering of some of the commands, and which (if any) of the defaults I should keep or remove.
    – Michael A
    Jan 17, 2020 at 22:15

1 Answer 1

7
+50

There are two parts for this answer. The first adds pam_tally2 to auth. The second adds it to account. You need both parts for pam_tally2 to work correctly.

Let's look at your common-auth,

auth    [success=1 default=ignore]  pam_unix.so nullok_secure
auth    required      pam_tally2.so deny=4 unlock_time=1200 even_deny_root
auth    requisite     pam_deny.so
auth    required      pam_permit.so

The first line says, "Try using UNIX (/etc/passwd) authentication. If it succeeds, skip one line and continue. Otherwise carry on to the next step." Using this logic here's how the problem manifests:

  1. Success: we skip one line (success=1), ie pam_tally2, and hit pam_deny which denies the login
  2. Failure: we hit pam_tally2 and then pam_deny, which denies the login

As you can now see, this will prevent all logins.

Part of the solution is to put pam_tally2 in the list at the top of the stack. (You might think changing success=2 would work, but this would skip pam_tally2 for successful authentication so it could only be reset from a failure after its timeout had expired.) Here's mine, from a fairly vanilla Debian system:

auth    required                        pam_tally2.so deny=5 unlock_time=1200 even_deny_root
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# 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)
auth    optional                        pam_cap.so
# end of pam-auth-update config

This increments the tally, but you need a way to reset it after successful logins without resorting to the pam_tally2 command. What's not particularly obvious is that you need to add pam_tally2.so to the account section, also as the first entry

account required                        pam_tally2.so onerr=fail

I have tested this, but when you try it out make sure you have an additional root shell open on the target machine (e.g. sudo -s) so that you can revert any changes to the PAM configuration!

You can see what is going on with tail -F /var/log/auth.log and watch pam_tally2 --user {user}.

Notice that the tally is incremented as soon as authentication is attempted, and reset only on success, so the tally limit must be to be one greater than the number of permitted attempts.

4
  • This is brilliant. Maybe it's a separate question, but do I need pam_cap? It isn't clear to me from the documentation what that does (probably because I'm not familiar with the POSIX 1003.1e standard). Otherwise everything works perfectly! I didn't even need to add account required pam_tally2.so to /etc/pam.d/common-auth.
    – Michael A
    Jan 18, 2020 at 20:12
  • pam_cap sets up capabilities per user. If your system has it installed then keep it there. Put pam_tally2 at the top of the stack and you should be good. Jan 18, 2020 at 20:32
  • Very good answer : very informative and detailling exactly step by step how the file is interpreted. Is there some similar referece online about those auth files (which I haven't modified yet on my system but dread the day I'd have to...) Sep 7, 2023 at 12:35
  • 1
    @OlivierDulac there is the full PAM documentation, which explains how it all fits together, the working examples shipped in each distribution, and the man page for the specials like pam_tally2. If/when you have a specific question please ask that separately. If you ping me here when you've posted it I'll see what I can do to answer Sep 7, 2023 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .