admin loses SSH access after backup/restore

J

jabbink

Verified User
Joined
Jan 24, 2012
Messages
5
Hi,

since today I am unable to login as admin on my CentOS 5.6 box with directadmin.

All other users work but I constantly get Access denied as server reponse (FlashFXP says [R] Authentication failed [Invalid Password]
[R] SSH Error: failed to negotiate authentication method
[R] SSH Connection closed)

I reset the password in directadmin (which works (logging in as well). Didn't help.

I logged in as another user, went up to root, executed "passwd admin" and set another password. Didn't work (even though the server said "passwd: all authentication tokens updated successfully.").

Any ideas?
 
A friend of mine solved it:
Something (I guess directadmin?!) removed admin from the AllowUsers part in /etc/ssh/sshd_config and changed /etc/passwd for admin to /bin/false instead of /bin/bash
 
Hello,

To clarify, that is the normal action DA does when the ssh option is removed from an account.
Ssh was likely disabled from the account.

John
 
That was not the case.
I did not remove it and nobody else logged in (or cleaned up all logs perfectly including the message that someone disconnected (from SSH)).

I tried to fix this (before I got the manual fix) by disabling SSH for the user admin. That did not work since SSH stayed checked.
 
Bumping this up because I encountered an identical problem on a Centos 6.2 install.

admin was unable to log in via ssh for the same reasons.

The only thing I can think of is that I did an admin restore from an existing DA server to this new one.

Did you do the same thing as well, Jabbink?
 
Hello,

The two things that would affect the admin login after doing a restore would be:
1) the admin password would be set to the value stored in the backup

2) the ssh setting set in the backup would determine if ssh is enabled or disabled after the restore.
So if ssh was disabled on the remote box, and you restore that admin backup to the new box, then ssh will be disabled for admin on the new box.

John
 
Hi, John,

DirectAdmin Support said:
Hello,
The two things that would affect the admin login after doing a restore would be:
1) the admin password would be set to the value stored in the backup
Click to expand...

As a standard precaution, I always use the passwd command to set the password for admin to what was supposed to be. This is because it seems that the password does not survive a backup/restore for whatever reasons.

2) the ssh setting set in the backup would determine if ssh is enabled or disabled after the restore.
So if ssh was disabled on the remote box, and you restore that admin backup to the new box, then ssh will be disabled for admin on the new box.
Click to expand...


The backups were on working DA installs before being transferred with working ssh access, that's what make it puzzling why the admin user shell was set to /bin/false instead.

I'll probably be doing a few more transfers/restore this weekend and will see if I can provide more information.
 
Problem confirmed

As mentioned in the previous post, I did another DA transfer today.

The new instance VM2 was installed with DA, then the DA created admin user had the password changed to the existing password used on VM1.

A restore to VM2 was done with the backup from VM1.

After restore, the admin password no longer works on VM2 and has to be reset again.
 
zEitEr said:
And what is wrong with that?
Click to expand...

Well, it is an unexpected behaviour and you get an unhappy customer whose admin account can't log in because the password is wrong.

Then after resetting it, they still can't SSH in because sshd_config had been reset to not allow them and they can't edit it because that file requires the root password.

So 3 things
1. admin password get changed to something unknown (as of this point)
2. ssh access denied, and cannot be enabled through DA panel because it's locked to a misleading "enabled" in the GUI despite the sshd_config.
3. no shell for admin even if they can get in via ssh because their entry in etc/passwd had been set to /bin/false for a shell.
 
Are you writing to tell us that the server is not behaving as posted by John from DirectAdmin Support, in posts above?

Jeff
 
nobaloney said:
Are you writing to tell us that the server is not behaving as posted by John from DirectAdmin Support, in posts above?

Jeff
Click to expand...

Neither Jabbink nor I are describing the situation John outlined

1) the admin password would be set to the value stored in the backup
Click to expand...

Same password used in both the old and new server. In other words, the admin password restored was not the one that should be in the backup.

2) the ssh setting set in the backup would determine if ssh is enabled or disabled after the restore.
Click to expand...

admin had proper SSH access on the old server, as well as on the new server until the backup was restored. In other words, either the backup did not store the correct SSH settings, or the restore did not put back the correct settings.

The admin password and SSH settings are either incorrectly saved or incorrectly restored.
 
zEitEr said:
With an account restore all it's settings get changed to those stored and restored from a tar.gz
Click to expand...

I think we all agree that should be the case and is the expected case, which isn't the case here.

Basically, the scenario is like this:

I logged into Server1 as admin with password1, made a backup and SSH into Server1 with password1, transferred the backup to a new Server2, then shut down Server1.

I log into Server2 as admin with password1, start the restore of that tar.gz.

I expected that after the restore, Server2 admin should still have password1 and should still be able to SSH.
 
And are the passwords encrypted with the same algorithm?

What do you see it on the both servers:
Code: 
grep ENCRYPT_METHOD /etc/login.defs

Code: 
grep ^admin: /etc/shadow | cut -d: -f2 | cut -d$ -f 2

?
 
zEitEr said:
And are the passwords encrypted with the same algorithm?

What do you see it on the both servers:
Code: 
grep ENCRYPT_METHOD /etc/login.defs

Code: 
grep ^admin: /etc/shadow | cut -d: -f2 | cut -d$ -f 2

?
Click to expand...

Thanks Zeiter!

That appears to be part of the problem, CentOS 5 defaulted to MD5 but CentOS 6 switched to SHA512.

So the remaining question is why did the restore process disable the SSH login? Does it check for valid login then disable SSH if it fails to log in?
 
So the remaining question is why did the restore process disable the SSH login? Does it check for valid login then disable SSH if it fails to log in?
Click to expand...

I guess you should run Directadmin in debug mode

The backups were on working DA installs before being transferred with working ssh access, that's what make it puzzling why the admin user shell was set to /bin/false instead.
Click to expand...

Make sure paths to shells on both server are the same and are working (/bin/bash). Nothing else comes into my mind.
 
emman said:
CentOS 5 defaulted to MD5 but CentOS 6 switched to SHA512.
Click to expand...
Is that going to be a problem when transferring accounts from a CentOS5 server to one running CentOS6?

If so, any ideas on how to resolve it besides issuing all new passwords?

Jeff
 
Ill test tomorrow a transfer between CentOS 5.8 and CentOS 6.2 on a test box and let you know (and also to DA Staff in private way) if any login-error occur.

Regards
 
You must log in or register to reply here.
Back
Top