Skip to main content

Forcing Linux system password changes with the chage command

Users are generally slow to change passwords. Here's how to nudge them into compliance.
Image
How to encrypt a single Linux filesystem

Photo by PhotoMIX Company on Pexels

Some of you may work in highly regulated industries, such as medical, government, government contracting, and food and beverage. You probably have strict guidelines for password aging, regular password changes, minimum length, complexity, and minimum time limits between password changes. Others of you might use equally strict guidelines simply because it's a good practice to do so. This article describes how to audit user accounts and set some guidelines around password expiration and change frequency. For the examples, I use the chage command.

[ You might also enjoy reading: Balancing Linux security with usability ]

The chage command is self-described as the "change user password expiry information" utility. According to the chage man page:

The chage command changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change their password.

Auditing user accounts

Periodic account audits are not only a good idea but, depending on your industry's compliance regulations, they could be a requirement. It's easy to check for password change requirements by using the chage command. Here's an example:

# chage -l jdoe
Last password change					: Apr 20, 2021
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

As you can see, auditing the jdoe user account yields an audit fail. The key indicators are that the user's password never expires and there's no minimum or maximum number of days between password changes. Some industry regulations require that passwords change every 45 days, while others dictate a 90-day change. And it could be that some enterprises and regulations require a 30-day change interval.

Expiring a user's password

Every client I've supported thus far has used a 90-day password expiration and a minimum number of days between password changes set to one. Setting a minimum number of days between password changes helps prevent a user from changing their password repeatedly until they can reset it to the previous one, bypassing system security. You can set this number to something larger than one. Some enterprises set the minimum number of days to seven.

# chage -m 1 -M 90 jdoe

# chage -l jdoe

Last password change					: Apr 20, 2021
Password expires					: Jul 19, 2021
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 1
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 7

The chage command expires the user's password 90 days from the last password change. So, if you last changed your password on January 15, 2019, it would expire your password with a date of April 15, 2019. This means if your expiration date is in the past, you'll be prompted to change it on your next login.

$ ssh jdoe@192.168.0.99
jdoe@192.168.0.99's password: 
You are required to change your password immediately (password expired)
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Sat Jun 19 10:46:27 2021
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user jdoe.
Current password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Connection to 192.168.0.99 closed.

Note that after the password change, the remote system disconnects the user. The user must reinitiate the connection to the remote system and log in with their new password.

The caveat and the cure

I've heard a lot of user and sysadmin arguments against setting a minimum number of days between password changes stating that it disrupts automated scripts. My response has always been, "Don't use passwords for automated scripts." The reason is that some users and sysadmins write passwords in plain text into those automated scripts, and that's a bad thing, even if they restrict a script's permissions to the user account that executes them.

The solution is to use SSH key pairs for automated tasks between systems.

[ Thinking about security? Check out this free guide to boosting hybrid cloud security and protecting your business. ]

Wrap up

This article gives you a quick overview of using the chage command to audit and expire passwords on the systems you manage. If you don't want to audit every account individually, I suggest you create a script to periodically check your user's accounts and expire those that don't comply with your security policies and regulatory requirements.

Author’s photo

Ken Hess

Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.