How to Manage Linux Account Expiration and Password Aging

Quick take: Manage Linux account expiration, password aging, warning and inactivity periods, password locks, PAM policies, verification, troubleshooting, and safe rollback.

Overview

Manage Linux account expiration, password aging, warning and inactivity periods, password locks, PAM policies, verification, troubleshooting, and safe rollback. This guide is written for engineers, architects, security teams, technical leaders, and decision-makers who need more than a headline. It explains the technical meaning, operational impact, risks, validation work, and practical next steps for Linux user account expiration and password management.

The article uses the publisher or project documentation as its primary factual reference and clearly separates announced facts from operational interpretation. Product behavior, regional availability, policy, pricing, and support conditions can change. Readers should verify current documentation and test their own environment before acting. Where the article recommends a production change, preserve the existing configuration, record the expected result, and make the smallest reversible change that can prove or disprove the approach.

Account expiration and password expiration are different

Linux administrators place time limits on identities for several reasons. A contractor may need access only until a project ends, students may receive accounts for one semester, and a laboratory may recreate users for every exercise. A regulated environment may also require password-aging controls or scheduled access reviews. Service accounts need special care: an unexpected interactive password-expiration prompt can stop unattended work, so their authentication and rotation should be designed around the application rather than copied from a human-user policy.

Account expiration disables the account on a calendar date. Password expiration makes the current password too old and normally requires a password change. The warning period tells an interactive user that password expiration is approaching. The password inactivity period is a grace period after password expiration; once it ends, the account is locked. An administrator can separately lock the password hash, while PAM can temporarily lock authentication after repeated failures. These controls use different fields and solve different problems.

Expiring or locking an account does not delete its home directory or files. Deleting a user is a separate operation. Similarly, locking the local password may not revoke SSH keys, tokens, existing sessions, or access supplied by an external identity provider.

Create the user correctly

On systems using the shadow-utils tools, useradd is the low-level account-creation command. Debian and Ubuntu also provide adduser, a friendlier distribution-specific wrapper that prompts for common values. Options and defaults differ, so inspect useradd --help, man useradd, and the local policy before automating account creation.

sudo useradd -m -s /bin/bash irfan
sudo passwd irfan

# Equivalent interactive workflow on Debian or Ubuntu
sudo adduser irfan

-m creates the home directory and -s /bin/bash selects the login shell. The second command securely prompts the administrator for a password; it does not place the password in shell history. Lowercase usernames such as irfan are conventional because they avoid case ambiguity in scripts, email addresses, files, and external identity systems. Local validation rules can reject names that do not match the distribution's configured policy.

sudo useradd -m -s /bin/bash -c "Irfan Example" irfan
sudo useradd -m -u 1050 irfan
sudo useradd -m -g developers -G sudo,docker irfan
sudo useradd -m -e 2027-02-17 irfan

-c stores a descriptive comment, -u requests a UID, -g selects an existing primary group, and -G supplies a comma-separated supplementary-group list. Group membership can grant significant privilege—especially groups such as sudo, wheel, or docker—so assign it deliberately. The final example sets an account-expiration date at creation time.

Set, inspect, remove, or expire an account

The account-expiration field is a date after which the local account is no longer available through authentication paths that honor shadow account aging. Both usermod -e and chage -E can change it for an existing local user.

sudo useradd -e 2027-02-17 irfan
sudo usermod -e 2027-02-17 irfan
sudo chage -E 2027-02-17 irfan
sudo chage -l irfan

Use ISO-style YYYY-MM-DD dates for clarity. Current shadow-utils also accepts a number of days since 1970-01-01 and interprets dates in UTC, but packaged versions and surrounding login components vary. Always read the target host's manual and verify the resulting value with chage -l.

# Remove account expiration
sudo usermod -e "" irfan
sudo chage -E -1 irfan

# Expire immediately by setting a date in the past
sudo chage -E 1970-01-02 irfan

An expired account normally cannot start a new authenticated login, but its UID, group membership, files, and home directory remain. Existing processes or sessions may continue until separately terminated. Expiration is therefore reversible and useful for temporary access; locking changes authentication state; deletion removes the account database entry and can create ownership problems if files remain.

Understand every password-aging field

Password aging is stored with the local shadow entry. The last password change establishes the starting point. The minimum age prevents another change too soon; zero permits an immediate change. The maximum age determines when the password expires. The warning age controls how many days before that event an interactive login may warn the user. The inactivity period starts after password expiration and eventually locks the account if the password is not changed.

