I just spent a couple of hours discovering faillog integration into PAM…
The original ticket was to reset a user password from the ubuntu root recovery session at the console. The ticket was old-ish. The server involved was DR (Disaster Recovery). No disaster, no urgency, therefore not a priority immediately.
Once the password was reset, ssh to the server still failed. The message was that authentication failed…
I've seen sshd and PAM behave poorly together before, so I disabled PAM in sshd_config (set "UsePAM no" and restart sshd). That fixed ssh for the specific user. But – sudo for that user failed…
I looked through the /etc/pam.d and /lib/security directories looking for any differences between this server and the failures and an identical server with successful ssh and successful sudo for the same user. I tried copying over the shadow and passwd files, looking for any difference that might cause the failure.
Nope. No change.
Finally, I was introduced to faillog.
The /var/log/auth.log file contained:
Mar 13 10:04:14 server sudo: pam_tally(sudo:auth): user admin (1010) tally 46, deny 4 Mar 13 10:04:20 server sudo: pam_tally(sudo:auth): user admin (1010) tally 47, deny 4 Mar 13 10:04:26 server sudo: pam_tally(sudo:auth): user admin (1010) tally 48, deny 4 Mar 13 10:04:35 server sudo: pam_unix(sudo:auth): authentication failure; logname=admin uid=0 euid=0 tty=/dev/pts/5 ruser= rhost= user=admin Mar 13 10:04:37 server sudo: admin : 3 incorrect password attempts ; TTY=pts/5 ; PWD=/home/admin ; USER=admin ; COMMAND=/bin/bash
pam_tally…
which creates faillog count…
root@server:~# faillog
Login Failures Maximum Latest On
admin2 0 0 09/21/11 09:32:33 -0400 pts/2
account4 0 0 08/29/12 13:36:06 -0400 server2
account3 0 0 02/28/13 16:37:43 -0500 207.180.29.
account2 0 0 03/13/13 09:05:40 -0400 /dev/pts/4
admin 2 0 03/13/13 10:50:43 -0400 /dev/pts/5
account1 0 0 12/30/11 13:49:02 -0500 static-155-
root@server:~# faillog -r admin
root@server:~# faillog
Login Failures Maximum Latest On
admin2 0 0 09/21/11 09:32:33 -0400 pts/2
account4 0 0 08/29/12 13:36:06 -0400 server2
account3 0 0 02/28/13 16:37:43 -0500 207.180.29.
account2 0 0 03/13/13 09:05:40 -0400 /dev/pts/4
admin 0 0 03/13/13 10:50:43 -0400 /dev/pts/5
account1 0 0 12/30/11 13:49:02 -0500 static-155-
root@server:~# faillog --help
Usage: faillog [options]
Options:
-a, --all display faillog records for all users
-h, --help display this help message and exit
-l, --lock-time SEC after failed login lock accout to SEC seconds
-m, --maximum MAX set maximum failed login counters to MAX
-r, --reset reset the counters of login failures
-t, --time DAYS display faillog records more recent than DAYS
-u, --user LOGIN display faillog record or maintains failure
counters and limits (if used with -r, -m or -l
options) only for user with LOGIN
This looks to be specifically enabled in common-auth
root@server:/etc/pam.d# cat common-auth # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) auth required pam_tally.so deny=4 per_user 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) # end of pam-auth-update config
This being the key line:
auth required pam_tally.so deny=4 per_user
Default for common-auth in Debian (and presumably ubuntu as well):
/etc/pam.d/common-auth: auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so
So – pam_tally would have been explicitly added to common-auth and, looking through the ticket history, I find that, yes, this was added several years ago. And to some extent forgotten. Until it came back to stop logins to a server. The change was committed by someone no longer present.
Even if there is a legal requirement making a discussion of this moot, I don’t think this is a good idea. It doesn’t reset after time. It is set to an absurdly low count. Better would be an automatic blacklist of an IP address after failed ssh login attempts. The way this is currently configured, failing to login to sudo also logs failed counts, and can lock the user out of not just sudo, but the entire system. I’ve found potential configurations which don’t include sudo like this. Just saying…
—doug