:-$ 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
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 
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. 
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…
#!/bin/bash
for USR in $(users)
do
[[ ! -z $(runuser -u ${USR} -- \
gpg-connect-agent 'scd getinfo card_list' /bye 2>/dev/null \
| grep SERIALNO) ]] \
&& RST=1
done
[[ ! -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.
@Loki , I stumbled across this post you wrote: https://forums.puri.sm/t/expired-root-account/13249 .
I have the same situation: “Account expires: Jan 02,1970”
I don’t understand what this is meant to do/control - Which account will expire? And, when will it expire? And, what does the date of Jan 2, 1970 mean? And, most importantly, why does someone want it to expire?
I realize you show a way to “undo” that, but, what are the ramifiactions of doing that? Especially as it pertains to future application updates or OS updates?
I don’t want to just “fix” something that I don’t understand what is going on.
Thanks.
I only use my OpenPGP card in the L5 to decrypt stored passwords with the pass command, which is a shell script, and added at its end
gpgconf --reload scdaemon
which disables the card and the next use of it requires the PIN.
What exactly is the situation?
You are getting an error message in syslog?
You have a cron job that is not working?
You want to log in as root?
root
Jan 2, 1970 i.e. it has already expired and hence can’t be used.
Unix base date is Jan 1, 1970. Expiry is only configurable in whole days, hence a value of ‘1’ means Jan 2, 1970.
I can’t find any evidence that 0 is a special value for this field but perhaps there was some concern that some broken implementations might treat 0 as no expiry. Therefore with that safety measure Jan 2, 1970 is the earliest possible expiry date.
One of the basics of security is: don’t enable something that doesn’t need to be enabled / don’t allow something that does not need to be allowed.
Typically in the Debian family of distros, the root account never needs to be used - therefore it is disabled by default. That’s just good security - especially considering that root is all-powerful.
You weaken your security, either in theory or in catastrophic reality.
I don’t believe that unexpiring the root account will cause any functional problems, for future updates or for other purposes.
If you unexpire the root account, you must make sure that it has a strong password or that it does not allow password login at all (depending on what precisely the problem is). I believe that the root account out-of-the-box does not allow password login at all (has no valid password) so it is relatively safe to unexpire the root account provided that you verify on your phone what I just said about the password. Not allowing password login at all is probably safer than having a strong password unless you need to log in as root using a password.
Ideally you also ensure that components like sshd, if installed, are configured to disallow or at least restrict root login - unless you specifically really need it. I believe that the default for sshd is to prohibit password login for root but that is not maximally secure. I would change that to ‘no’ unless you really need it.
@irvinewade , Thanks, you addressed my concerns.
I did not have any problems. I now see that my issue was that I misunderstood the inactivation of the root account. I thought the fact that it was inactivated was some kind of mistake in the design of the phone’s OS. Your explanation cleared that up for me.
@irvinewade has covered it pretty well.
The only thing I will add is more of a general update, I moved from Amber to Byzantium a good few months ago and took the time to convert my cron jobs to systemd units with timers. Systemd appears to function fine and does not complain about the expired root account so I have left the root account in an expired state with no problems so far.
I use the card for a number of things so tacking it onto the end of a script or creating a large number of wrapper scripts to circumvent the issue is not really an option for me.
Back in September I was pointed to the idea of restarting scdaemon through gpgconf as you are doing rather than restarting pcscd so the cron job was recreated as a systemd user service triggered by a timer which is working for me.
To reset this, you’ll need to first add a root password:
Command:
sudo passwd root
Then edit with sudo the /etc/shadow file.
Command:
sudo nano /etc/shadow
Find the root entry line, and at the very end you’ll see a numerical value (The very last one), carefully delete it, and be extremely careful not to delete any ‘:’ colon characters or you could ruin your system forever until you reinstall the OS. ONLY REMOVE THE LAST NUMBER!
The tail end of the root line should have like 3 ‘:’ colon characters with nothing in between.
Save file, and log in as root.
This will help someone, and you’re welcome!
Now, in before the “THIS ISN’T SECURE” bullshit. People wanted a Linux phone and are smart enough to use it and configure it, if they aren’t smart enough, go use android or iPhone. I and others using this platform want control over their devices and this is how you maintain it, not with this locking down root BS. Now, that being said, I will say that you will need to set a very strong root password, probably stronger than you’d use on a desktop as if root were to be gained on your personal phone with access to all sorts of information it would be bad.
If you like, you can always re-edit the /etc/shadow file and re-add the same number that you deleted (In the same place it was originally) after doing your business with root, and it will put back what was there already, and prevent root accounts from being used by anyone including you again, thus locking down the account again.
To any nay sayers on this, it is NOT ACCEPTABLE to lock down root without users consent on this type of phone, no matter what the security requires. This is not why people buy this phone.
I will also note that editing the shadow file, if you fail at syntax you can lock yourself out of your device forever, so take caution. You are a Linux user, you like to configure things. I’ll remind everyone the Linux mantra “With great power comes great responsibility” You own your device, including any mistakes or data loss you create. Enjoy!
You are right its not acceptable to do this.
You can have the same password too… or have a second or third user in your sudors and wheel group to become root with only the knowledge of its (secure!) user password.
Its all better as what your are doing. This is a danger to your security and system. Cause a evil process, application/program or social engineering can highjack your system for root privileges… you know.
Have backups or a unique root password too, and you will have a second or third Layer to get back to your information.
Edit: I just want to say: Have another normal user for root access via sudo, one with a different password and you do not daily use. Brings up more secure, but less administration comfort for your daily user. You have some good aspects of doing it right nikitis, but they have some leaks too, like everything has.
An evil process can also bruteforce sudo passwords just as easily as root ones, and would give the same access. The reason working as root is nice is so you don’t have to hand type ‘sudo’ before every program which can be a pain on a phone. (You could ssh into it once you set that up and work that way). But using linux is also being able to run as root. Yes there are security measures to take like, don’t leave your machine while logged on as root etc. But the danger really isn’t anymore with root than with sudo only. I’m not suggest people log on as root as the main user of their phone, but for a development session, opening up a bash session as root from the user is acceptable and not any less secure.
Another benefit to developing as root user too is browsing root directories for logs and troubleshooting. When a user doesn’t have permissions to view a simple ‘ls’ lookup in a root directory as sudo fails to work as one would like it to. as root, I can ls all day long and see those files in a root level directory.
You have to see the user with less privilege as a secure. Like if you do rf command and you will not want to systems files deleted. Do not trust yourself, or like the user one, cause it can be controlled by someone else is just feature for security and digital hygiene. Like a Backup. Or like the possibility to see a encrypted package passing the network, for evil snitching code.
The Zero Days nightmare can overwhelm you like a tsunami every Time. But you should prepared for the small one too and include some more steps for an attacker as, you mentioned. One user without Sudo is fine if you can use it in daily use and you have limited the sudo trys and ban someone after fails, that will enlarge an attackers brutforce time. Plus you will see it in your logs.
I am not sure what i would do on my Librem5, i think i would use ssh and “sudo su” for administration investigation every time. You can just leave a shell season open with tmux (new stile) or screen (old one) too.
On some modern Systems you have the -1 Ring/Layer for virtual Systems or machine Code/CPU instructions on Firmwarelevel (Like Intel or AMD), too. I just want to say: Just have encryption backups of important Data and safe as less data as possible on your active using system
Just use sudo -i
There is no need to have an enabled root account for that to work.
Don’t edit /etc/shadow - just use the chage command as shown in the OP!!!
Also, “forever” is a long time. If you did totally mess up that file so that password authentication became impossible (hence can’t log in either directly on the device or via ssh) then you would boot JumpDrive and use that to fix up the file (preferably restore file from backup but, failing that, restore factory default file or repair the file as best you can, sufficient to allow logging in again).