PAM, short for Pluggable Authentication Modules, is the framework through which Linux programs delegate authentication, account checks, password changes and session setup to a configurable stack of shared-library modules. In Linux security, PAM separates the question of *how* a user is verified from the applications that need verification, so login, sshd, sudo and graphical display managers all follow policies defined in one place.
An application that supports PAM never reads password files itself. It calls the libpam API, and the administrator decides in plain text configuration files which modules run, in what order and with what consequences. Changing from local passwords to a directory service or adding a second factor is therefore a configuration change, not a code change.
How PAM processes an authentication request
Each PAM-aware program has a service name, such as sshd or sudo, and a matching file in /etc/pam.d/. When the program calls functions such as pam_authenticate() or pam_open_session(), libpam reads that file, loads the listed modules from /lib/security or /usr/lib64/security and runs them in order, combining their results according to control flags.
PAM divides the work into four management groups. A single login typically passes through all four: the user proves identity, the account is checked for validity, a session is prepared, and the password group is invoked only when the user changes credentials.
| Group | Question answered | Example modules |
|---|---|---|
| auth | Is the user who they claim to be | pam_unix, pam_sss, pam_faillock |
| account | May this account log in now | pam_unix, pam_access, pam_time |
| password | Is the new password acceptable | pam_pwquality, pam_unix |
| session | What must be set up or torn down | pam_limits, pam_systemd, pam_mkhomedir |
Modules communicate with the user through a conversation function supplied by the application. This is why the same module can prompt for a password in a terminal, in an SSH keyboard-interactive exchange or in a graphical dialog without knowing which one it is using.
Control flags and stack evaluation
Every line in a PAM file has the form type, control, module path, arguments. The control flag determines how a module’s success or failure affects the final result. Misunderstanding these flags is the most common cause of PAM misconfiguration, because the stack keeps running after some failures and stops after others.
| Flag | On success | On failure |
|---|---|---|
| required | Continue the stack | Overall failure, but continue the stack |
| requisite | Continue the stack | Fail and stop immediately |
| sufficient | Stop with success if nothing required failed | Ignore and continue |
| optional | Matters only if it is the only module | Ignore and continue |
| include | Pull in another file’s lines | Same as included lines |
The behavior of required is deliberate: by continuing after a failure, PAM avoids telling an attacker which step rejected the attempt. Modern Linux-PAM also supports a bracketed syntax such as [success=1 default=ignore], which maps individual return codes to actions and can skip a number of following lines. Distribution tools generate many of these complex lines, so editing them by hand requires care.
PAM compared with other Linux security layers
PAM governs who gets in and how a session starts. It does not limit what a process can do after login, which is the job of mandatory access control systems such as SELinux and AppArmor, and of kernel mechanisms such as seccomp and Linux capabilities.
| Mechanism | Layer | Main purpose |
|---|---|---|
| PAM | User space, at login and privilege change | Authentication and session policy |
| NSS | User space, name lookups | Find users and groups in files or directories |
| SELinux | Kernel, mandatory access control | Label-based confinement of processes |
| AppArmor | Kernel, mandatory access control | Path-based program profiles |
| Linux capabilities | Kernel, privilege split | Grant parts of root power |
PAM and NSS are frequently confused. NSS, configured in /etc/nsswitch.conf, answers *where user records come from*, while PAM answers *how to verify them*. Integrating a host with a central directory usually requires both, and tools such as SSSD provide a module for each.
Typical PAM configurations
Distributions manage shared PAM stacks so that administrators rarely edit service files directly. Debian and Ubuntu use pam-auth-update with files such as common-auth, while Fedora and RHEL use authselect with system-auth and password-auth. Hand edits to generated files may be overwritten by these tools.
| Module | Use | Typical setting |
|---|---|---|
| pam_faillock | Lock accounts after failed logins | deny=5 unlock_time=900 |
| pam_pwquality | Enforce password strength | minlen=12 with character class rules |
| pam_limits | Apply ulimit values per session | Read from /etc/security/limits.conf |
| pam_google_authenticator or similar | Time-based one-time codes | Added to the auth group |
| pam_access | Allow or deny by user and origin | Rules in /etc/security/access.conf |
Risks and common mistakes
Because PAM sits on the login path of every service, a single wrong line can lock out all users, including root, or worse, admit anyone. The safest practice is to keep a root shell open while testing changes in a second session and to validate each service, including SSH, sudo and the console.
- Placing sufficient before required checks can let a weak module grant access before stricter checks run.
- Using optional for a security module means its failure is ignored entirely.
- Forgetting UsePAM yes in sshd disables the account and session stack for SSH logins.
- Editing generated files directly leads to silent reversion at the next tool run.
- Installing untrusted modules is dangerous, because a PAM module runs inside privileged processes and can capture passwords.
The idea in brief
PAM is like the reception desk procedure of a large company. Every department that needs to check visitors, whether the front door, the server room or the payroll office, follows the same procedure book instead of inventing its own. The procedure might say: check the badge, then check whether the visit is allowed today, then hand out a temporary pass.
When the company decides to add a fingerprint check, it updates the procedure book once and every desk follows the new rule. In the same way, PAM lets a Linux administrator change how people log in across many programs without changing any of those programs.
A practical scenario
A university department manages 40 Linux servers that researchers reach over SSH. After a series of password-guessing attempts, the administrators decide to add account lockout and one-time codes. On a test server, they add pam_faillock with deny=5 and unlock_time=900, then insert a one-time-code module into the auth stack of /etc/pam.d/sshd while keeping a root session open.
They test password logins, key-based logins, sudo and console access, and discover that sudo needs no change because it uses a different service file. The configuration is then rolled out through configuration management. The outcome is that repeated guessing now triggers a 15-minute lockout, and a stolen password alone no longer opens a shell.