sudo chage -m 2 irfan
sudo chage -M 90 irfan
sudo chage -W 7 irfan
sudo chage -I 14 irfan
sudo chage -d 0 irfan
sudo chage -l irfan

# Apply the normal aging policy in one operation
sudo chage -m 2 -M 90 -W 7 -I 14 irfan

-m 2 requires two days between password changes. This can prevent rapid password cycling but can also impede recovery from a mistakenly disclosed password. -M 90 sets a 90-day maximum. -W 7 requests seven days of warning. -I 14 sets 14 days between password expiration and inactivity. Finally, -d 0 records an epoch last-change value, forcing a change at the next compatible interactive login. Inspect the result rather than assuming the command affected a remote LDAP or Active Directory identity.

Force a password change at next login

After assigning a temporary password, administrators commonly expire it immediately so only the intended user chooses the lasting secret.

sudo passwd --expire irfan
# Equivalent shadow-aging operation
sudo chage -d 0 irfan

At the next supported interactive login, the user authenticates with the temporary password and is required to select a new one that satisfies PAM policy. This workflow can fail over SSH when password changes are not supported by the client or server configuration. It can also break SFTP-only access, non-interactive automation, cron jobs, API integrations, and services that cannot answer a prompt.

Before enforcing the change remotely, keep a tested administrative session open and try the exact login path the user will use. Never apply interactive aging blindly to a service identity. Prefer non-password service authentication and a managed secret-rotation workflow appropriate to the workload.

How the password warning period works

sudo chage -W 7 irfan
chage -l irfan
passwd -S irfan

The warning is normally displayed during an interactive login within the configured number of days before maximum age is reached. It is informational: it does not change the password and does not guarantee that the user saw it. Console, SSH, display managers, desktop sessions, SFTP, and scheduled processes can invoke different PAM stacks or suppress interactive messages.

A user can usually run chage -l irfan for their own local record, while an administrator can inspect any local account. passwd -S provides a compact status. Organizations that depend on warning delivery should test each supported access method and supplement login messages with an accountable notification process.

Password inactivity is a post-expiration grace period

Suppose a password was set on day 0 and its maximum age is 90 days. It expires on day 90. With chage -I 14 irfan, the user has a post-expiration interval in which a compatible login flow may require the password to be changed. After 14 days, the account becomes inactive and administrator action is required.

sudo chage -I 14 irfan
sudo chage -l irfan

This setting does not mean “disable the user after 14 days without logging in.” It is tied specifically to the number of days after password expiration. Detecting dormant accounts requires login records, identity-provider data, application evidence, and an organizational definition of inactivity. It is also different from the absolute account-expiration date configured with -E.

Change passwords without exposing secrets

# A user changes their own password
passwd

# A privileged administrator changes another local user's password
sudo passwd irfan

A normal user is usually asked for the current password before choosing a replacement. Root can assign another user's password without knowing the old one, although PAM and distribution policy determine exactly which quality controls apply. When issuing a temporary password, use a secure delivery method and force a change at the next interactive login where appropriate.

Do not place passwords in command-line arguments, shell history, scripts, documentation, chat messages, tickets, CI logs, or public repositories. Command arguments may be observable to other processes and durable records spread secrets beyond their intended boundary. For automation, use a controlled secret-management system, short-lived credentials where possible, and a protected configuration-management workflow whose logs redact sensitive values.

Locking a password is not universal account revocation

sudo passwd -l irfan
sudo passwd -u irfan
sudo usermod -L irfan
sudo usermod -U irfan

On common shadow-utils systems, locking prefixes the password-hash field in /etc/shadow with an exclamation mark, making that local password unusable. Unlocking removes the lock marker when a usable hash remains. Never copy a real shadow entry into a ticket or article.

Password locking may not block an authorized SSH key, certificate, token, Kerberos login, external identity provider, existing session, or a sudo rule. Setting the shell to /usr/sbin/nologin prevents ordinary shell use for a different reason and may affect some services. Terminating existing sessions and processes is another separate action. Effective offboarding therefore inventories every authentication path rather than relying on one command.

sudo passwd -S irfan
sudo chage -l irfan
getent passwd irfan
id irfan

Verify the intended denial through a safe test account before modifying an administrator. Avoid unlocking an account with an empty or invalid password field; set a valid authentication method first.

Read password status output

sudo passwd -S irfan
sudo chage -l irfan

