Manage Linux Password Aging with chage

Learn how to inspect and configure Linux password expiration, warning periods, inactivity limits, and account expiration dates with chage.

Password aging is the set of rules that controls how long a password may be used, when it may be changed, when warnings appear, and what happens after expiration. Linux administrators commonly manage these rules for local accounts with chage.

Password aging can support security policies, compliance requirements, and account lifecycle management. It is especially useful when an account should expire on a known date or when users must periodically replace passwords.

Prerequisites: You should understand local Linux users, shell commands, sudo, basic date formats, and the difference between local and centrally managed accounts. See Bourne Again Shell Bash for shell fundamentals.

Password expiration and account expiration

Password expiration concerns the password. When its maximum age is reached, the user may be required to choose a new password. A warning can appear before that point, and an additional inactive period may follow it.

Account expiration concerns the account itself. After a fixed account expiration date, normal account use is prevented regardless of how recently the password was changed.

Setting	What expires	When it takes effect	Expected user experience	Administrative recovery action
Password expiration	The current password	After the maximum password age elapses	The user is warned beforehand and may be required to change the password at login	Provide an interactive password-change path or reset the password administratively
Account expiration	The account's ability to be used	On the configured calendar date	Normal authentication is denied even if the password is valid	Clear or extend the account expiration date if policy permits

The chage command

chage is the standard Linux utility for displaying and changing password-aging information for a user account. Its general form is:

chage [options] username

Administrative privileges are normally required when changing another user's settings:

sudo chage -l bob

Depending on local policy, a non-root user may be able to inspect or alter limited aging information for their own account. The exact permissions and behavior can vary by Linux distribution and identity configuration.

View current aging settings

Use -l to display the current password-aging and account-expiration status:

sudo chage -l bob

A listing commonly contains fields similar to these:

Last password change                                    : Mar 01, 2026
Password expires                                        : Mar 31, 2026
Password inactive                                       : Apr 07, 2026
Account expires                                         : Dec 31, 2026
Minimum number of days between password change          : 1
Maximum number of days between password change          : 30
Number of days of warning before password expires       : 7

Displayed field	Meaning	Common values	Related chage option
Last password change	The date used as the starting point for maximum-age calculations	A calendar date or never	`-d`
Password expires	The date on which the current password reaches its maximum age	A date or never	`-M`
Password inactive	The date after password expiration when the account becomes unusable because the inactivity period has elapsed	A date or never	`-I`
Account expires	The fixed date after which the account cannot normally be used	A date or never	`-E`
Minimum number of days between password change	The waiting period before another password change is allowed	A number of days, commonly 0 or greater	`-m`
Maximum number of days between password change	The maximum period for which the password remains valid	A number of days or never	`-M`
Number of days of warning before password expires	How early the user should be warned	A number of days	`-W`

Never means that no limit is configured for that particular field. It does not mean that all account-aging rules are disabled. For example, a user can have a password with no maximum age while still having a fixed account expiration date.

chage options for password and account aging

Option	Argument	Purpose	Typical effect	Notes
`-l`	None	List aging information	Displays password and account dates and day counts	Use after every policy change
`-m`	Days	Set minimum password age	Requires the specified wait before another change	`0` permits immediate changes
`-M`	Days	Set maximum password age	Password expires after the specified number of days	`-1` commonly removes the limit
`-W`	Days	Set warning period	Warnings begin this many days before expiration	Depends on the login and PAM environment
`-I`	Days	Set post-expiration inactivity period	Account becomes unusable after the password has expired for this long	`-1` commonly disables the inactivity limit
`-E`	Date	Set account expiration date	Account use ends on the specified date	Use readable `YYYY-MM-DD`; `-1` commonly clears it
`-d`	Date	Set last password change date	Changes the starting point for aging calculations	`0` commonly forces a change at next login

Set the maximum password age

The maximum password age is the number of days a password remains valid. Set it with -M:

sudo chage -M 30 bob
sudo chage -l bob

After the maximum age is reached, the user must change the password at the next applicable login. The resulting expiration date is calculated from the last password-change date. On systems supporting it, -1 removes the maximum-age limit:

sudo chage -M -1 bob

Set the minimum password age

The minimum password age defines how many days must pass before the user can change the password again:

sudo chage -m 1 bob

A value of 0 permits immediate password changes:

sudo chage -m 0 bob

A minimum age can prevent someone from changing a password repeatedly in quick succession merely to cycle through password history and return to an old password.

Configure password-expiration warnings

Use -W to set the number of days before expiration when warnings should begin:

sudo chage -W 7 bob

This requests a seven-day warning period. Warnings depend on the login method and PAM environment presenting them. A noninteractive authentication method may not display a message even when the value is configured.

Handle inactivity after password expiration

The inactive period begins after the password has expired. It is separate from the password's expiration date. Set it with -I:

sudo chage -I 7 bob

With this setting, the user may still have a limited opportunity to change an expired password. After seven days of inactivity following expiration, the account may become locked or unable to authenticate until an administrator intervenes. On systems supporting it, -1 disables the inactivity limit:

sudo chage -I -1 bob

