18.2 Change Passwords and Adjust Password Aging

18.2 Change Passwords and Adjust Password Aging

Quick Answer: Set or change passwords with passwd. Inspect and set aging with chage (-l list, -M max days, -m min days, -W warn, -E expire date, -I inactive, -d last change). Defaults for new accounts often come from /etc/login.defs. Force an immediate password change with chage -d 0 user or passwd -e user. Verify with sudo chage -l user and the shadow fields.

Why password aging is an EX200 skill

Local accounts are incomplete until authentication policy matches the task. EX200 language looks like:

• “Set the password for user alice.”
• “Password must expire every 90 days.”
• “User must change password at next login.”
• “Account expires on 2026-12-31.”
• “Minimum password lifetime 2 days; warn 7 days before expiry.”

You need both password setting (passwd) and aging controls (chage / related passwd flags). Configuration is stored primarily in /etc/shadow and must persist after reboot (it does—these are file-backed).

passwd: set and manage passwords

Interactive and stdin

sudo passwd alice                 # prompts twice for new password
echo 'S3curePass!' | sudo passwd --stdin alice    # non-interactive (RHEL)

As root, you can set another user’s password without knowing the old one. As an unprivileged user, passwd changes your own password and may enforce quality checks (pam_pwquality and related PAM modules).

passwd                            # change own password

Useful passwd status flags

sudo passwd -S alice
sudo passwd -l alice
sudo passwd -u alice
sudo passwd -e alice

RHCSA preference: Many training paths teach chage for aging clarity and passwd for setting the secret. Either aging interface can satisfy tasks if the shadow end state is correct—know chage -l as your primary verification tool.

/etc/shadow fields (mental model)

name:hash:lastchange:min:max:warn:inactive:expire:reserved

sudo grep '^alice:' /etc/shadow
sudo chage -l alice

Prefer chage -l for human-readable output over decoding epoch day numbers by hand under time pressure.

chage: the aging Swiss army knife

List policy

sudo chage -l alice

Example fields you will see:

• Last password change
• Password expires
• Password inactive
• Account expires
• Minimum/Maximum/Warning numbers

Set policy (common exam options)

# Classic corporate-style policy
sudo chage -m 2 -M 90 -W 7 -I 14 alice
sudo chage -l alice

# Account (login) expires on a calendar date
sudo chage -E 2026-12-31 alice
sudo chage -E -1 alice          # remove account expiration

# Force password change at next login
sudo chage -d 0 alice
# equivalent idea:
sudo passwd -e alice
sudo chage -l alice

Combining create + password + aging

sudo useradd -m -s /bin/bash alice
echo 'InitialP@ss1' | sudo passwd --stdin alice
sudo chage -d 0 -M 60 -m 1 -W 7 alice
sudo chage -l alice

Set a known password before or as part of the task so the user can log in once and be forced to change it when -d 0 / passwd -e is required.

login.defs defaults (new accounts)

grep -E '^PASS_' /etc/login.defs

Typical keys:

Changing login.defs affects future default application for new users more than rewriting every existing account. If the task names one user, use chage on that user rather than rewriting global defaults unless asked.

# Inspect defaults; avoid casual global edits on the exam
grep -E '^PASS_MAX_DAYS|^PASS_MIN_DAYS|^PASS_WARN_AGE' /etc/login.defs

Account expire vs password expire

These are easy to confuse:

A user can have a valid password age but a past account expiration—or the reverse. Read the task words: “password expires every N days” → -M; “account expires on DATE” → -E; “must change password at next login” → -d 0 or passwd -e.

Inactive days (-I)

After the password expires, inactive days may pass before the account is fully disabled for login:

sudo chage -M 90 -I 7 alice

Meaning pattern: password valid 90 days; after it expires, 7 more days of grace (policy-dependent messaging) before inactive disable—confirm with chage -l wording. Use exactly the numbers the task specifies.

Password quality (awareness)

On RHEL, PAM modules (for example pam_pwquality via /etc/security/pwquality.conf) may reject weak passwords for non-root paths. As root setting another user’s password, quality rules are often less strict—but extremely weak passwords can still fail depending on configuration. If passwd rejects a password:

1. Choose a longer mixed password.
2. Retry.
3. Do not disable PAM system-wide on the exam unless a task explicitly redesigns authentication (unlikely for core RHCSA user tasks).

Locking and unlocking (overlap with 18.1)

sudo passwd -l alice
sudo passwd -S alice
sudo passwd -u alice
sudo usermod -L alice
sudo usermod -U alice

Locked accounts show ! or !! prefixes in the shadow hash field. Unlocking restores use of the existing hash when appropriate. Deleting a password with passwd -d can leave an account oddly accessible depending on PAM—prefer lock/expire patterns taught in training over empty passwords.

Verification habits

sudo chage -l alice
sudo passwd -S alice
sudo grep '^alice:' /etc/shadow
# optional: date math sanity—max days and warn match the task

If the task requires next-login change, confirm Last password change is set such that the password is expired (commonly via day 0 semantics shown in chage -l as requiring change).

Exam workflows

Workflow A — Set password only

echo 'CorrectHorseBattery1' | sudo passwd --stdin alice
sudo passwd -S alice

Workflow B — 90-day max, 7-day warn, 2-day min

sudo chage -m 2 -M 90 -W 7 alice
sudo chage -l alice

Workflow C — Must change password at next login

echo 'TempPassw0rd!' | sudo passwd --stdin alice
sudo chage -d 0 alice
# or: sudo passwd -e alice
sudo chage -l alice

Workflow D — Contractor account ends on a date

sudo chage -E 2026-12-31 alice
sudo chage -l alice | grep -i 'Account expires'

Workflow E — Full package for one user

sudo useradd -m -s /bin/bash contractor1
echo 'InitP@ss9' | sudo passwd --stdin contractor1
sudo chage -d 0 -m 1 -M 30 -W 5 -I 3 -E 2026-11-30 contractor1
sudo chage -l contractor1

Common traps

1. Setting PASS_MAX_DAYS in login.defs only and forgetting chage on the named user when the task targets that user.
2. Mixing up -E account expire with -M password max days.
3. Using chage -d 0 without first setting a password—user may be stuck depending on process.
4. Assuming passwd interactive prompts work the same in all non-interactive exam automation—know --stdin on RHEL.
5. Forgetting sudo so chage -l / shadow reads fail.
6. Setting min days higher than max days—nonsensical policy; follow task numbers carefully.
7. Locking with passwd -l when the task asked only for aging—do not overshoot.
8. Not re-running chage -l after changes.
9. Confusing inactive (-I) with account expire (-E).
10. Expecting aging to “enable a service”—no systemd step; files alone persist.

Relationship to other sections

• 18.1 Users: accounts must exist before passwords/aging; locks overlap.
• 18.3 Groups: membership does not set passwords.
• 18.4 sudo: password prompts for sudo still use the user’s password policy.
• SSH key auth (security chapter): key login can bypass password entry, but account lock/expire still matter.
• PAM/security: quality and lockouts are related but deeper PAM redesign is beyond basic aging tasks.

Section checkpoint

You should set passwords with passwd (including RHEL --stdin), lock/unlock and expire passwords when required, configure min/max/warn/inactive/account expire with chage, force next-login changes with chage -d 0 or passwd -e, understand /etc/shadow and login.defs defaults, and verify everything with chage -l. That meets the EX200 objective to change passwords and adjust password aging on RHEL 10.