A typical passwd -S line includes the login name, password status, last-change date, minimum age, maximum age, warning period, and sometimes inactivity information. Common status codes include P for a usable password, L for a locked password, and NP for no password. Exact letters, fields, date formatting, and privilege requirements vary across distributions.

chage -l expands the aging record into readable labels such as “Password expires,” “Password inactive,” and “Account expires.” It reports local shadow information only. It does not prove that SSH permits password authentication, that PAM has no failed-login lock, or that an LDAP account is active.

Default aging policy in login.defs

grep -E '^[[:space:]]*(PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|PASS_MIN_LEN)' /etc/login.defs
sudo useradd -D
sudo chage -l irfan

PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE commonly supply defaults when new local accounts are created. Changing them usually does not rewrite aging values for existing users; update existing accounts explicitly after review. PASS_MIN_LEN may be documented in the file but is often not the effective password-length control on modern PAM-based systems.

Inspect before editing. Password quality is normally enforced through the active PAM stack, such as pam_pwquality, and not solely by login.defs. Defaults can also be influenced by /etc/default/useradd, account-management tools, cloud images, or organizational automation.

PAM, password quality, and password history

Pluggable Authentication Modules, or PAM, lets services use ordered authentication, account, password, and session modules. Debian and Ubuntu commonly compose password changes through /etc/pam.d/common-password. RHEL-family systems commonly use generated or managed stacks involving /etc/pam.d/system-auth and /etc/pam.d/password-auth. Editing these files incorrectly can lock out every administrator.

pam_pwquality can evaluate minimum length, dictionary matches, similarity, repeated characters, character classes, and other properties, with policy often stored in /etc/security/pwquality.conf. Password history may be enforced by pam_pwhistory. Policies should favor long, unique secrets and compromised-password screening instead of relying only on composition rules.

grep -R "pam_pwquality\|pam_pwhistory" /etc/pam.d 2>/dev/null
grep -Ev '^[[:space:]]*(#|$)' /etc/security/pwquality.conf 2>/dev/null

Back up the relevant configuration, use the distribution's supported management tooling, test with a non-privileged account, and keep a separate privileged session open. Never paste an unreviewed PAM recipe from another distribution or release.

Failed-login lockout is a separate control

pam_faillock can record authentication failures and deny further attempts according to policy. On systems that provide the faillock utility, administrators can inspect or reset a user's tally:

sudo faillock --user irfan
sudo faillock --user irfan --reset

# Inspect policy when this file is used
grep -Ev '^[[:space:]]*(#|$)' /etc/security/faillock.conf 2>/dev/null

A failed-login lockout is not password expiration, post-expiration inactivity, an account-expiration date, or an administrator placing ! before a password hash. PAM module availability, configuration locations, tally storage, root-account treatment, and reset behavior differ between Debian/Ubuntu and RHEL-family releases. Confirm that the relevant service actually uses the configured PAM stack before interpreting a zero tally as proof that authentication is healthy.

Files that hold local identity policy

/etc/passwd maps local usernames to UID, primary GID, comment, home directory, and login shell; its password field normally contains x. /etc/shadow contains protected password hashes and aging fields. /etc/group defines groups and supplementary members, while /etc/gshadow stores protected group authentication and administration data. /etc/login.defs supplies defaults used by selected account tools. PAM files determine how individual services authenticate and manage accounts.

Use supported commands such as useradd, usermod, passwd, chage, gpasswd, and distribution configuration tools. Do not manually edit passwd or shadow files for routine work. Restrict access to shadow data, never expose a real hash, and avoid copying these files into backups, tickets, or troubleshooting channels without appropriate protection.

Verify and troubleshoot login problems systematically

getent passwd irfan
id irfan
sudo passwd -S irfan
sudo chage -l irfan
sudo getent shadow irfan
lastlog -u irfan
getent group sudo
getent group wheel

Start with identity resolution: getent passwd checks the configured Name Service Switch rather than only the local file, and id shows resolved UID and groups. Then inspect password and aging status. Treat the output of getent shadow as sensitive because it can contain a password hash; view it only when necessary and do not paste it elsewhere.

If unlocking does not restore access, check account and password expiration, the login shell, the home directory's existence and ownership, SSH AllowUsers/AllowGroups rules, whether SSH password authentication is disabled, PAM failure tallies, access-control files, and directory-service policy. An LDAP, Active Directory, SSSD, or IdM account may not be controlled by local shadow commands. Also verify system time and timezone because aging decisions depend on dates.

