User Authentication with PAM

Programs which give users access to privileges of any sort need to be able to authenticate the users. When you log into a system, you provide your name and password, and the login process uses those to authenticate the login -- to verify that you are who you say you are. Forms of authentication other than passwords are possible, and it is possible for the passwords to be stored in different ways.

PAM, which stands for Pluggable Authentication Modules, is a way of allowing the system administrator to set authentication policy without having to recompile authentication programs. With PAM, you control how the modules are plugged into the programs by editing a configuration file.

Most Red Hat Linux users will never need to touch this configuration file. When you use RPM to install programs that require authentication, they automatically make the changes that are needed to do normal password authentication. However, you may want to customize your configuration, in which case you must understand the configuration file.

PAM Modules

There are four types of modules defined by the PAM standard.

These modules may be stacked, so that multiple modules are used. For instance, rlogin normally makes use of at least two authentication methods: if rhosts authentication succeeds, it is sufficient to allow the connection; if it fails, then standard password authentication is done.

New modules can be added at any time, and PAM-aware applications can then be made to use them. For instance, if you have a one-time-password calculator system, and you can write a module to support it (documentation on writing modules is included with the system in /usr/doc/pam*), PAM-aware programs can use the new module and work with the new one-time-password calculators without being recompiled or otherwise modified in any way.


Each program using PAM defines its own "service" name. The login program defines the service type login, ftpd defines the service type ftp, and so on. In general, the service type is the name of the program used to access the service, not (if there is a difference) the program used to provide the service.

The Configuration Files

The directory /etc/pam.d is used to configure all PAM applications. (This used to be /etc/pam.conf in earlier PAM versions; while the pam.conf file is still read if no /etc/pam.d/ entry is found, its use is deprecated.) Each application (really, each service) has its own file. A file looks like this:

auth      required  /lib/security/
auth      required  /lib/security/ shadow nullok
auth      required  /lib/security/
account   required  /lib/security/
password  required  /lib/security/
password  required  /lib/security/ shadow nullok use_authtok
session   required  /lib/security/

The first line is a comment. (Any line that starts with a # character is a comment.) Lines two through four stack up three modules to use for login authorization. Line two makes sure that if the user is trying to log in as root, the tty on which they are logging in is listed in the /etc/securetty file if that file exists. Line three causes the user to be asked for a password and the password checked. Line four checks to see if the file /etc/nologin exists, and if it does, displays the contents of the file, and if the user is not root, does not let him or her log in.

Note that all three modules are checked, even if the first module fails. This is a security decision -- it is designed to prevent the user from knowing why their authentication was disallowed, because knowing why it was disallowed might allow them to break the authentication more easily. You can change this behavior by changing required to requisite; if any requisite module returns failure, PAM fails immediately without calling any other modules.

The fifth line causes any necessary accounting to be done. For example, if shadow passwords have been enabled, the module will check to see if the account has expired, or if the user has not changed his or her password and the grace period for changing the password has expired.

The sixth line subjects a newly changed password to a series of tests to ensure that it cannot, for example, be easily determined by a dictionary-based password cracking program.

The seventh line (which may be wrapped) specifies that if the login program changes the user's password, it should use the module to do so. (It will do so only if an auth module has determined that the password needs to be changed --- for example, if a shadow password has expired.)

The eighth and final line specifies that the module should be used to manage the session. Currently, that module doesn't do anything; it could be replaced (or supplemented by stacking) by any necessary module.

Note that the order of the lines within each file matters. While it doesn't really matter much in which order required modules are called, there are other control flags available. While optional is rarely used, and never used by default on a Red Hat Linux system, sufficient and requisite cause order to become important.

Let's look at the auth configuration for rlogin:

auth  required    /lib/security/
auth  sufficient  /lib/security/
auth  required    /lib/security/ shadow nullok
auth  required    /lib/security/

That looks almost like the login entry, but there's an extra line specifying an extra module, and the modules are specified in a different order.

First, keeps root logins from happening on insecure terminals. This effectively disallows all root rlogin attempts. If you wish to allow them (in which case we recommend that you not be Internet-connected or be behind a good firewall), you can simply remove that line.

Second, if authenticates the user, PAM immediately returns success to rlogin without any password checking. If fails to authenticate the user, that failed authentication is ignored.

Third, if has failed to authenticate the user, the module performs normal password authentication.

Finally checks /etc/nologin, as specified above.

Note that if you do not want to prompt for a password if the securetty check fails, you can change the module from required to requisite.

Shadow Passwords

The module will automatically detect that you are using shadow passwords and make all necessary adjustments. Please refer to the section called Shadow Utilities for more information.

Rexec and PAM

For security reasons, rexec is not enabled in Red Hat Linux 6.2. Should you wish to enable it, you will need to comment out one line in the file /etc/pam.d/rexec. Here is a sample of the file (note that your file may differ slightly):

auth       required     /lib/security/ shadow nullok
auth       required     /lib/security/
account    required     /lib/security/

To enable rexec, the line referring to the module must be commented out:

auth       required     /lib/security/ shadow nullok
#auth      required     /lib/security/
account    required     /lib/security/

After this file is modified, rexec will be enabled.

NotePlease Note

If your /etc/pam.d/rexec file contains a line referring to the module, you will not be able to rexec as root. To do so, you must also comment out the line referring to the module.

More Information

This is just an introduction to PAM. More information is included in the /usr/doc/pam* directory, including a System Administrators' Guide, a Module Writers' Manual, an Application Developers' Manual, and the PAM standard, DCE-RFC 86.0.