← All rules
SOCLE-CLD-IAM-034// Accounts (PAM modules)mediumpersistent config

Require use_authtok for pam_unix.so

Forces pam_unix.so to reuse the password token already validated by the complexity modules, via the use_authtok option in the PAM password stack.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

A pass proves? running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

Without use_authtok, the pam_unix.so module prompts for a brand-new password instead of reusing the token already validated by the earlier complexity modules (pam_pwquality / pam_cracklib). The result is a password that bypasses the configured strength, history and dictionary checks, silently defeating the whole password policy stack.

What Pavois checks

Pavois greps the effective PAM password stack under /etc/pam.d/ for a non-commented pam_unix.so line carrying use_authtok. Reading the live PAM tree (including common-password and any service files that @include it) catches the option wherever it is actually wired, which a check pinned to a single hard-coded file would miss.

describe command('grep -RqE \'^[^#]*\bpam_unix\\.so\b[^#]*\buse_authtok\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
  its('stdout.strip') { should eq 'ok' }
end

How to verify it is applied

Run:

grep -rE '^[^#]*\bpam_unix\.so\b[^#]*\buse_authtok' /etc/pam.d/

Expected: at least one password line (typically in common-password or password-auth) shows pam_unix.so followed by use_authtok. No match means the option is absent.

Inspect & investigate

PAM authentication and password-change events are logged to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/Fedora). Follow them live with journalctl -t passwd -f or journalctl _COMM=passwd while changing a password; a token rejected by the complexity modules will surface here.

Remediation

No automated harden plan ships for this rule yet, so it must be applied manually: edit the password stack (/etc/pam.d/common-password on Debian/Ubuntu, /etc/pam.d/password-auth and system-auth on RHEL/Fedora, ideally via authselect/pam-auth-update) and append use_authtok to the pam_unix.so line, after the pam_pwquality module.

Pavois applies this with its own harden engine, the plan below, not a shell script:

command# Ensure pam_unix in /etc/pam.d/common-password carries 'use_authtok' (so it reuses the checked # password). Manage the stack with: pam-auth-update (do not hand-edit common-password)
reasonPAM password-stack change, apply via pam-auth-update, not a hand edit
resourcemanual
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

If left unset, users can set weak passwords that escape the policy, but the misconfiguration itself is low-risk to fix. Precautions: never hand-edit a PAM stack over your only SSH session without an open root shell as a fallback, an ordering mistake on pam_unix.so can lock everyone out of password authentication. Use pam-auth-update/authselect where possible, and verify the change in a second session before closing the first.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS5.3.3.4.4directper OS, see the benchmark tablehigh

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references