effing linux: /etc/shadow out of sync with /etc/passwd

[Underpants?]

Strange, strange, strange request this week, custom removal of users for UID number sequence preservation. Had to clean the group, passwd and shadow files.

Am now getting the feeling that shadow and passwd are out of sync.

This is what happens when setting passwd for newly added users:
passwd: Authentication token manipulation error
perms look right:
-r-------- 1 root root 1.5K Jul 16 15:40 /etc/shadow
google doesn't like me tonight
Existing logins still work. Missing something here, i just know it. Reboot is not an option at this point.

Tried chattr -i on the file, re-running the passwd command and sweet mother buttpunch, it still didn't work.
Missing something, and it's probably stupid ey

edit: Odd to note that if the shadow file logins are forcefully added to match the passwd file, followed by like ::::: or something (no ws), system will allow password updates. This doesn't address the foreseeable future problem of new account creation, though.

[^misantropia^]

Remove /etc/shadow (or better, back it up) and run `pwconv` to regenerate it from /etc/passwd

[Underpants?]

Thanks for the suggestion misant. Not really keen to attempt it, unless it's a last resort though. From what I understand, this replaces the actual password hashes with fuzzies. though it'd be easy enough to immediately passwd root after running pwconv, it's still too risky. See, this being a remote bastion host, to which we connect from halfway across the nation with high latency, the session is prone to time out drops. It's also a prod machine which manages 120+ accounts.

[^misantropia^]

Ah, I can see how that puts you in a somewhat awkward position. But if you use ssh public/private key authentication and `screen`, you can always login again and pick up the session with `screen -x`. 15 seconds, and you are up & running again.

[Underpants?]

OK, nice...actually we do use keys for admin accounts, customer accounts are daemon-specific with shell access set to nologin. I suppose there's a password database floating around somewhere with the account info, so I can manually re-passwd those.
So, what about the chrooted service-based entries? This machine runs nagios,and a few other centralized management services?
Fuck me. This is the point at which I go get into an all-out mod_auth_mysql / auth_db brawl with the guys who call the shots.

[^misantropia^]

So, what about the chrooted service-based entries?

What about them? They have their own passwd files (as in /path/to/chroot_jail/etc/passwd)?

Fuck me. This is the point at which I go get into an all-out mod_auth_mysql / auth_db brawl with the guys who call the shots.

Centralized authentication is nice until your database server goes offline / you lose connectivity / etc. I've burned myself with that in the past.

[Underpants?]

right--thanks, much appreciated.