Encrypted password for Unix user [namehere] does not match virtual server

When running 'Validate Virtual Servers', 20 out of 160 virtual servers have the following error:

Administration user : Encrypted password for Unix user [namehere] does not match virtual server

What steps should I take (details appreciated!) to fix this?

Status: 
Closed (fixed)

Comments

That's odd, it seems like the virtual server's Unix passwords were changed outside of Virtualmin, perhaps from the command line.

The fix is to go to the Edit Virtual Server page for each domain, change the password to something different, then change it back again.

To prevent this from happening in future, don't use the 'passwd' command or other non-Virtualmin methods to change passwords..

SoftwareLibrarian's picture
Submitted by SoftwareLibrarian on Sat, 06/27/2009 - 07:22 Pro Licensee

Thank you for the 'fix' information. However, fwiw, command-line actions were NOT used to change any passwords (other than the root password).

Automatically closed -- issue fixed for 2 weeks with no activity.

I've got the same problem. Changing password doesn't help. The password for this account wasn't changed outside virtualmin. Ha, it wasn't changed at all. I tried to restore the virtual-server on another server. Any other clues?

expro - does changing the password within Virtualmin to something different and then changing it back again help here?

Could you post the line from the /etc/shadow file for that user? I'd like to see what encryption format is being used..

User's information are stored in LDAP:

# getent passwd foo.com
foo.com:*:1010:1011:foo.com:/srv/www/foo.com:/sbin/nologin

In "LDAP Users and Groups" the password on the primary server is:

{ssha}c8hNDUwE2uGHifAi54DxcyRrKDvC8QKt

and on the backup server (after restoring virtual-server) it's:

{ssha}au+8YGbLZZ6vpYHaU01lEYnM4tEWOUxW

Ok, this is really a false warning from Virtualmin - when LDAP ssha encryption is being used, it has no way to re-hash the password with the same salt to verify the match. I'll fix this in the next Virtualmin release.

Automatically closed -- issue fixed for 2 weeks with no activity.