I'm currently migrating a CentOS environment to a Debian one. The users log in over the network using NIS. I was hoping to copy /etc/shadow
from my old server to my new one so that we can offer continuity to the users. I discovered two problems with it:
- User ID conflicts This is easily resolvable by adding 500 to the UIDs in the CentOS
shadow
file since CentOS started UIDs at 500 while Debian starts them at 1000. - Different password hashes This is what's killing me. It seems CentOS hashes its passwords with
md5
while Debian usessha-512
. I would like to have the users be able to log in to the system without having to consult me.
An acceptable solution I found after some Googling was as follows:
passwd -d uname
chage -d 0 uname
The first line sets an empty password for the user uname
so they can login directly. The second line causes uname
's password to expire so that they're forced to change it on next login. I figure this is a good enough compromise.
This is all well and good if the user logs in on the server. It does not work if the user attempts NIS authentication from a different box. They still get the message of "Password change required" but it's immediately followed by "Authentication Token Manipulation Error"; which, I'm guessing, is due to the fact that the password change is attempted via passwd
rather than yppasswd
. So this is the pickle I'm currently in. How can I achieve continuity without awkwardly forcing the users to first log in on the server?
EDIT
- This is similar to what I'm talking about; except it makes no mention of NIS.
- This seems to suggest that it's actually impossible. Can anyone refute that or confirm it?
EDIT 2
I just noticed that when users try logging in on the server, they can do so normally without error messages. On a different box (to test NIS), I switched to root then tried su
'ing into one of the NIS users. It succeeds while giving me a warning that says "Authentication failed (Ignored)". I'm guessing this comes from the PAM policy chain.
$x$
prefix to represent the hash by a numberx
, so perhaps just adding/correcting that would have been enough.md5
rather than Debian'ssha-512
: the Debian hashes are significantly longer and the method therefore didn't work when I tried.$x$
actually refers to the hashing algorithm So it stands to reason that if the$x$
's are different between 2 distros then they are using different hashing algorithms and (obviously) producing different hashes that can't just be fixed by changingx
. More info on the numbering of algorithms here