Set an account expiration date

Use -E to set a fixed end date for the account. The ISO-style YYYY-MM-DD form is readable and suitable for examples:

sudo chage -E 2026-12-31 bob
sudo chage -l bob

Account expiration prevents normal account use regardless of password age. This makes it useful for temporary users or employees with a known end date. On systems supporting it, -1 clears the account expiration date:

sudo chage -E -1 bob

Set the last password-change date and force a reset

The -d option sets the date that Linux considers to be the user's last password change:

sudo chage -d 2026-03-01 bob

Setting the value to 0 commonly makes the password immediately due for replacement and forces a password change at the next interactive login:

sudo chage -d 0 bob

Use interactive mode

Run chage with only a username to walk through prompts for each aging setting:

sudo chage bob

Interactive mode is useful when reviewing and editing one account manually because the prompts show the available fields and existing values. Explicit options are preferable for repeatable administration, scripts, documented changes, and automation because the intended values are visible in the command.

How Linux stores aging information

Password hashes and local password-aging fields are typically stored in the protected /etc/shadow file, not in /etc/passwd. The local /etc/passwd file contains account identity information such as the username, user ID, group ID, home directory, and login shell.

Shadow aging fields include the last-password-change day, minimum age, maximum age, warning period, inactivity period, and account-expiration day. These values are represented internally as day counts, while chage -l presents them in a more readable form.

Administrators should use account-management commands such as chage rather than manually editing /etc/passwd or /etc/shadow. Manual edits can damage field alignment, permissions, or account access. For file and ownership fundamentals, see File Structure In Linux and Manage File Ownership.

An administrator can inspect the local shadow lookup for a user with:

sudo getent shadow bob

Do not expose the output unnecessarily: it may contain a password hash and other sensitive account data.

Practical policy examples

Apply a 30-day password policy with seven-day warnings

sudo chage -M 30 bob
sudo chage -W 7 bob
sudo chage -l bob

Prevent changes more often than once per day

sudo chage -m 1 bob
sudo chage -l bob

Disable an account on a known date

sudo chage -E 2026-12-31 bob
sudo chage -l bob

Clear accidental limits

Where supported by the system, use the no-limit value appropriate to the field:

sudo chage -M -1 bob
sudo chage -I -1 bob
sudo chage -E -1 bob
sudo chage -l bob

Do not assume that clearing one field clears the others. Verify each setting independently.

Safe administration and validation

Confirm that the username is correct and identify whether it is local:
```
getent passwd bob
```
Inspect the current values before changing anything:
```
sudo chage -l bob
```
Apply only the required option instead of overwriting unrelated settings.
Run chage -l again after every policy update.
Test the actual login path, especially when warnings or forced password changes are expected.
Record a recovery plan before changing accounts used by services, automation, emergencies, or multiple people.

Expiration policies can break daemon accounts, scheduled jobs, deployment tools, monitoring systems, and shared emergency access. Use an approved service-account policy or a non-password authentication mechanism where appropriate.

Also confirm that the account is actually local and has a local shadow entry. LDAP, Active Directory, SSSD, and other centralized identity systems may manage password policy outside the local chage data. In that situation, use the identity-management system that owns the account.

Troubleshooting

User does not exist

If chage reports that the named user does not exist, check the spelling and account lookup:

getent passwd username

The account may have been removed or may be supplied by a directory service rather than the local account database. Manage it through the owning identity system.

Permission denied or aging data cannot be updated

Use sudo or run as root when changing another user's settings. If that does not help, check whether the account files are read-only or whether another identity service controls the account.

The expiration date still says “never”

Run the listing for the exact account and verify that the intended -M value was applied:

sudo chage -l bob

A no-limit value may be configured, or the change may have been made in a different identity source. Reapply the intended value and check whether LDAP, Active Directory, SSSD, or another service governs the account.

The user does not receive warnings

Check the warning value with chage -l. The user may not yet be inside the warning window, the value may be zero or unset, or the login method may not display interactive PAM messages. Test the real login path, such as a console or SSH session, and review applicable PAM configuration if warnings should appear.

The user cannot log in after password expiration

Inspect all aging fields:

sudo chage -l username

The account may be beyond its inactivity period, past a fixed account expiration date, or waiting for a password change through an interactive login path. Adjust or clear the relevant setting only when policy permits, and provide an interactive reset path when required.

A service stops authenticating after a policy rollout

A password-aging rule may have been applied to a noninteractive service account. Because the service cannot complete a required password change, it may stop authenticating. Identify service accounts before bulk changes, restore access under change-control procedures, and verify the service after using an approved account policy or non-password authentication method.

Exam-relevant notes

-M sets maximum password age; -m sets minimum password age.
-W controls the warning period before password expiration.
-I controls inactivity after password expiration; it does not set the password's expiration date.
-E sets a fixed account expiration date, which is independent of password age.
-d 0 commonly forces a password change at the next interactive login.
-l lists current settings and should be used to verify changes.
/etc/shadow stores protected password hashes and aging fields; /etc/passwd stores account identity and login-shell information.
Centralized accounts may not be controlled by local chage settings.