- PAM provides a way to develop programs that are independent of authentication scheme. These programs need "authentication modules" to be attached to them at run-time in order to work. Which authentication module is to be attached is dependent upon the local system setup and is at the discretion of the local system administrator.
This article explains the Arch Linux base set-up defaults for PAM to authenticate local and remote users. Applying changes to the defaults is subject of crosslinked specialized per topic articles.
The meta package and, thereby, normally installed on an Arch system. The PAM modules are installed into
The repositories contain a number of optional PAM packages, the #Configuration How-Tos show examples.
A number of
/etc paths are relevant for PAM; execute
pacman --query --list pam | grep /etc to see the default configuration files created. They relate to either #Security parameters for the modules, or the #PAM base-stack configuration.
/etc/security contains system-specific configuration for variables the authentication methods offer. The base install populates it with default upstream configuration files.
Note Arch Linux does not provide distribution-specific configuration for these files. For example, the
/etc/security/pwquality.conf file can be used to define system-wide defaults for password quality. Yet, to enable it, the
pam_pwquality.so module has to be added to the #PAM base-stack of modules, which is not the case per default.
See #Security parameter configuration for some of the possibilities.
/etc/pam.d/ path is exclusive for the PAM configuration to link the applications to the individual systems' authentication schemes. During installation of the system base, it is populated by:
- the package, which contains the base-stack of Arch Linux specific PAM configuration to be used by applications, and
- other base packages. For example, Users and groups). adds configuration for the central login and other programs, the package adds the Arch Linux defaults to secure and modify the user database (see
The different configuration files of the base installation link together and are stacked during runtime. For example, on a local user logon, the login application sources the
system-local-login policy, which in turn sources others:
login -> system-local-login -> system-login -> system-auth
For a different application, a different path may apply. For example,
sshd PAM policy:
sshd -> system-remote-login -> system-login -> system-auth
Consequently, the choice of the configuration file in the stack matters. For the above example, a special authentication method could be required for
sshd only, or all remote logins by changing
system-remote-login; both changes would not affect local logins. Applying the change to
system-auth instead would affect local and remote logins.
Like the example of
sshd, any pam-aware application is required to install its policy to
/etc/pam.d in order to integrate and rely on the PAM stack appropriately. If an application fails to do it, the
/etc/pam.d/other default policy to deny and log a warning is applied.
$ ldd /usr/bin/login | grep pam
libpam.so.0 => /usr/lib/libpam.so.0 (0x000003d8c32d6000) libpam_misc.so.0 => /usr/lib/libpam_misc.so.0 (0x000003d8c30d2000)the login application is pam-aware and must, therefore, have a policy.
The PAM package manual pagesand describe the standardized content of the configuration files. In particular, they explain the four PAM groups: account, authentication, password, and session management, as well as the control values that may be used to configure stacking and behavior of the modules.
Additionally, extensive documentation is installed to
/usr/share/doc/Linux-PAM/index.html which, among various guides, contains browsable man pages for each of the standard modules.
Two short examples to illustrate the above warning.
First, we take the following two lines:
auth required pam_unix.so try_first_pass nullok auth optional pam_permit.so
- The authentication component
pam_unix.soperforms the task of checking the users credentials (password). The default action of this module is to not permit the user access to a service if their official password is blank.
- the latter being what
pam_permit.so is used for. Simply swapping the control values
optional for both lines is enough to disable password authentication, i.e. any user may logon without providing a password.
Second, as the contrary example, per default configuration of
pam_nologin.so at /etc/pam.d/login, creating the following file:
# touch /etc/nologin
results in that no user other than root may login (if root logins are allowed, another default for Arch Linux). To allow logins again, remove the file. Possibly, from the console you created it with.
With that as background, see #PAM stack and module configuration for particular use-case configuration.
This section provides an overview of content detailing how to apply changes to the PAM configuration and how to integrate special new PAM modules into the PAM stack. Note the man pages for the modules can generally be reached dropping the
Security parameter configuration
The following sections describe examples to change the default PAM parameter configuration:
- shows how to enforce strong passwords with
- shows how to configure the limits on login attempts with
- limits user logons with
- detail how to configure system process limits with
- shows examples to set environment variables via
PAM stack and module configuration
The following articles detail how to change the #PAM base-stack for special use-cases.
- detail examples for using
pam_mount.soto automount encrypted directory paths on user login.
pam_ecryptfs.soto automount an encrypted directory.
- Dm-crypt/Mounting at login
- shows how to use
pam_exec.soto execute a custom script on a user login.
- Active Directory integration#Configuring PAM
pam_krb5.soto let users authenticate via Active Directory (LDAP, Kerberos) services.
- LDAP authentication#NSS and PAM[broken link: invalid section]
- is an article about integrating LDAP client or server-side authentication with
- YubiKey#Linux user authentication with PAM
- describes how to use U2F (
pam_u2f.so) and the proprietary Yubico OTP implementation (
pam_yubico.so) provided by the YubiKey with PAM
- shows an example to implement software based two-factor authentication with
pam_fprintd.soto setup fingerprint authentication.
- saves username and password to log in automatically.
- shows how to configure
pam_usb.soto use an usb-device for, optionally two-factor, authentication.
- SSH keys#pam_ssh
pam_ssh.soto authenticate as a remote user.
- explains how
pam_abl.socan be used to limit brute-forcing attacks via ssh.
- may get automounted via
- Google Authenticator
- shows how to set up two-factor authentication with
- Very Secure FTP Daemon#PAM with virtual users
- explains how to configure a FTP chroot with
pam_pwdfile.soto authenticate users without a local system account.
Further PAM packages
Other than those packages mentioned so far, the Arch User Repository contains a number of additional PAM modules and tools.
A general purpose utility relating to PAM is:
- Pamtester — Program to test the pluggable authentication modules (PAM) facility