PAM

Related articles
Security
pam_mount
pam_usb
pam_abl
pam_oath
Universal 2nd Factor
Identity management
The
Linux Pluggable Authentication Modules
(PAM) provides a framework for system-wide user authentication. To quote the
project
:
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.
Installation
The
pam
package is a dependency of the
base
meta package
and, thereby, normally installed on an Arch system. The PAM modules are installed into
/usr/lib/security
exclusively.
The repositories contain a number of optional PAM packages, the
#Configuration How-Tos
show examples.
Configuration
A number of
/etc
paths are relevant for PAM; execute
pacman -Ql 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.
Security parameters
The path
/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.
PAM base-stack
The
/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
pambase
package, which contains the base-stack of Arch Linux specific PAM configuration to be used by applications, and
other base packages. For example,
util-linux
adds configuration for the central
login
and other programs, the
shadow
package adds the Arch Linux defaults to secure and modify the user database (see
Users and groups
).
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:
/etc/pam.d/
login -> system-local-login -> system-login -> system-auth
For a different application, a different path may apply. For example,
openssh
installs its
sshd
PAM policy:
/etc/pam.d/
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-login
or
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.
Tip
PAM is dynamically linked at runtime. For example:
$ 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 pages
pam(8)
and
pam.d(5)
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.
Warning
Changes to the PAM configuration fundamentally affect user authentication. Erroneous changes can result in that
no user
can log in, or
all users
being able to log in.
Tip
Changes are not effective for already authenticated users; a way to work with PAM is to login preferably locally on the testing machine and develop, keeping the session constantly running, while checking the results from another user on another console.
Examples
The factual accuracy of this article or section is disputed.
Reason:
(1) the use of nullok (2) the way pam handles optional modules (Discuss in
Talk:PAM#Accuracy of PAM#Examples
)
Two short examples to illustrate the above warning.
First, we take the following two lines from a
historic Arch default
:
/etc/pam.d/system-auth
auth      required  pam_unix.so     try_first_pass nullok
auth      optional  pam_permit.so
From
pam_unix(8)
:
The authentication component
pam_unix.so
performs 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
required
and
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
in
/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, see
Security#Restricting root login
). To allow logins again, remove the file again before your logout from the console you created it with.
With that as background, see
#PAM stack and module configuration
for particular use-case configuration.
Configuration How-Tos
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
.so
extension.
Security parameter configuration
The following sections describe examples to change the default PAM parameter configuration:
Security#Enforcing strong passwords with pam_pwquality
shows how to enforce strong passwords with
pam_cracklib.so
.
Security#Lock out user after three failed login attempts
shows how to configure the limits on login attempts with
pam_faillock.so
.
Security#Allow only certain users
limits user logons with
pam_wheel.so
.
Realtime process management#Configuring PAM
and
Security#Limit amount of processes
detail how to configure system process limits with
pam_limits.so
.
Environment variables#Using pam_env
shows examples to set environment variables via
pam_env.so
.
PAM stack and module configuration
The following articles detail how to change the
#PAM base-stack
for special use-cases.
pam_mount
detail examples for using
pam_mount.so
to automount encrypted directory paths on user login.
ECryptfs#Auto-mounting
uses
pam_ecryptfs.so
to automount an encrypted directory.
Dm-crypt/Mounting at login
shows how to use
pam_exec.so
to execute a custom script on a user login.
Active Directory integration#Configuring PAM
uses
pam_winbind.so
and
pam_krb5.so
to let users authenticate via Active Directory (
LDAP
,
Kerberos
) services.
LDAP authentication
is an article about integrating LDAP client or server-side authentication with
pam_ldap.so
.
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
pam_oath
shows an example to implement software based two-factor authentication with
pam_oath.so
.
fprint
employs
pam_fprintd.so
to setup fingerprint authentication.
pam_autologin
saves username and password to log in automatically.
pam_usb
shows how to configure
pam_usb.so
to use an usb-device for, optionally two-factor, authentication.
SSH keys#pam_ssh
uses
pam_ssh.so
to authenticate as a remote user.
pam_abl
explains how
pam_abl.so
can be used to limit brute-forcing attacks via ssh.
EncFS
may get automounted via
pam_encfs.so
.
Google Authenticator
shows how to set up two-factor authentication with
pam_google_authenticator.so
.
Very Secure FTP Daemon#PAM with virtual users
explains how to configure a FTP chroot with
pam_pwdfile.so
to 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:
Pamtester
— Program to test the pluggable authentication modules (PAM) facility
https://pamtester.sourceforge.net/
||
pamtester
AUR
authselect
— Tool to select PAM system authentication and identity sources from a list of supported profiles
https://github.com/authselect/authselect/wiki
||
authselect
AUR
Note the AUR features a keyword tag for
PAM
, but not all available packages are updated to include it. Hence, searching the
package description
may be necessary.
Tips and tricks
Locked out
If PAM has locked you out, perhaps by typing the wrong password too many times, see
Security#Lock out user after three failed login attempts
.
See also
linux-pam.org
- The project homepage
Understanding and configuring PAM
- An introductory article
Login managers: An introduction
- Motivates PAM in the context of a
login manager