Give PAM a Separate Password Store with pam_extrausers

pam_extrausers lets one PAM service check a separate passwd and shadow file instead of the system's own account database. It adds pam_extrausers to a PAM stack so the selected operation reads /var/lib/extrausers/passwd and /var/lib/extrausers/shadow instead of the ordinary /etc/passwd and /etc/shadow files. Allow about 20 minutes for a review-only change, longer if you test a real login. Keep an existing administrator session open the whole time: PAM mistakes lock people out, not just you.

This covers the module shipped in Ubuntu's libpam-modules package. It does not create extrausers records for you, and it does not enable itself on every service just because it is installed.

1. Confirm the installed module and version

Check the package and shared object before touching any configuration. This guide was checked against version 1.5.3-5ubuntu5.7 of the amd64 package; yours may differ after an update.

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -r /usr/lib/x86_64-linux-gnu/security/pam_extrausers.so && echo module-present
module-present
$ man 8 pam_extrausers

If the package query fails, stop and install it through your normal package-management process. Never copy a module from another host: the PAM ABI, architecture and package version all have to match the system that will load it.

2. Choose one PAM service

PAM configuration is per service. /etc/pam.d/login, /etc/pam.d/sshd and /etc/pam.d/sudo each have their own stack, and changing one does not touch the others. Find the service you actually mean to change, without modifying anything yet:

$ sudo grep -nH 'pam_\(unix\|extrausers\)' /etc/pam.d/sshd /etc/pam.d/login /etc/pam.d/sudo 2>/dev/null
$ sudo sed -n '1,160p' /etc/pam.d/sshd

• Swap in the real service name. Replace sshd above with whichever file you settled on. If it includes a common stack, check that included file too.
• Pick the operation type. auth checks credentials, account checks account status, password changes a password, session records login or logout activity. pam_extrausers provides all four.

3. Back up the service configuration

A broken PAM stack can block logins or privilege escalation outright, so make a root-owned backup beside the file before you touch it. This is an elevated command; check the path before you run it.

$ sudo cp --preserve=mode,ownership,timestamps /etc/pam.d/sshd /etc/pam.d/sshd.before-pam-extrausers
$ sudo ls -l /etc/pam.d/sshd /etc/pam.d/sshd.before-pam-extrausers

4. Add the module to the intended stack

Put the module on the line matching the operation you picked. An authentication line, for example, can read:

auth    required    pam_extrausers.so

A password-changing stack needs more care. The manual's pattern uses obscure and sha512 first, then falls back to the ordinary Unix module if that one fails:

password        [success=2 default=ignore] pam_extrausers.so obscure sha512
password        [success=1 default=ignore] pam_unix.so obscure sha512
password        requisite                  pam_deny.so
password        required                   pam_permit.so

Do not paste that block into an unrelated service without understanding its existing control flags and extra lines: required, requisite and bracketed jump rules all decide how later modules get reached. Preserve distribution-managed comments and included files where you can.

• Blank passwords are rejected by default. Adding nullok permits them; nullok_secure limits that exception to terminals named in /etc/securetty. Treat either as a deliberate security decision, not a quick compatibility fix.
• Password reuse across modules. try_first_pass reuses a password from an earlier stacked module where it can; use_first_pass refuses to prompt at all if that password is unavailable or unsuitable.

5. Validate the edit before testing a login

Check the file as text first, and confirm the module path is still present. A syntax check cannot prove the whole stack will authenticate successfully, but it does catch the common mistakes: wrong service, misspelled module.

$ sudo grep -n 'pam_extrausers\.so' /etc/pam.d/sshd
12:auth    required    pam_extrausers.so
$ sudo test -s /var/lib/extrausers/passwd && echo passwd-file-present
$ sudo test -s /var/lib/extrausers/shadow && echo shadow-file-present
passwd-file-present
shadow-file-present

The module reads the extrausers files directly, so a missing or unreadable record is not something PAM control flags can fix. Check ownership and permissions with sudo stat /var/lib/extrausers/passwd /var/lib/extrausers/shadow. Warning: never make the shadow file world-readable.

6. Test without closing your recovery path

Leave the original administrator shell open and test the affected service from a second terminal or console. For SSH, open a new connection rather than reusing an old one. Try an expected valid account and a deliberately wrong password, then check both the client result and the service log. Do not test by logging out first.

$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no USER_NAME@HOST_NAME
$ sudo journalctl -u ssh --since '5 minutes ago' --no-pager

Swap in a USER_NAME and HOST_NAME you have already verified. The log unit may be ssh or sshd depending on your system. PAM failures usually name the service and module, but that is not proof the password file itself is healthy: check the account data and the whole stack if a result surprises you.

7. Change passwords only with a planned rollback

The password component updates the extrausers password. Its default hash choice comes from ENCRYPT_METHOD in /etc/login.defs; options like sha256, sha512 and rounds= affect passwords changed from this point on, not existing hashes. Check the effective policy before asking anyone to change a password, and keep passwords out of shell history or test transcripts.