PAM base


No contents found at URL
Source Repository:Repository:Gentoo Portage Tree

Summary: Base configuration files for different PAM implementations

Use Flags

Enable pam_cracklib module on system authentication stack. This produces warnings when changing password to something easily crackable. It requires the same USE flag to be enabled on sys-libs/pam or system login might be impossible.
Enable pam_ck_connector module on local system logins. This allows for console logins to make use of ConsoleKit authorization.
Enable pam_gnome_keyring module on system login stack. This enables proper Gnome Keyring access to logins, whether they are done with the login shell, a Desktop Manager or a remote login systems such as SSH.
Enable debug information logging on syslog(3) for all the modules supporting this in the system authentication and system login stacks.
Enable pam_passwdqc module on system auth stack for password quality validation. This is an alternative to pam_cracklib producing warnings, rejecting or providing example passwords when changing your system password. It is used by default by OpenWall GNU/*/Linux and by FreeBSD.
Enable pam_mktemp module on system auth stack for session handling. This module creates a private temporary directory for the user, and sets TMP and TMPDIR accordingly.
Enable pam_ssh module on system auth stack for authentication and session handling. This module will accept as password the passphrase of a private SSH key (one of ~/.ssh/id_rsa, ~/.ssh/id_dsa or ~/.ssh/identity), and will spawn an ssh-agent instance to cache the open key.
Switch Linux-PAM's pam_unix module to use sha512 for passwords hashes rather than MD5. This option requires >=sys-libs/pam-1.0.1 built against >=sys-libs/glibc-2.7, if it's built against an earlier version, it will silently be ignored, and MD5 hashes will be used. All the passwords changed after this USE flag is enabled will be saved to the shadow file hashed using SHA512 function. The password previously saved will be left untouched. Please note that while SHA512-hashed passwords will still be recognised if the USE flag is removed, the shadow file will not be compatible with systems using an earlier glibc version.
Enable pam_krb5 module on system auth stack, as an alternative to pam_unix. If Kerberos authentication succeed, only pam_unix will be ignore, and all the other modules will proceed as usual, including Gnome Keyring and other session modules. It requires sys-libs/pam as PAM implementation.
Disables the standard PAM modules that provide extra information to users on login; this includes pam_tally (and pam_tally2 for Linux PAM 1.1 and later), pam_lastlog, pam_motd and other similar modules. This might not be a good idea on a multi-user system but could reduce slightly the overhead on single-user non-networked systems.



Kits Are Go (And Ego Needs a Manual Bump)

An update on kits and how to manually update to ego-1.1.3-r3 (required steps for some)
2017-08-17 by Drobbins

Kits are Go (Switch to Them!)

Kits are now the official way we do things at Funtoo.
2017-07-31 by Drobbins

Funtoo-Stable Going Away

As we move towards the next generation of Funtoo Linux, funtoo-stable is being retired.
2017-07-11 by Drobbins

PAM base


We welcome improvements to this page. To edit this page, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.

PAM: Pluggable authentication module is a system to authenticate users in several ways. PAM can use biometrics, ssh key passphrases, and other systems to authenticate users.


pam controls login behavior, an error in configuration may result in being locked out of your account. Test login behavior on alternate tty consoles before relying upon changes made, and make sure to have rescue media available.

Current design

Installed files

Currently the following files are installed by pambase:


The files starting with 'system' prefix are intended to be used by other PAM files. In particular:

  1. system-auth is used whenever user authentication is desired. It is included in PAM files for account manipulation tools (passwd, chsh, ...), authenticated daemons (imap, pop3), xscreensaver (for screen locking) and system-login.
  2. system-login is used whenever login is done. It is currently included only in system-local-login and system-remote-login.
  3. system-local-login is used whenever local system login is performed. It is used by login and display managers.
  4. system-remote-login is used whenever remote system login is performed. It is used by sshd.
  5. system-services is used whenever system daemons are started. It is used by start-stop-daemon and systemd.

How files are generated

The pambase Makefile generates the above files using traditional C preprocessor on top of templates. The preprocessor is provided with defines matching USE flags of choice. The processed files are then installed to user systems.

Problems with the current system

The problems with the current system are:

  1. centralised management of PAM backends,
  2. no easy way for user to modify the configuration files without having to repeatedly handle updates.

In particular, the ability to change authentication backends is very limited. If a new backend is to be supported out-of-the-box, one needs to update the pambase package and add more flags and conditionals to it. There is no sane way of controlling the module use order or adding out-of-tree PAM modules.

If user modifies module configuration, they need to maintain the modifications while pambase upgrades try to restore configuration files to original content.

ssh key auth


this might break login to users without ssh keys.

PAM can be used as an alternative to Keychain. Make sure you have a ssh key with a passphrase before enabling the pam ssh backend.

# echo "sys-auth/pambase pam_ssh" >> /etc/portage/package.use/pambase
# emerge -1 sys-auth/pambase