Password aging policy
low on-server
What it inspects
`chage -l` for every account in /etc/passwd whose shell is bash, zsh, sh, dash, ksh, csh, tcsh or fish. An account is reported when its maximum days between password changes is 99999, -1 or never. Locked accounts, and hosts where sudo authenticates against a directory (SSSD, Kerberos), are ignored. The result is a warning only, with minimal score impact.
Why it matters
Some compliance regimes require a maximum password age, so this check shows you accounts that would not meet one. Current NIST guidance (SP 800-63B) recommends against forced periodic changes because they push people toward weaker, predictable passwords, and prefers keys, MFA and rotation after evidence of compromise. Decide based on the policy you actually have to meet.
How to verify
# A maximum of 99999 (or -1) is what the check flags.
for u in $(awk -F: '$7 ~ /[/](bash|zsh|sh|dash|ksh|csh|tcsh|fish)$/ {print $1}' /etc/passwd); do echo "== $u"; sudo chage -l "$u" | grep -i 'maximum'; doneHow to fix
Only if you must meet a rotation policy: set a maximum age per account with chage, or lock accounts that do not need a password. Check the last-change date first to avoid expiring a password you cannot reset.
Set a maximum password age, or lock accounts that need no password needs your judgement
Any distro
# Optional and policy-driven. NIST SP 800-63B advises against forced rotation; skip this if no policy requires it.
# Per account, first look at 'Last password change' and the current limits:
# chage -l <user>
# EXPIRY WARNING: if the last change is older than the new maximum, the password is expired immediately and the
# next login forces a change. For a key-only account whose password you do not know, that can lock you out.
# Option A, accounts with a password you control (example 365 days):
# chage -M 365 <user>
# New accounts: set PASS_MAX_DAYS in /etc/login.defs (it does not change existing accounts).
# Option B, accounts that log in only with SSH keys: lock the password; the check then ignores them.
# passwd -l <user>
# Confirm first: `sshd -T | grep -i '^usepam'` must be `usepam yes`, otherwise sshd rejects key logins
# for locked accounts. Do not lock an account that needs its password for sudo.