Expired root account

:-$ sudo su -
Your account has expired; please contact your system administrator
su: Authentication failure

I stumbled across this when investigation a non-running cron job that I dropped into /etc/cron.d/.

Checking ‘sudo chage -l root’ shows ‘Account expires : Jan 02, 1970

I have addressed the issue by setting the root account to never expire with…

sudo chage -E -1 root

1 Like

I get “account root has expired” errors once an hour, at 17 minutes past the hour. It looks like this in the journalctl log:

Apr 28 11:17:01 pureos CRON[3817]: pam_unix(cron:account): account root has expired (account expired)
Apr 28 11:17:01 pureos CRON[3817]: Authentication failure
Apr 28 11:17:01 pureos cron[497]: Authentication failure
Apr 28 12:17:01 pureos CRON[3889]: pam_unix(cron:account): account root has expired (account expired)
Apr 28 12:17:01 pureos CRON[3889]: Authentication failure
Apr 28 12:17:01 pureos cron[497]: Authentication failure
Apr 28 13:17:01 pureos CRON[1567]: pam_unix(cron:account): account root has expired (account expired)
Apr 28 13:17:01 pureos cron[495]: Authentication failure
Apr 28 13:17:01 pureos CRON[1567]: Authentication failure

That’s parts of the output from the sudo journalctl --since today command.

I did not create any cron job myself, as far as I know.

I would like to find out what the cron job is that it is trying to run, and who is doing that. I tried these commands but that just gives “no crontab”:

purism@pureos:~$ crontab -l
no crontab for purism
purism@pureos:~$ sudo crontab -l
no crontab for root

If anyone has ideas on how to find out more, please let me know. This is for amber-phone.

The root account is intentionally configured to be expired. sudo -s gives you a root shell.

The cron issue is known:

Of course if you don’t want your root account to be expired, you’re free to reenable it on your device :slight_smile:

See ls /etc/cron.* - cronjobs can also live there as separate files.


Thanks @dos – I see now that I have this line in /etc/crontab:

17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly

So probably the “17” there explains why something is happening at 17 minutes past every hour.

Great, then I will not worry more about this for the moment. Thanks again.

Just comment it out. There is nothing in cron.hourly anyway and in that case your battery doesn’t need the hourly wake-up in order to get an error.

Some vendors like to desynchronize the cron jobs across the customer base rather than having the entire customer base, or some large section of it, doing the same thing at the same time. (This applies not only to hourly, but most importantly to hourly, but also to daily, weekly and monthly.) Maybe Purism doesn’t have the scale to have to worry about that at this time.

This is default out-of-the-box behaviour. You have lots of cron jobs.

Make sure that the password is not empty in that case. I think it will be secure out-of-the-box but people, particularly Linux users, do like to tinker. :wink:

1 Like

Good to know and thanks for the link, I did have a look there, not sure how I missed it, it even has “Expired root account” in the issue title.

I did check that and it does have a password on it.

Maybe I’m missing something very obvious and simple, the issue I am attempting to work around is that the smartcard appears to be caching the PIN, or some such similar with the same affect. As far as I can tell it is not a simple case of gpg-agent caching as is common with passphrases.

When you first hit the smartcard you are prompted for your PIN. However, for the remainder of the login session all subsequent key requests go straight through without any prompts for the PIN, there seems to be no easy way of clearing the PIN or disabling that behaviour. So, if someone gets a hold of your phone they will be able to sign, encrypt, decrypt and authentic as you unchallenged for as long as they don’t switch off or logout.

In most standard laptop/desktop scenarios using smartcards or USB tokens you can simply remove/reinsert the card/token as they are truly and easily removable, it’s mildly annoying to have to do so but easily done. Although the card as fitted in the Librem 5 is removable, the fact that you have to remove the back then the battery to get to it means removing/reinserting isn’t really an option, nor is logging in/out or rebooting practical.

The best I have come up with so far is to setup a cron job to check if the card has been used and if so restart the pcscd service. To restart the pcscd service requires root privileges so seems that running the cron job as root makes some sense? Prior to the phone, I’ve had very little exposure to sudo, it doesn’t seem like the a good solution to use sudo in an automated script, even though it’s currently password less on the phone, that could change?

If there is a better or easier way to do this, let me know. This is what I have so far…


for USR in $(users)
  [[ ! -z $(runuser -u ${USR} -- \
          gpg-connect-agent 'scd getinfo card_list' /bye 2>/dev/null \
        | grep SERIALNO) ]] \
       && RST=1

[[ ! -z ${RST} ]] && systemctl restart pcscd

exit 0

This gets called from a cron job and basically just checks if the card is listed and resets pcscd if it is. Resetting pcscd seems to provide the same result as physically removing/reinserting the card would have.

Although the phone is single user at the moment, this works for me good enough that I suspect I’ll forget all about it and without accounting for the possibility of multiple users now, the script would fail if/when multi-user support comes to the phone.

As far as I can see, the card only shows up in card_list when it has actually been used and it is the only way I could find to determine if the PIN is likely to be cached.