Fix the Linux Cron Error: “Authentication Token Is No Longer Valid; New One Required”

Your cron jobs stopped running, but the crontab has no syntax error and the script works fine by hand. If the system log shows “Authentication token is no longer valid; new one required”, the problem is not cron at all: the account that owns the job has an expired password. This DevAnswers guide resets it, shows how to find which account is affected, explains the PAM cause, and stops it from recurring.

The Fix: Reset the Account’s Password #

The job fails because the password on the account that runs it has expired. Reset that password as root and the job runs again (this is just changing the user’s password):

sudo passwd devans  # replace 'devans' with the account that owns the failing job

The new password has to satisfy the system PAM password policy (length and complexity) or passwd will reject it. If diagnosis below shows the account is locked rather than just expired, unlock it as well:

sudo passwd -u devans

Find Which Account and Confirm #

To confirm which account is affected, find the user the failing job runs as. Check the cron log; where it lands depends on your distribution. On a modern systemd system, query the journal (use the cron log for the full walkthrough):

sudo journalctl -u cron --since "1 hour ago"    # Debian/Ubuntu
sudo journalctl -u crond --since "1 hour ago"   # RHEL/Rocky/Alma

Older systems without journald keep cron messages in a flat file instead: /var/log/syslog on Debian/Ubuntu, or /var/log/cron on RHEL-family systems. If your distribution names the service differently (Arch’s cronie, for instance), systemctl list-units '*cron*' reveals the right unit to query. Cron fails quietly because it runs in the background with no terminal, so the only outward sign is usually a job that did not run. By default cron does not email these failures either, so a broken job can sit unnoticed for days; the log is the first reliable place to look. The log line names the user the job ran as. Confirm that account’s password status:

sudo passwd -S devans

The second field is the key one: P means a usable password, L means the password is locked, and NP means no password is set. On RHEL, Rocky, and AlmaLinux the passwd tool prints the equivalent PS for a usable password and LK for a locked one. For the underlying aging that caused it, list the account’s expiry dates:

sudo chage -l devans

Last password change          : Jan 02, 2024
Password expires              : Apr 02, 2024
Password inactive             : never
Account expires               : never
Minimum number of days        : 0
Maximum number of days        : 90

Two fields tell the story: Password expires is the date the password becomes invalid (set by Maximum number of days counting from the last change), and Account expires is the date the whole account is switched off. Once either date has passed, cron jobs for that user start failing. If Account expires is the culprit, the password reset above won’t be enough on its own; clear the account expiry too with chage -E -1 (covered in Stop It Recurring below).

Why This Happens #

This is an account-policy problem, not a cron problem. Cron jobs are subject to PAM, and the pam_unix account module checks the user’s shadow password-aging fields, such as expire and max_change. Once the password has passed its maximum age, that check fails and the scheduled job is refused with the authentication-token message, even though the command itself is perfectly valid. You can confirm the cause interactively: switch to the account with su - devans and an expired password either prompts you to set a new one or is refused with the same message, proving the problem is the account credentials, not the schedule. This most often bites dedicated service accounts that fall under an organisation-wide password-aging policy.

Stop It Recurring #

For a service or system account that exists only to run scheduled jobs, the durable fix is to stop the password aging that locked it out, not to keep resetting it by hand. The chage command (see the chage man page) manages that expiration policy. Disable the maximum password age so the account’s password never expires:

sudo chage -M -1 devans

If the account also carries an absolute expiry date, clear that too:

sudo chage -E -1 devans

Conclusion #

Re-run the job (or wait for its next scheduled tick) and re-check the log; the authentication-token error should be gone. If a user can log in interactively but their jobs or logins still misbehave, see why a correct password can still be refused.