From Scapegoat to Security Pro: A Linux User Management Pitfalls Guide

1. Core User Management Files

/etc/passwd stores a roster of all system users. Each line follows the format username:password_placeholder:UID:GID:comment:home:shell. Example: devops:x:1000:1000:Ops Engineer:/home/devops:/bin/bash. The password placeholder x indicates the real password resides in /etc/shadow , which only root can read.

UID 0 is the super‑user; 1‑999 are system accounts; 1000+ are regular users. Changing a regular UID to 0 effectively grants root privileges—a major pitfall.

/etc/shadow holds encrypted passwords. Its fields are

username:encrypted_password:last_change:min_days:max_days:warn_days:expire_days:reserved

. Password hashes starting with $6$ use SHA‑512 with a salt. Special markers: * or ! – account cannot log in !! – password never set

Empty field – empty password (highly risky)

/etc/group defines group memberships: group_name:password:GID:user_list. A user can belong to multiple groups, separated by commas; the id command displays a user’s “friend circle.”p>

2. User CRUD Operations

2.1 Create Users – useradd

Standard command:

useradd -m -s /bin/bash -G wheel devops

-m

– create home directory -s /bin/bash – set login shell -G wheel – add to wheel (sudo) group

After creation, set a password:

passwd devops

2.2 Modify Users – usermod

Change shell, home, groups, or lock status:

usermod -s /bin/zsh devops

usermod -d /new/home/devops -m devops

usermod -aG docker devops

usermod -L devops   # lock

usermod -U devops   # unlock

Warning: Modifying a currently logged‑in user may fail; log the user out first.

2.3 Delete Users – userdel

Remove a user and optionally its home directory: userdel -r devops # -r deletes home and mail Lesson: In production, avoid -r without confirming no running processes, open files, or cron jobs.

2.4 Query Users – id

Show a user’s UID, GID, and groups: id devops Output example: uid=1000(devops) gid=1000(devops) groups=1000(devops),10(wheel),996(docker)

3. What Happens When a User Logs In?

3.1 Login Shell vs. Non‑Login Shell

Login shells (SSH, telnet, local login) read a series of configuration files; non‑login shells (new terminal windows, scripts) read only a subset.

3.2 Configuration File Load Order

Login shell reads the first existing file among:

/etc/profile → ~/.bash_profile → ~/.bash_login → ~/.profile

All shells read ~/.bashrc . Pitfall: Do not place environment variables in ~/.bashrc because login shells skip it; use /etc/profile for system‑wide variables and ~/.bash_profile for user‑level variables.

3.3 Logout Execution

When a user exits, ~/.bash_logout runs, allowing cleanup actions such as logging the logout time.

4. Password Security: Policies and Management

4.1 Complexity Policy – /etc/security/pwquality.conf

# /etc/security/pwquality.conf
minlen = 12      # minimum length
dcredit = -1    # at least one digit
ucredit = -1    # at least one uppercase letter
lcredit = -1    # at least one lowercase letter
ocredit = -1    # at least one special character

Negative values mean “at least” that many characters.

4.2 Expiration – chage

# View password status
chage -l devops
# Force password change after 90 days, warn 7 days before
chage -M 90 -W 7 devops
# Require change on first login
chage -d 0 devops

4.3 Password History – /etc/login.defs

PASS_HISTORY_SIZE 5  # last 5 passwords cannot be reused

5. Login Auditing: Who Logged In and When?

5.1 last – Recent Logins

last -10          # last 10 entries
last -a           # show hostnames
last -F           # full timestamps
last devops       # filter by user

5.2 lastlog – Last Login of All Users

lastlog
# Example line:
# root       pts/1   192.168.1.1   Mon May 10 08:00:00 +0800 2026

5.3 lastb – Failed Login Attempts

lastb               # requires root
lastb -10          # recent 10 failures
lastb | awk '{print $1}' | sort | uniq -c | sort -rn   # count brute‑force targets

Alert: A large lastb output indicates ongoing SSH brute‑force attacks.

5.4 /var/log/secure – Detailed SSH Logs

# Successful logins
grep "Accepted" /var/log/secure
# Failed logins
grep "Failed" /var/log/secure
# All records for a specific IP
grep "192.168.1.100" /var/log/secure

6. Defending Against Brute‑Force Attacks

6.1 Disable Password Login, Use SSH Keys

# In /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

6.2 Change the Default SSH Port

# /etc/ssh/sshd_config
Port 22222   # non‑standard port avoids ~90% of scans

6.3 Fail2Ban – Automatic IP Banning

# Install
yum install fail2ban   # CentOS
apt install fail2ban   # Ubuntu
# Configuration snippet
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
bantime = 3600   # 1 hour
findtime = 600   # 10‑minute window

Configuration means three failed attempts within ten minutes trigger a one‑hour ban.

6.4 PAM Module – pam_tally2

# Add to /etc/pam.d/sshd
auth required pam_tally2.so deny=3 unlock_time=600 even_deny_root root_unlock_time=300
# Check failure count
pam_tally2 --user devops
# Reset (unlock) user
pam_tally2 --user devops --reset

6.5 Disallow Direct Root SSH Login

# /etc/ssh/sshd_config
PermitRootLogin no

Create a regular user, grant sudo, and log in with that account.

6.6 Cloud Firewalls / Security Groups

For cloud servers, configure security groups to expose only necessary ports, blocking the majority of attacks.

7. Checklist Summary

When creating users: use useradd -m, add to wheel or sudo group, set password immediately.

Password security: minimum 12 characters with mixed case, digits, and symbols; enforce 90‑day rotation; monitor with chage.

Login security: disable root SSH login, change default port, prefer key‑based authentication, deploy Fail2Ban or pam_tally2.

Log auditing: daily review lastb for anomalies, regularly inspect /var/log/secure.

Effective Linux user management is a foundational operation for system administrators and the first line of defense against most security incidents.