You are not logged in.
In a fresh install of Arch, I created a new user, set its the initial password, then force the new user to change the password with
chage -d0 newuser.
However, when the user login with the default password, it would prompt "authentication token manipulation error".
I have searched online about this issue, but none of the solutions seem to solve my problem. The things I have tried include remount root directory with rw, check the properties of /usr/bin/passwd and /etc/shadow
How could I fix this?
Offline
Did you read the chage manpage? What does "0" mean?
You probably want the date to be maxdays before today, "forcing" the user to change the password *today* (or the account will be locked and you need root permissions to reactivate it) Maybe give the user more time, there's a setting for when to start to warn him as well.
You also might have to tamper w/ the timestamps of passwd and shadow (setting them before the lastday date) to make the situation plausible.
Is this for some sort of easy arch installation script?
Offline
I did read the man page but couldn't really understand what "set the number of days since Jan 1st, 1970 when the password was last changed" actually implies. Then I started to search for ready-made solutions online. For instance, this one:
https://www.tecmint.com/force-user-to-c … -in-linux/
What I want to do is the following:
I am setting up a public computer for a small group of people. Each person will get an account with a default password. The user is then forced to change the password with his personal one upon first login.
I have seen many such registration system with an password assigned to the user and then the user is forced to modify it immediately after first login. What is the right way to do this in Linux? Or is it a completely superfluous feature?
Last edited by ss (2019-05-21 05:01:48)
Offline
Just use "passwd --expire" for this. (The alternative would be to expire the password eg. tomorrow by setting the age and max days accordingly)
If you wonder why you're not getting a request to alter the password at a local getty, alter /etc/pam.d/login
…
account include system-local-login
password include system-local-login # ---> add this line
session include system-local-login
…
idk why it's not there by default (pending CVEs etc) but it's available in sshd, so assuming that a remote attack would be worse than a local one, it's probably safe to use.
Whether or not a fancy GUI login can handle that depends on how stupid the author of the fancy GUI is ;-)
Offline
Entering the issue myself I opened a bug for this.
Offline