1

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 uses sha-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.

12
  • 1
    The handling of password hashes is not that different among Linux distributions, you should have looked at the mechanisms used (and how to represent which has is in use). AFAIU, some use a $x$ prefix to represent the hash by a number x, so perhaps just adding/correcting that would have been enough.
    – vonbrand
    Mar 23, 2013 at 12:26
  • Interesting note. The CentOS release was, however, ancient (I think <=5) so it used md5 rather than Debian's sha-512: the Debian hashes are significantly longer and the method therefore didn't work when I tried.
    – Joseph R.
    Mar 23, 2013 at 12:46
  • @vonbrand After some reading, I found that the $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 changing x. More info on the numbering of algorithms here
    – Joseph R.
    Mar 23, 2013 at 16:53
  • Are the passwords actually a problem? Debian should support CentOS's hashes. It's only the other way round that might be a problem: supporting newer hashes on an older distribution. If you do nothing, are the users able to log in? If they aren't, what error messages appear to the users and in logs?
    – Gilles 'SO- stop being evil'
    Mar 23, 2013 at 20:50
  • @Gilles I actually "did nothing" and the users weren't able to log in. They get a normal "Authentication Failure" error as if they'd typed a wrong password. Interestingly enough, when they try logging in on the server, it works! Updating the question...
    – Joseph R.
    Mar 23, 2013 at 20:51

1 Answer 1

Reset to default
0

It wasn't a matter of re-hashing passwords at all. All I needed was to modify my old /etc/group so that it has group IDs starting with 1000 and the users could log in easily using their old passwords as some commenters have guessed.

You must log in to answer this question.

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