I have an machine, running OpenSUSE, that I'm using as a cluster server and as login server, and another machine runing Debian Etch r2, that will be the new server. I have installed everything in the Debian machine and copied the /etc/passwd and such from the OpenSUSE machine. Then, I've noticed something very weird: seems that the way of managing the users passwords are different. I mean, the root password is the same in both Debian Machine and OpenSUSE machine, but when i give it a look, the shadowed password is somewhat different. What is happening? Do I have to make any conversion to make the user account files work in the Debian? There's any tool or way to do it?

Hi.

It's because the hash is salted (the first 8 characters after the "$1$'), so it's unlikely that you'll have the same hash value in shadow for two accounts with the same password. Should work just fine with no intervention.

http://en.wikipedia.org/wiki/Salt_(cryptography)

Dave

I was looking into the suse shadow file, and some passwords isn't $1$, but $2a$10$ that comes in the beginning. What it means? I can't figure out, and the man pages tells nothing about $2a$10$.

Thanks.

I recently readed that SUSE uses blowfish, and debian/ubuntu uses md5 for encrypting the passwords... Im googlein for it, but if you have a solution, please post.
Thanks.

Depending on how PAM (I think it's PAM that controls the hash type anyway) was compiled on SuSE, you may be able to change the hash type in authconfig to MD5, and make it compatible with your existing MD5 shadow files.

WARNING: I'd research this thoroughly before implementing, as I'd imagine that changing the hash type to MD5, but still having Blowfish hashes in /etc/shadow might stop you logging into the box.

Dave

Each password-entry is of a recognizable format that tells the system how the password-value is encoded.

The entry also includes some "salt." This is a purely-random value that is injected into the value, along with the password. The "salt" value is then provided in the password-file as clear-text. What the salt does is to inject some deliberate entropy into the mix so that there is no longer a one-to-one correspondence between "a particular password" and "its encrypted equivalent." If the salt were merely a 32-bit integer, there would now be more than 4 million ways to hash the same password, and every one of the hashed values would be radically different.