PAM: Difference between revisions

From ArchWiki
(→‎PAM base-stack: new pambase release, default 'other' policy changed to upstream; FS# closed, Yay. re https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pambase&id=3552aba772e8bebbe754a4d01f2729e291dd2070)
(→‎Examples: style fix, add crosslink reference)
 
(49 intermediate revisions by 18 users not shown)
Line 3: Line 3:
[[es:PAM]]
[[es:PAM]]
[[ja:PAM]]
[[ja:PAM]]
[[ru:PAM]]
[[zh-hans:PAM]]
[[zh-hans:PAM]]
{{Related articles start}}
{{Related articles start}}
Line 10: Line 11:
{{Related|pam_abl}}
{{Related|pam_abl}}
{{Related|pam_oath}}
{{Related|pam_oath}}
{{Related|Universal 2nd Factor}}
{{Related articles end}}
{{Related articles end}}
The [http://www.linux-pam.org/ Linux Pluggable Authentication Modules] (PAM) provide a framework for system-wide user authentication. To quote the [http://www.linux-pam.org/whatispam.html project]:
The [http://www.linux-pam.org/ Linux Pluggable Authentication Modules] (PAM) provides a framework for system-wide user authentication. To quote the [https://web.archive.org/web/20220402070708/http://linux-pam.org/whatispam.html 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.  
: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.  
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 ==  
== Installation ==


The {{Pkg|pam}} package is part of the [[base group]] of packages and, thereby, normally installed on an Arch system. The PAM modules are installed into {{ic|/usr/lib/security}} exclusively.  
The {{Pkg|pam}} package is a dependency of the {{Pkg|base}} [[meta package]] and, thereby, normally installed on an Arch system. The PAM modules are installed into {{ic|/usr/lib/security}} exclusively.  


The repositories contain a number of optional PAM packages, the [[#Configuration How-Tos]] show examples.
The repositories contain a number of optional PAM packages, the [[#Configuration How-Tos]] show examples.


== Configuration ==  
== Configuration ==


A number of {{ic|/etc}} paths are relevant for PAM, execute {{ic|<nowiki>pacman -Ql pam |grep /etc</nowiki>}} to see the default configuration files created. They relate to either [[#Security parameters]] for the modules, or the [[#PAM base-stack]] configuration.  
A number of {{ic|/etc}} paths are relevant for PAM; execute {{ic|<nowiki>pacman --query --list pam | grep /etc</nowiki>}} to see the default configuration files created. They relate to either [[#Security parameters]] for the modules, or the [[#PAM base-stack]] configuration.


=== Security parameters ===  
=== Security parameters ===


The path {{ic|/etc/security}} contains system-specific configuration for variables the authentication methods offer. The base install populates it with default upstream configuration files.  
The path {{ic|/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 {{ic|/etc/security/pwquality.conf}} file can be used to define system-wide defaults for password quality. Yet, to enable it the {{ic|pam_pwquality.so}} module has to be added to the [[#PAM base-stack]] of modules, which is not the case per default.
Note Arch Linux does not provide distribution-specific configuration for these files. For example, the {{ic|/etc/security/pwquality.conf}} file can be used to define system-wide defaults for password quality. Yet, to enable it, the {{ic|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.
See [[#Security parameter configuration]] for some of the possibilities.
Line 37: Line 39:
=== PAM base-stack ===
=== PAM base-stack ===


The {{ic|/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 {{ic|/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 {{Pkg|pambase}} package, which contains the base-stack of Arch Linux specific PAM configuration to be used by applications, and  
* the {{Pkg|pambase}} package, which contains the base-stack of Arch Linux specific PAM configuration to be used by applications, and  
* other base packages. For example, {{Pkg|util-linux}} adds configuration for the central ''login'' and other programs, the {{Pkg|shadow}} package adds the Arch Linux defaults to secure and modify the user database (see [[Users and groups]]).  
* other base packages. For example, {{Pkg|util-linux}} adds configuration for the central ''login'' and other programs, the {{Pkg|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, are stacked during runtime. For example, on a local user logon, the ''login'' application sources the {{ic|system-local-login}} policy, which in turn sources others:  
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 {{ic|system-local-login}} policy, which in turn sources others:  


{{hc|/etc/pam.d/|
{{hc|/etc/pam.d/|
Line 57: Line 59:


{{Tip|PAM is dynamically linked at runtime. For example:  
{{Tip|PAM is dynamically linked at runtime. For example:  
{{hc|<nowiki>$ ldd /usr/bin/login |grep pam</nowiki>|2=
{{hc|<nowiki>$ ldd /usr/bin/login | grep pam</nowiki>|2=
libpam.so.0 => /usr/lib/libpam.so.0 (0x000003d8c32d6000)
libpam.so.0 => /usr/lib/libpam.so.0 (0x000003d8c32d6000)
libpam_misc.so.0 => /usr/lib/libpam_misc.so.0 (0x000003d8c30d2000)}}
libpam_misc.so.0 => /usr/lib/libpam_misc.so.0 (0x000003d8c30d2000)}}
the ''login'' application is pam-aware and '''must''', therefore, have a policy.}}  
the ''login'' application is pam-aware and '''must''', therefore, have a policy.}}  


The PAM package manual pages {{man|8|pam}} and {{man|5|pam.d}} 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 behaviour of the modules.  
The PAM package manual pages {{man|8|pam}} and {{man|5|pam.d}} 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, an extensive documentation is installed to {{ic|/usr/share/doc/Linux-PAM/index.html}} which, among various guides, contains browsable man pages for each of the standard modules.  
Additionally, extensive documentation is installed to {{ic|/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''' or '''any''' user can log in. Since changes are not effective for already authenticated users, a good precaution is to perform changes with one user and test the result with another user in a separate console.}}
{{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.}}


==== Examples ====
{{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 ====
{{Accuracy|(1) the use of nullok (2) the way pam handles optional modules|Talk:PAM#Accuracy of PAM#Examples}}
Two short examples to illustrate the above warning.  
Two short examples to illustrate the above warning.  


First, we take the following two lines:
First, we take the following two lines from a [https://github.com/archlinux/svntogit-packages/commit/2d5af94ae55a5c98837ce9631f331ad2aad32bb3#diff-aec230c42317e26304d9510982853cc56a2f4a5d63d91eb4da46d247def8cd9aL3-L4 historic Arch default]:
{{hc|/etc/pam.d/system-auth|
{{hc|/etc/pam.d/system-auth|
auth      required  pam_unix.so    try_first_pass nullok
auth      required  pam_unix.so    try_first_pass nullok
auth      optional  pam_permit.so}}  
auth      optional  pam_permit.so}}  


From {{man|8|pam_unix}}: "The authentication component {{ic|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 {{ic|pam_permit.so}} is used for. Simply swapping the control values {{ic|required}} and {{ic|optional}} for both lines is enough to disable password authentication, i.e. any user may logon without providing a password.  
From {{man|8|pam_unix}}:
:The authentication component {{ic|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 {{ic|pam_permit.so}} is used for. Simply swapping the control values {{ic|required}} and {{ic|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 creating the following file:  
Second, as the contrary example, per default configuration of {{ic|pam_nologin.so}} in {{ic|/etc/pam.d/login}}, creating the following file:  
  # touch /etc/nologin  
  # 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 from the console you created it with.  
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. Possibly, from the console you created it with.


With that as background, see [[#PAM stack and module configuration]] for particular use-case configuration.
With that as background, see [[#PAM stack and module configuration]] for particular use-case configuration.
Line 89: Line 96:
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 {{ic|.so}} extension.
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 {{ic|.so}} extension.


=== Security parameter configuration ===  
=== Security parameter configuration ===


The following sections describe examples to change the default PAM parameter configuration:  
The following sections describe examples to change the default PAM parameter configuration:  


* [[Security#Enforcing strong passwords using pam_cracklib]]  
* [[Security#Enforcing strong passwords with pam_pwquality]]  
:shows how to enforce strong passwords with {{ic|pam_cracklib.so}}.  
:shows how to enforce strong passwords with {{ic|pam_cracklib.so}}.  
* [[Security#Lockout user after three failed login attempts]]  
* [[Security#Lock out user after three failed login attempts]]  
:shows how to limit login attempts with {{ic|pam_tally.so}}.  
:shows how to configure the limits on login attempts with {{ic|pam_faillock.so}}.  
* [[Security#Allow only certain users]]  
* [[Security#Allow only certain users]]  
:limits user logons with {{ic|pam_wheel.so}}.  
:limits user logons with {{ic|pam_wheel.so}}.  
Line 104: Line 111:
:shows examples to set environment variables via {{ic|pam_env.so}}.
:shows examples to set environment variables via {{ic|pam_env.so}}.


=== PAM stack and module configuration ===  
=== PAM stack and module configuration ===


The following articles detail how to change the [[#PAM base-stack]] for special use-cases.
The following articles detail how to change the [[#PAM base-stack]] for special use-cases.


PAM modules from the [[Official repositories]]:
; [[pam_mount]]: detail examples for using {{ic|pam_mount.so}} to automount encrypted directory paths on user login.
* [[pam_mount]]
; [[ECryptfs#Auto-mounting]]: uses {{ic|pam_ecryptfs.so}} to automount an encrypted directory.  
:detail examples for using {{ic|pam_mount.so}} to automount encrypted directory paths on user login.
; [[Dm-crypt/Mounting at login]] : shows how to use {{ic|pam_exec.so}} to execute a custom script on a user login.  
* [[ECryptfs#Auto-mounting]]
; [[Active Directory integration#Configuring PAM]]: uses {{ic|pam_winbind.so}} and {{ic|pam_krb5.so}} to let users authenticate via Active Directory ([[LDAP]], [[Kerberos]]) services.
:uses {{ic|pam_ecryptfs.so}} to automount an encrypted directory.  
; [[LDAP authentication]]: is an article about integrating LDAP client or server-side authentication with {{ic|pam_ldap.so}}.  
* [[Dm-crypt/Mounting at login]]  
; [[YubiKey#Linux user authentication with PAM]]: describes how to use U2F ({{ic|pam_u2f.so}}) and the proprietary Yubico OTP implementation ({{ic|pam_yubico.so}}) provided by the YubiKey with PAM
:shows how to use {{ic|pam_exec.so}} to execute a custom script on a user login.  
; [[pam_oath]] : shows an example to implement software based two-factor authentication with {{ic|pam_oath.so}}.
* [[Active Directory Integration#Configuring PAM]]
; [[fprint]]: employs {{ic|pam_fprintd.so}} to setup fingerprint authentication.
:uses {{ic|pam_winbind.so}} and {{ic|pam_krb5.so}} to let users authenticate via Active Directory (LDAP, [[Kerberos]]) services.
; [[pam_autologin]] : saves username and password to log in automatically.
* [[LDAP authentication]] with its [[LDAP authentication#NSS and PAM]] section
; [[pam_usb]] : shows how to configure {{ic|pam_usb.so}} to use an usb-device for, optionally two-factor, authentication.
:is an article about integrating LDAP client or server-side authentication with {{ic|pam_ldap.so}}.  
; [[SSH keys#pam_ssh]]: uses {{ic|pam_ssh.so}} to authenticate as a remote user.   
* [[YubiKey#Two-factor authentication with SSH]]  
; [[pam_abl]]: explains how {{ic|pam_abl.so}} can be used to limit brute-forcing attacks via ssh.
:relies on {{ic|pam_yubico.so}} in the PAM stack to enable authentication via the proprietary Yubikey.
; [[EncFS#/etc/pam.d/|EncFS]] : may get automounted via {{ic|pam_encfs.so}}.
* [[pam_oath]]  
; [[Google Authenticator]]: shows how to set up two-factor authentication with {{ic|pam_google_authenticator.so}}.
:shows an example to implement software based two-factor authentication with {{ic|pam_oath.so}}.
; [[Very Secure FTP Daemon#PAM with virtual users]]: explains how to configure a FTP chroot with {{ic|pam_pwdfile.so}} to authenticate users without a local system account.
* [[fprint]]
:employs {{ic|pam_fprintd.so}} to setup fingerprint authentication.
 
PAM modules from the [[Arch User Repository]]:  
* [[pam_usb]]  
:shows how to configure {{ic|pam_usb.so}} to use an usb-device for, optionally two-factor, authentication.
* [[SSH keys#pam_ssh]]
:uses {{ic|pam_ssh.so}} to authenticate as a remote user.   
* [[pam_abl]]
:explains how {{ic|pam_abl.so}} can be used to limit brute-forcing attacks via ssh.
* [[EncFS#.2Fetc.2Fpam.d.2F|EncFS]]  
:may get automounted via {{ic|pam_encfs.so}}.
* [[Google Authenticator]]
:shows how to set up two-factor authentication with {{ic|pam_google_authenticator.so}}.
* [[Very Secure FTP Daemon#PAM with virtual users]]
:explains how to configure a FTP chroot with {{ic|pam_pwdfile.so}} to authenticate users without a local system account.


== Further PAM packages ==
== Further PAM packages ==
Line 144: Line 135:
Other than those packages mentioned so far, the [[Arch User Repository]] contains a number of additional PAM modules and tools.   
Other than those packages mentioned so far, the [[Arch User Repository]] contains a number of additional PAM modules and tools.   


General purpose utilities relating to PAM are:  
A general purpose utility relating to PAM is:  
 
* {{App|[https://github.com/ArchLinux-x32/libx32-pam libx32_pam]|Arch Linux PAM x32 ABI library|http://linux-pam.org/|{{Aur|libx32-pam}}}}


* {{App|[http://linux.die.net/man/1/pamtester Pamtester]|Program to test the pluggable authentication modules (PAM) facility|http://pamtester.sourceforge.net/|{{Aur|pamtester}}}}
* {{App|[https://linux.die.net/man/1/pamtester Pamtester]|Program to test the pluggable authentication modules (PAM) facility|https://pamtester.sourceforge.net/|{{Aur|pamtester}}}}


Note the AUR features a keyword tag for [https://aur.archlinux.org/packages/?O=0&SeB=k&K=pam&outdated=off&SB=p&SO=d&PP=50&do_Search=Go PAM], but not all available packages are updated to include it. Hence, searching the [https://aur.archlinux.org/packages/?O=0&SeB=nd&K=pam&outdated=off&SB=p&SO=d&PP=50&do_Search=Go package description] may be necessary.
Note the AUR features a keyword tag for [https://aur.archlinux.org/packages/?SeB=k&K=pam PAM], but not all available packages are updated to include it. Hence, searching the [https://aur.archlinux.org/packages/?K=pam package description] may be necessary.


== See also ==
== See also ==


* [http://www.linux-pam.org/ linux-pam.org] - The project homepage  
* [http://www.linux-pam.org/ linux-pam.org] - The project homepage  
* [https://www.ibm.com/developerworks/linux/library/l-pam/index.html Understanding and configuring PAM] - An introductory article
* [https://web.archive.org/web/20211124031525/https://developer.ibm.com/tutorials/l-pam/ Understanding and configuring PAM] - An introductory article

Latest revision as of 20:23, 15 March 2024

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 --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.

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. Possibly, 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:

shows how to enforce strong passwords with pam_cracklib.so.
shows how to configure the limits on login attempts with pam_faillock.so.
limits user logons with pam_wheel.so.
detail how to configure system process limits with pam_limits.so.
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.

A general purpose utility relating to PAM is:

  • Pamtester — Program to test the pluggable authentication modules (PAM) facility
https://pamtester.sourceforge.net/ || pamtesterAUR

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.

See also