Understanding PAM authentication

PAM (Pluggable Authentication Modules) is the framework that handles authentication on Linux. When you log in, type a password for sudo, or unlock your screen, PAM is doing the work. Understanding PAM lets you customize authentication policies.

How PAM works

PAM separates authentication into four management groups:

• auth — verify the user’s identity (password, token, etc.)
• account — check if the account is allowed access (expired, locked, time restrictions)
• password — handle password changes
• session — set up the user session (mount home dir, set limits, log access)

Each group has a stack of modules. When a service needs authentication, PAM runs through the relevant stack.

Configuration files

PAM configs are in /etc/pam.d/. Each service has its own file:

• /etc/pam.d/login — console login
• /etc/pam.d/sshd — SSH authentication
• /etc/pam.d/sudo — sudo authentication
• /etc/pam.d/common-auth — shared auth rules (included by others)

A typical config line:

auth    required    pam_unix.so

Fields: module-type, control-flag, module-path, arguments.

Control flags

• required — must succeed; continue checking other modules but ultimately fail if this fails
• requisite — must succeed; fail immediately if this fails
• sufficient — if this succeeds and no prior required module failed, authentication succeeds
• optional — success or failure doesn’t matter unless it’s the only module in the stack
• include — include another config file

The difference between required and requisite: both cause failure if they fail, but required continues checking other modules (to not reveal which module failed), while requisite stops immediately.

Common modules

pam_unix.so — traditional password authentication against /etc/shadow

auth required pam_unix.so

pam_permit.so — always succeeds. Used when you want to allow something without checking.

pam_deny.so — always fails. Used as a default deny at the end of a stack.

pam_limits.so — sets resource limits from /etc/security/limits.conf

pam_env.so — sets environment variables from /etc/security/pam_env.conf

Password policies

Set minimum password length and complexity in /etc/pam.d/common-password:

password requisite pam_pwquality.so retry=3 minlen=12 difok=3

• minlen — minimum password length
• difok — number of characters that must differ from the old password
• retry — number of attempts before giving up

Lock an account after failed attempts in /etc/pam.d/common-auth:

auth required pam_tally2.so deny=5 onerr=fail unlock_time=900

This locks the account for 15 minutes after 5 failed attempts. Check and reset tallies:

sudo pam_tally2 --user username
sudo pam_tally2 --user username --reset

Restricting access by time

Limit login times in /etc/security/access.conf:

# Allow logins only during business hours
+ : admin : ALL
+ : ALL : LOCAL
- : ALL : ALL

Enable this in the PAM config:

account required pam_access.so
## Restricting SSH to specific users

In `/etc/pam.d/sshd`, add:

account required pam_access.so

Then in `/etc/security/access.conf`:

• : deploy : ALL
• : admin : ALL

• : ALL : ALL

## Common mistakes

**Editing the wrong PAM file.** Each service has its own config. Editing `/etc/pam.d/login` doesn't affect SSH.

**Locking yourself out.** Always keep a root session open when editing PAM configs. A bad PAM config can lock everyone out.

**Forgetting to include common-* files.** Many service configs include `@include common-auth`. If you remove that include, standard password authentication breaks.

**PAM ordering matters.** Modules are evaluated in order. A `sufficient` module before a `required` module can short-circuit the check.

## Remarks

PAM is powerful but the configuration is order-sensitive and mistakes can lock you out. The safe approach: always keep a root session open when testing, use `required` for security-critical checks, and test with a non-critical account first. Most systems ship with sensible defaults — only change what you need to.