• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer navigation

The Geek Diary

  • OS
    • Linux
    • CentOS/RHEL
    • VCS
  • Interview Questions
  • Database
    • MariaDB
  • DevOps
    • Docker
    • Shell Scripting
  • Big Data
    • Hadoop
    • Cloudera
    • Hortonworks HDP

CentOS / RHEL 6 : Lock User Account After N Number of Incorrect Login Attempts

by admin

Often a requirement in a secure environment is to lockdown users after they enter a wrong password for a specified number of times. This makes the system protect againt attacks likes password dictionary attacks. The post describes how to lock an account after N incorrect login attempts using pam.d files.

Lock user after N incorrect logins

1. First, take a backup of the file /etc/pam.d/password-auth and /etc/pam.d/system-auth. Then add the following lines to the file.

auth        required        pam_tally2.so        file=/var/log/tallylog deny=N even_deny_root unlock_time=1200 
account     required        pam_tally2.so

Here,
file=/var/log/tallylog – Failed login attempts are logged here.
deny – allows us to set the value N (no. of attempts) after which the user account should be locked.
even_deny_root – makes sure that the same rule applies to root user as well. To exclude root user from this policy, simply remove the parameter from the line. [Optional]
unlock_time – is the time for which the account should stay locked [Optional]

The sample /etc/pam.d/system-auth will look as follows:

# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

2. Edit the file /etc/ssh/sshd_config to increase the MaxAuthTries value to a higher value than the above number.

# vi /etc/ssh/sshd_config
MaxAuthTries 10

3. Save the file after checking the ChallengeResponseAuthentication no is already set in the file.

# vi /etc/ssh/sshd_config
ChallengeResponseAuthentication no

4. Restart the sshd service.

# service sshd restart

Reset the lock

1. faillog command reports the number of failed login attempts for a specific user:

# faillog -u [username]

2. If pam_tally2.so is being used, pam_tally2 command can be used to check number of failed login attempts for a specific user:

# pam_tally2  -u [username]

3. To reset the lock for a user, pam_tally2 command can be used:

#  pam_tally2 --user=[username]  --reset

Filed Under: Linux

Some more articles you might also be interested in …

  1. git archive: Create an archive of files from a named tree
  2. CentOS / RHEL : How to rotate /var/log/wtmp and /var/log/btmp file using logrotate
  3. cpufreq-aperf Command Examples in Linux
  4. tail command examples in UNIX/Linux
  5. debuild Command Examples in Linux
  6. Insert into search_tmp… queries never ends
  7. dart: The tool for managing Dart projects
  8. nmcli device Command Examples in Linux
  9. lslogins: command not found
  10. CentOS / RHEL : How to change the UUID of the filesystem

You May Also Like

Primary Sidebar

Recent Posts

  • gixy Command Examples
  • gitsome Command Examples
  • gitmoji Command Examples
  • gitlint Command Examples

© 2023 · The Geek Diary

  • Archives
  • Contact Us
  • Copyright