Linux Commands Examples

A great documentation place for Linux commands


The login counter (tallying) module

see also : faillog

Synopsis [file=/path/to/counter] [onerr=[fail|succeed]] [magic_root] [even_deny_root_account] [deny=n] [lock_time=n] [unlock_time=n] [per_user] [no_lock_time] [no_reset] [audit] [silent] [no_log_info]

pam_tally [--file /path/to/counter] [--user username] [--reset[=n]] [--quiet]

add an example, a script, a trick and tips

: email address (won't be displayed)
: name

Step 2

Thanks for this example ! - It will be moderated and published shortly.

Feel free to post other examples
Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!



Add the following line to /etc/pam.d/login to lock the account after too many failed logins. The number of allowed fails is specified by /var/log/faillog and needs to be set with pam_tally or faillog(8) before.

auth required
auth required per_user
auth required
auth required
auth required
account required
password required
session required
session required
session required nowtmp
session optional standard

$(ROMFSINST) build/libpamc/.libs/ /lib/
$(ROMFSINST) build/modules/pam_tally/.libs/pam_tally /bin/pam_tally


This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally has several limitations, which are solved with pam_tally2. For this reason pam_tally is deprecated and will be removed in a future release.

pam_tally comes in two parts: and pam_tally. The former is the PAM module and the latter, a stand-alone program. pam_tally is an (optional) application which can be used to interrogate and manipulate the counter file. It can display users' counts, set individual counts, or clear all counts. Setting artificially high counts may be useful for blocking users without changing their passwords. For example, one might find it useful to clear all counts every midnight from a cron job. The faillog(8) command can be used instead of pam_tally to to maintain the counter file.

Normally, failed attempts to access root will not cause the root account to become blocked, to prevent denial-of-service: if your users aren't given shell accounts and root may only login via su or at the machine console (not telnet/rsh, etc), this is safe.



This can be used for auth and account module types.


If something weird happens (like unable to open the file), return with PAM_SUCCESS if onerr=succeed is given, else with the corresponding PAM error code.


File where to keep counts. Default is /var/log/faillog.


Will log the user name into the system log if the user is not found.


Don't print informative messages.


Don't log informative messages via syslog(3).


Authentication phase first checks if user should be denied access and if not it increments attempted login counter. Then on call to pam_setcred(3) it resets the attempts counter.


Deny access if tally for this user exceeds n.


Always deny for n seconds after failed attempt.


Allow access after n seconds after failed attempt. If this option is used the user will be locked out for the specified amount of time after he exceeded his maximum allowed attempts. Otherwise the account is locked until the lock is removed by a manual intervention of the system administrator.


If the module is invoked by a user with uid=0 the counter is not incremented. The sysadmin should use this for user launched services, like su, otherwise this argument should be omitted.


Do not use the .fail_locktime field in /var/log/faillog for this user.


Don't reset count on successful entry, only decrement.


Root account can become unavailable.


If /var/log/faillog contains a non-zero .fail_max/.fail_locktime field for this user then use it instead of deny=n/ lock_time=n parameter.


Don't use .fail_locktime filed in /var/log/faillog for this user.


Account phase resets attempts counter if the user is not magic root. This phase can be used optionally for services which don't call pam_setcred(3) correctly or if the reset should be done regardless of the failure of the account phase of other modules.


If the module is invoked by a user with uid=0 the counter is not incremented. The sysadmin should use this for user launched services, like su, otherwise this argument should be omitted.


Don't reset count on successful entry, only decrement.



failure logging file

module types provided

The auth and account module types are provided.

return values


A invalid option was given, the module was not able to retrieve the user name, no valid counter file was found, or too many failed logins.


Everything was successful.


User not known.

see also

faillog , pam.conf, pam.d, pam


pam_tally was written by Tim Baverstock and Tomas Mraz.

How can this site be more helpful to YOU ?

give  feedback