password encryption in /etc/shadow

vielmaj · 06-16-2009, 11:35 PM

I am moving my Linux server from Suse 10 to Ubuntu 9.04 and I moved the significant parts of /etc/shadow, /etc/passwd, and /etc/group over to Ubuntu 9.04. I am not able to login into the computer with the old accounts. The only problem I see is that the old accounts use Blowfish and DES to encrypt the passwords in /etc/shadow, and Ubuntu uses SHA512. If I change the passwords, the accounts will work. However; I have about 300 accounts to move, and I don't want to do that to all of them. I have tired Ubuntu Forums and talked to every linux expert I know, and no one has an answer. Could some point me in the right direction on how to fix this.

Thanks,

Jason

JulianTosh · 06-17-2009, 12:27 AM

I understand the quest for knowledge, but consider the time you're wasting trying to solve a unique problem that may never be raised again. It may be wiser to invest the time learning how to script the resetting of numerous account passwords automatically.

Just some food for thought.

vielmaj · 06-17-2009, 09:59 AM

I appreciate that you replied. I have put this on many forums and no one has given the same consideracy you have. You are probably correct and this is the same answer every linux expert I know has given me.

Quote:

Originally Posted by Admiral Beotch

I understand the quest for knowledge, but consider the time you're wasting trying to solve a unique problem that may never be raised again. It may be ewiser to invest the time learning how to script the resetting of numerous account passwords automatically.

Just some food for thought.

Disillusionist · 06-17-2009, 12:18 PM

A perl script to help automate resetting the passwords:

Code:

#!/usr/bin/perl
use strict;
my $SALT='$1$senThESlt45r$';

open(USERLIST, "userlist") or die "Failed to open userlist!\n";

while(<USERLIST>) {
   my($user, $pass)=split(/ /, $_);
   my $enc_pass=crypt($pass, $SALT);

   print("/etc/sbin/usermod -p $enc_pass $user\n");
   # system("/etc/sbin/usermod -p $enc_pass $user");
}

close(USERLIST);

The script expects a file userlist to contain two columns, seperated by a space:

The user to be reset.
The unencrypted password.

Once you are happy that the script is getting the correct details, remove the # that is commenting out the system call.

nuwen52 · 06-17-2009, 04:19 PM

I don't really recommend doing this, but couldn't you change the encryption method used on the Ubuntu machine to using DES? In the /etc/login.defs file maybe? Or would this not do what you want it to do? I've never tried this, so I am hesitant to do it on any of my current machines, because I already have them set up and don't want to kill the system. But, if it's a newly installed system that's not that much to reinstall, it might be an interesting experiment.

P.S. I have no idea if this would actually work or if there are other things you would have to change to make it work.

JulianTosh · 06-17-2009, 05:56 PM

That is, indeed, the $25000 question... 8D But, one could take that long academic journey to figure it out, or move on to more productive and useful things by simply changing the passwords.

jschiwal · 06-17-2009, 06:18 PM

The characters in shadow file between the two "$" signs indicate the encryption used. Apparently Ubuntu hasn't support for Bluefish; otherwise it would be possible to use the same passwd/shadow file entries. Another difference to consider is the range of UIDs used for regular users. SuSE starts at 1000. Are the UIDs brought over from SuSE in the range of regular user UIDs that Ubuntu uses? Look in /etc/login.defs. My guess is that they are, and you would more likely run into a problem had you gone from Ubuntu to SuSE.

nuwen52 · 06-18-2009, 06:50 AM

Quote:

Originally Posted by Admiral Beotch

That is, indeed, the $25000 question... 8D But, one could take that long academic journey to figure it out, or move on to more productive and useful things by simply changing the passwords.

Agreed. It's more of a curiosity. It doesn't look like it would work this time anyway. Well, good luck with changing over the passwords and getting the rest of the server moved over.