6

I have a box being upgraded from CentOS 5 to CentOS 6. On the original server, all users have MD5 passwords. The upgraded server is now using SHA-512 passwords.

Users who have changed their password and have a SHA-512 password in /etc/shadow since the upgrade are able to use crontab successfully, but users who have not changed their password and still have an old MD5 password cannot use crontab. The error message they receive is:

Authentication service cannot retrieve authentication info
You (_username_) are not allowed to access to (crontab) because of pam configuration.

I've looked at /etc/pam.d/system-auth (you can too) but I'm not exactly sure what to tweak to permit access to crontab for users who have not yet changed their passwords.

I'm well aware that I can force everyone to change their passwords with chage -d 0, and users who change their password will regain access to crontab (and whatever else might be broken) but I have a few users where I need to edit their crontab before their next login, and using crontab -e -u _username_ as root also fails with exactly the same error as above.

Strangely, this issue didn't show up on my dev box; I've run into this on the staging box just prior to deployment. Users on the dev box with old MD5 passwords can access crontab just fine, and the /etc/pam.d/system-auth is identical. The dev and staging boxes are supposed to be identical, aside from their IP addresses. I suspect I've missed something really obvious and stupid...

So my question is, how can I enable access to crontab for users who haven't yet changed their passwords and been SHA-512 hashed? Or, how can I work around this issue?

Improve this question

3 Answers 3

Reset to default
10

I managed to fix this moments after posting the question.

It turns out that the /etc/shadow entries for the affected MD5 password users had somehow had the field after the hashed password duplicated, causing PAM to be unable to interpret the line. In other words, a bad cut and paste job.

I haven't had enough coffee...

Improve this answer
3
  • There's a tool called vipw that should prevent this kind of mistake. vipw -s edits the shadow file.
    – Ladadadada
    Jul 17, 2012 at 6:15
  • Unfortunately vipw (which I was using) doesn't prevent my wireless mouse from going nuts due to interference, low battery, or whatever was causing it to misbehave...
    – Michael Hampton
    Jul 20, 2012 at 5:11
  • Thanks for this. Simple solution to something I was way overthinking.
    – mattcaffeine
    Sep 7, 2014 at 4:23
1

I had this issue too and it turned out that /etc/shadow did not have an entry for that user. Using pwck added the user and the problem was solved.

Improve this answer
0

Had the same issues. If you do not need some exact password for account, just run:

pwconv
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .