Learn How Linux PAM Architecture Works

Linux PAM (Pluggable Authentication Modules) is one of the most important parts of a Linux system. It controls how users are authenticated when they log in through SSH, use sudo, switch users with su, or access other PAM-enabled services. A small mistake in a PAM configuration file can prevent users from logging in, so understanding how it works is essential for every Linux administrator.

In this guide, you'll learn what PAM is, how the PAM architecture works, how to read files in /etc/pam.d/, understand control flags and modules, and safely configure authentication without locking yourself out of your system.

Examples

PAM stands for Pluggable Authentication Modules. It is the layer that decides whether you actually get in when you type a password, tap a security key, or run sudo, and it sits between the application and the actual authentication logic.

Before PAM existed, every program that needed to check a password had its own hardcoded way of doing it. Login had its own code, FTP had its own code, and su had its own code. If you wanted to add fingerprint login or lock accounts after failed attempts, you had to patch every single program separately.

PAM changed that by moving authentication logic into small, swappable modules that any PAM-aware program can call. Think of it like a bouncer at a club who checks a list of rules handed to him by management. Change the rules, and the bouncer behaves differently, without anyone rebuilding the club itself.

Every time you type your password for sudo, unlock your screen, or SSH into a box, PAM is quietly running through a stack of these modules behind the scenes to decide yes or no.

Every line inside a file in /etc/pam.d/ follows a standardized structure containing three mandatory fields and an optional fourth field for arguments. Once you can read one line, you can read all of them.

The first field is the module type, meaning whether this line handles authentication, account checks, password changes, or session setup. The second field is the control flag, which decides what happens if the module succeeds or fails. The third field is the actual module doing the work, and anything after that is arguments passed to it. That fourth field is optional though, most include and system-auth lines skip it entirely because the module needs nothing extra to do its job.

The control flag is the part people get wrong most often, because it looks like a minor detail but it decides whether one failed module locks a user out or gets quietly ignored.

Start by seeing what's already there before you change anything.

Before referencing a module in a config file, confirm it exists on this machine.

Debian and Ubuntu store these under /usr/lib/x86_64-linux-gnu/security/, while RHEL, Rocky Linux, AlmaLinux, and Fedora use /usr/lib64/security/. The wildcard above matches either one, so the same command works everywhere.

The sudo file is short, which makes it a good first file for actually reading the four-field syntax in context.

Rejecting weak passwords at the OS level instead of trusting people to pick good ones.

A common hardening step so random local users can't attempt to become root.

Uncommenting that single line means only accounts in the wheel group can use su at all, everyone else gets denied before a password prompt even appears.

This is the kind of protection people assume exists by default. It doesn't, you have to add it.

That output is coming from pam_faillock, which tracks failed attempts per account. Pair it with a line in system-auth to actually lock accounts after a set number of tries.

A real-world scenario most teams run into once they get serious about server access. This stacks a code prompt on top of the normal password or key check.

This alone won't do anything until KbdInteractiveAuthentication yes is also set in sshd_config. That's the current directive name on OpenSSH 8.7 and newer, which ships with Ubuntu 22.04+, RHEL 9+, and Debian 12. On older OpenSSH versions you'll still use ChallengeResponseAuthentication yes instead, since the newer name didn't exist yet. Check this alongside your SSH server hardening steps.

Useful on shared or contractor-facing systems where access outside working hours shouldn't be possible at all.

That single rule tells pam_time to only allow the contractor account to log in on weekdays between 8am and 6pm, and reject it entirely outside that window.

An enterprise-grade example. On shared build servers, one runaway process can starve everyone else, and PAM is where you stop it before it starts.

That line is what makes the values in /etc/security/limits.conf actually take effect for every session, things like max open files or max processes per user.

When something breaks, PAM tells you exactly why, if you know where to look.

This is close to what actually happened to me. Someone moves a requisite line above the module that actually establishes identity, incorrectly assuming order doesn't matter. It matters more than anything else in the file.

Keep a root session open in a second terminal any time you touch a live pam.d file. If you get locked out, that second session is the only way back in without console access.

Without PAM, every login decision on your system would be scattered across dozens of programs with no shared rulebook. One stack, one set of files, one place to enforce policy across SSH, sudo, login, and cron all at once, that consistency is the entire point.

Once you understand the stack, security work stops feeling like guesswork and starts feeling like editing a short list of rules you actually control. Compliance checklists that ask for account lockout, MFA, or session logging usually come down to a handful of lines in /etc/pam.d/, not a separate product. The official reference for every module and control flag lives in the pam.conf man page, and it is worth bookmarking.