PAM

What PAM is and how it works

PAM (Pluggable Authentication Modules) is a set of libraries that handle authentication for system services. The pam(8) manual says it gives privilege-granting programs such as login and su a standard interface for common authentication tasks, and that the nature of the authentication is dynamically configurable. A program asks PAM for a decision, and PAM runs the modules the administrator listed for that service.

Modules belong to four management groups:

• auth authenticates the user and sets up credentials.
• account checks account status, for example an expired password or whether the user may use the service.
• password updates authentication tokens.
• session does setup before a service starts and cleanup after it ends, such as audit logging.

Configuration lives in per-service files in /etc/pam.d, where the lowercase file name is the service name (sshd, su, login). If that directory exists, /etc/pam.conf is ignored, and files in it override same-named vendor defaults in /usr/lib/pam.d.

Reading a PAM rule and testing a change safely

Each line in a service file has four fields: type, control, module path and module arguments. Modules for one type run in the order listed, and the control field decides what a result means, according to the pam.d(5) manual:

• required: a failure is reported only after the rest of the stack has run.
• requisite: a failure returns immediately.
• sufficient: a success returns immediately if no earlier required module failed, and a failure is ignored.
• optional: matters only if it is the only module of that type.

The pam_wheel manual gives this example, which lets root in, requires wheel membership to become root, then checks the password:

auth sufficient pam_rootok.so
auth required   pam_wheel.so
auth required   pam_unix.so

To test safely, keep a root session open, change one file, and try a new login from a second terminal before closing anything. A leading - on the type only silences the log entry when a module is missing.

How sshd uses PAM and where lockouts come from

The sshd_config manual says UsePAM yes enables PAM for password and keyboard-interactive authentication and also applies PAM account and session processing to all authentication types. So a failing account module can block a user even when the SSH key is valid. The manual's default is no, though many distributions ship yes, and it warns to disable either PasswordAuthentication or KbdInteractiveAuthentication, since they usually serve the same role.

Common pitfalls:

• A malformed line generally makes authentication fail.
• requisite can reveal that an account exists.
• pam_unix refuses blank passwords unless nullok is given.
• pam_nologin blocks non-root logins while /etc/nologin exists.
• pam_faillock locks after 3 failures within 900 seconds for 600 seconds by default, never locks root unless even_deny_root is set, and stores counters in /var/run/faillock, which may not survive a reboot.

Where PAM fits in hardening

PAM is where login policy is enforced after sshd has done its own checks, so it is a hardening layer and a lockout risk at once. Use it for specific jobs: pam_wheel to limit who can su, pam_faillock to slow guessing, and a time-based code module for a second factor. The pam_faillock manual shows these settings and the commands to inspect and clear a lock:

# /etc/security/faillock.conf
deny=4
unlock_time=1200
silent

faillock --user alice
faillock --user alice --reset

Remember that lockouts can be triggered by an attacker against a real administrator, so pair them with network-level controls from the SSH brute force guide and fail2ban. Follow the rollout order in the SSH two-factor guide, keep a provider console available, and read how to recover from an SSH lockout before you need it.

Related terms: sshd_config, Two-factor authentication, sudo, TOTP, Fail2ban.