journalctl -u ssh --since today
journalctl -u sshd --since today
sudo tail -n 100 /var/log/auth.log   # Debian/Ubuntu when present
sudo tail -n 100 /var/log/secure     # RHEL family when present
ls -ld /home/irfan
getent passwd irfan | cut -d: -f7

Preserve the first relevant error, change one variable at a time, and avoid weakening system-wide authentication merely to make one account work.

Practical lab: configure irfan on App Server 3

Connect to the actual hostname assigned to App Server 3. A training environment might call it stapp03, but do not invent or assume the server name. Confirm the host before creating the account.

hostnamectl --static
getent passwd irfan

sudo useradd -m -s /bin/bash -e 2027-02-17 irfan
sudo passwd irfan
sudo chage -m 2 -M 90 -W 7 -I 14 irfan

The initial lookup should return no line if the user does not exist. useradd creates lowercase user irfan, creates /home/irfan, selects Bash, and sets the account-expiration date. passwd securely assigns the initial password. chage requires two days between changes, expires the password after 90 days, warns seven days beforehand, and makes the account inactive 14 days after password expiration.

getent passwd irfan
id irfan
sudo passwd -S irfan
sudo chage -l irfan
ls -ld /home/irfan

Expected results include a passwd entry ending in /home/irfan:/bin/bash, matching UID/group information from id, a usable or appropriately locked password status, and chage values of 2, 90, 7, 14, and account expiration on 2027-02-17. Exact dates derived from the password's last-change date and exact output formatting will vary.

For rollback without deleting the user's data, use the commands in the next section. If this is a disposable lab and deletion is explicitly required, first inspect owned files and backups; user deletion is not the same as reversing aging settings.

Safe rollback commands

sudo chage -E -1 irfan
sudo chage -M -1 irfan
sudo chage -I -1 irfan
sudo passwd -u irfan
sudo usermod -s /bin/bash irfan
sudo chage -l irfan
sudo passwd -S irfan

-E -1 removes the absolute account expiration date. -M -1 disables the maximum password age on current shadow-utils implementations. -I -1 removes the post-expiration inactivity interval. passwd -u unlocks the local password where a valid hash exists, and usermod -s restores Bash as the login shell.

Rollback values and accepted syntax must be checked on the target distribution. A password may still be expired because of its last-change value, SSH may still reject it, PAM may retain a failure tally, or an external identity provider may impose another policy. Verify the complete access path after rollback.

Security recommendations for modern environments

Prefer long, unique passwords or passphrases, compromised-password screening, MFA where supported, and protected SSH keys for administrators. Disable direct root SSH login where the operating model permits it, remove unused accounts promptly, review privileged groups, conduct periodic access reviews, avoid shared human accounts, and monitor authentication events. Service accounts should have a named owner, minimal privileges, a non-interactive design where appropriate, and managed credential rotation.

Forced periodic changes are not automatically safer. They can encourage predictable modifications and written-down passwords. Current NIST guidance says verifiers should not require periodic changes without evidence of compromise, while organizations may still have regulatory or contractual rotation requirements. Align maximum age with the threat model, authentication strength, applicable obligations, and the capabilities of the systems involved. Change a password immediately when compromise is suspected.

Before changing PAM, preserve configuration, test on a non-production host, keep an authenticated recovery session open, and know how console access works. A syntax-valid policy can still deny every login.

Comparison table

Command cheat sheet

# Create and inspect
sudo useradd -m -s /bin/bash -e 2027-02-17 irfan
id irfan
getent passwd irfan

# Account expiration
sudo usermod -e 2027-02-17 irfan
sudo chage -E -1 irfan

# Password and aging
sudo passwd irfan
sudo chage -m 2 -M 90 -W 7 -I 14 irfan
sudo passwd --expire irfan
sudo passwd -S irfan
sudo chage -l irfan

# Locks and diagnostics
sudo passwd -l irfan
sudo passwd -u irfan
lastlog -u irfan
sudo faillock --user irfan
sudo faillock --user irfan --reset

The safe workflow is consistent: determine where the identity is authoritative, record its present state, make the smallest intended change, verify both configuration and real login behavior, and keep a tested rollback path. Account expiration, password aging, password locking, and failed-login controls should be combined deliberately—not treated as interchangeable synonyms.

Primary source and methodology

The factual starting point for this article is the current chage manual from the Linux man-pages project. LearnWithIrfan adds independent infrastructure, security, and operational analysis. The external source does not endorse this article, and implementation recommendations should be validated against current official documentation.