Final Edit: It appears Debian 11 drops MD5 password compatibility. This can be a problem with some old accounts where passwords haven’t been updated for decades. I’m working on a system with passwords from dial up days.
SYSTEM INFORMATION
OS type and version
Debian 11
Webmin version
2.013
Virtualmin version
7.5
Related packages
Batch Import
Importing user accounts via batchmin is creating the accounts but authentication fails when I try and access them.
Best info I have so far is from this
A password that I’m trying to import is identical to the same password in the shadow file I have on my home machine and has the prefix $6$7GqJ63Au$.
The same password created on the Debian 10 server, upgraded to 11, has the prefix $6$75737138$ and what follows is different.
My home machine, Debian11 upgraded I don’t know how many times recreates the new password with a prefix of $y$j9T$ and what follows is different.
Only thing I see in the logs is auth failed. This is a password I’ve used for a while so not likely I get it wrong every time. But, I’m well burnt toast at this point.
So, my home system can still read the old version. Any clues as to why my new server can’t? Both are upgraded to Debian 11. Searches mostly have hundreds of article on how to change your password. That link above was the only thing close to helpful so far.
Passwords are always hashed differently each time, by design. i.e. every time you run passwd, it will produce a different hash even for the same password. This is because it uses a unique salt, each time (salt is a string that is combined with the password when hashing…this mitigates the risk of rainbow tables, and makes the password database harder to crack, even if exposed).
That said, if you copy the entire hash over to another system exactly, it should work on the new system, too.
Like I said. The password for the same ‘word’ created the same hash on two different systems. The old Linux server and my home server. To test the migration I chose a site broken by the cPanel to Webuzo migration and created a user with one of my commonly used passwords for testing. Trust me. It produced the same hash as on my home computer.
I worked briefly for a company where we would set up accounts for developers when we set up new servers by doing the copy and paste. According to the docs I linked to the prefix is probably the clue here. I’ve just had a decent break and will look again to make sure I haven’t done some stupid typo. (I learned to type on a manual typewriter prior to computers. There was no 1(one). Lower case L was used. I once reverted and used the lower case L in a variable. That took me awhile to figure out. Now I make sure to use a developer friendly font on my systems. )
I only have the Webuzo backup of the site I am trying to migrate from. It provides the usernames and passwords hashes for the email accounts. That’s where I got the hash from. I copy and pasted the value from the backup file into the batch user window and chose ‘already encrypted’. I only did one user because I wanted to test it. (I set username:realname:password:ftpto1:emailto1:unlimiteddisk0 I think was the format? ) Maybe I’ll try it in a file and see if that makes a difference. But the shadow file looks fine so I don’t know.
But basically, I’m dead in the water in terms of migrating off of Webuzo if I don’t get past this.
Temps are approaching 70F here for the first time since last fall. Maybe a long walk will help clear the clutter before I try and get back to this.
This gets uglier. Some of these accounts are ancient and have all kinds of files carried forward. One labeled “email” looks like it might be the Webuzo data.
Old account looks like this:
“fred@blank.org”: {
“emailuser”: “fred”,
“domain”: “blank.org”,
“email”: “fred@blank.org”,
“home”: “/home/oooo/mail/blank.org/fred”,
“password”: “$1$TvhsETaY$/dppIOjpPrvl3r8TnNi3//”,
“quota_limit”: 10485760
One I updated recently seems to have a different format for the password that doesn’t look like a system one:
“ted@blank.org”: {
“emailuser”: “ted”,
“domain”: “blank.org”,
“email”: “ted@blank.org”,
“home”: “/home/oooo/mail/blank.org/ted”,
“password”: “0efc9165f0d70d250564577d9b3e2198acf25887”,
“quota_limit”: 1048576000,
“login”: “allow”,
“incoming”: “allow”,
“outgoing”: “allow”
That is not a Linux password hash. I wouldn’t know what to do with it.
If you can’t get the passwords in a Linux system password form, you’ll have to just reset the password to a new one. (I mean, if it’s a weak hash, maybe it can be recovered via brute force. Not something I could help with, though.)
Not sure if that’s for efficiency or vendor lock in purposes. I can get a free license so it might pay to spin up a server for a short time and import an account and see if there is anything behind the scenes I can work with. And no email all users to tick either to alert customers. Not that I don’t get enough scam emails about resetting my password now.
This started as a ‘get my stuff off this crap’ and that part won’t be hard. I have about 7 domains, of which I probably only ‘need’ 3. And really, the client accounts haven’t been my responsibility for a decade now.
I wonder if this could be some sort of database hash? I can see the case of storing email login records in a DB instead of the being an actual system record. Maybe I should see if there is a related DB dump related somehow. DB is my weakness but I do know DBs can encrypt storage.
Still I doubt there would be that many password changes since the change over, but still…
OK. This gets uglier. I moved the first site that needed to really use the batch import. The there were two non-system passwords. I set those up first with a password ‘single user’. Moved the mail into place. chown -R and life is good. My home system logged in and synced just fine.
Next were the system password accounts. No love. Even having Virtualmin open the account, after a loooong wait I see:
So, even the automatic login doesn’t work. The strange thing is, no auth error in the logs. I did a grep -ir on the user and it shows the stuff you would expect from setting up the account and the initial email sent. Then, nothing.
As I said way back, if all you have is hashed passwords, Virtualmin can’t possibly know them. Obviously it can’t do anything that requires passwords. Usermin, by default, is configured to get mail via IMAP and it needs a password to do that (even though it’s logging into the “same” server Usermin is running on). If you want stuff that requires passwords to work, you’ll have to reset them. If you know the password, you should be able to log into Usermin directly, and configure the IMAP password so that it is correct.
There are several other things Virtualmin can’t do, BTW, unless and until you reset passwords to inform Virtualmin of what they are. Database passwords will be a mystery, for instance. Any hashed password is an unknown password to Virtualmin, so anything that Virtualmin would need to know a password for will not work.
I’m starting to research to see if this algorithm is deprecated. I found some sent mail from 2006. VMin logs into the accounts I do one at a time and set the passwords. Is it storing them? Lack of errors is puzzling too.
Well, on the ‘bright side’, I email 388 accounts and asked them to respond if they still used the email account. The original software didn’t manage anything and people had to remember to take them out. Provided the customer told them all of the ones they had. (This goes back to dial up days). A whopping 3 people responded so far. That was the one account I was most worried about. Others with a more modern hash might go better. I hope.
Might also explain why Webuzo can auto log in some accounts from the interface and some it can’t. Might be a good test going forward on accounts I have to worry about.
But we are talking about software that changes the backup server password every time I log in and fails if you don’t delete the directory it is set to backup too because it will fail if it can’t create it. Gotta think their customers don’t value backups.
Thanks for your replay. Problem I have $1$(MD5) and $6(SHA512) hashes in /etc/shadow. New passwords are obviously created with SH512 hashes. However users with MD5 hashes cannot login (login incorrect) –
Paweł
)
