admin loses SSH access after backup/restore

I did a quick search with Google in order to find what is the default encryption method for CentOS 6, but I didn't find anything. So my guess would be MD5 is still the default, and here is a guide on how to change it:

http://www.cyberciti.biz/faq/rhel-centos-fedora-linux-upgrading-password-hashing/

Note, I still mostly use CentOS 5, and have CentOS 6 only as a testing environment. And one thing came to my mind and I remembered that I also moved several accounts from CentOS 5 to CentOS 6 and had none issue with passwords.
 
I just checked /etc/login.defs on several servers running CentOS 5 and CentOS 6.

The last lines of the /etc/login.defs file on one system running CentOS 5.8:
Code: 
# Use MD5 or DES to encrypt password? Red Hat use MD5 by default.
MD5_CRYPT_ENAB yes
 
ENCRYPT_METHOD MD5
The last lines of the /etc/login.defs file on another system running CentOS 5.8:
Code: 
# Use MD5 or DES to encrypt password? Red Hat use MD5 by default.
MD5_CRYPT_ENAB yes
My guess for the difference is the subversion with which the sysem was originally built.

Here the last lines of the /etc/login.defs file on another system running CentOS 6.2:
Code: 
# Use SHA512 to encrypt password.
ENCRYPT_METHOD SHA512
But when we built this last system we used admin level Backup and Restore to move sites from an old server running CentOS3 or CentOS 4 (I forget which but definitely old) to new server running CentOS 6. And they just worked.

So more testing is required. Can anyone with both a combination of CentOS 4, CentOS 5, and CentOS 6 servers do some backups/restores, and tell us if the old passwords still work (and let us know the last few lines of the /etc/login.defs file as well).

Knowing this in advance would be helpful to those of us taking old servers out of service and replacing them with new builds.

Thanks.

Jeff
 
The only issue with passwords I had when moved accounts from FreeBSD to CentOS, the passwords were encrypted with an algorithm not supported by CentOS.

With CentOS 5.x for sure you can use both SHA512 and MD5. I've just looked at /etc/shadow on CentOS 5 powered box and I saw lines encrypted with both algorithms. And I have there:

Code: 
# Use MD5 or DES to encrypt password? Red Hat use MD5 by default.
MD5_CRYPT_ENAB no

ENCRYPT_METHOD SHA512

A mix of algorithms in my /etc/shadow I would try to explain as Directadmin ignores ENCRYPT_METHOD set in /etc/login.defs and still uses MD5 when you create an account. And as soon as a user changes the password it becomes encrypted with the method set in /etc/login.defs. At least my recently made test (I'm still logged into the box while typing this) made me think so.

So both methods work OK on CentOS 5, and I really don't see any reason why it should not on CentOS 5 and on CentOS 6.

Note, I did not try to use SHA512 encrypted passwords with ENCRYPT_METHOD set to MD5.
 
I had a similar issue after making a backup in Centos 5 and restoring it in Centos 6. The directadmin interface told me SSH access was on, but looking at /etc/ssh/sshd_config and /etc/passwd this was not the case. In other words: the Directadmin interface did not reflect the real situation. Turning SSH access off, wait for a minute and turning SSH on solved the issue.

I am quite certain of the fact that I did not turn SSH access off before making the backup or after restoring the backup. So either the (Centos 5) backup did not store the SSH access for 'admin' or it got lost during the restore in Centos 6.

There probably was a change in the default hashing mechanism, because I now have users with MD5 hashing and others (like admin) with SHA256 hashing. Other users with SSH access did not lose it.
 
Last edited:
Jan_E said:
In other words: the Directadmin interface did not reflect the real situation. Turning SSH access off, wait for a minute and turning SSH on solved the issue.
Click to expand...

When showing it in directadmin interface only values from user.conf are honored. The fact that SSH access was not restored might be a bug. So if you could test it once more and replicate it again, then I'd guess it should be reported to Directadmin staff.
 
zEitEr said:
The fact that SSH access was not restored might be a bug. So if you could test it once more and replicate it again, then I'd guess it should be reported to Directadmin staff.
Click to expand...
I tried it the other way around. Create a fresh Centos 5 server, check that the admin had SSH access, restore a backup of my Centos 6 server. All users that had SSH access were restored with SSH access except admin.

Definitely a bug.

Edit: Hold your horses. I restored a backup with the inconsistency. Nothing confirmed or rejected yet.
 
Last edited:
Well, I now recollect the recent restore for a customer of mine. I was wondering why I was not able to login as admin after the restore. Both servers had admin allowed to use SSH, but after restore /etc/ssh/sshd_config was missing a line

Code: 
AllowUsers admin
, the other users were still there, and admin's shell was changed to /bin/false, so I had to change it to /bin/bash and the missing line into ​/etc/ssh/sshd_config
 
I just did a fresh restore from Centos 6 to Centos 6. Before the restore the admin had SSH access, the backup was taken from a server where the admin also had SSH access. After the restore the AllowUsers admin line was vanished.

I also checked on two backupservers, where I had restored a backup in January: the same problem. So it is a confirmed bug now.

BTW, there was a difference in hashing mechanism. On the server where the backup was made:
Code: 
[root@vps ~]# passwd --status admin
admin PS 2014-07-31 0 99999 7 -1 (Password set, SHA512 crypt.)
On the server where the restore was done:
Code: 
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-01 0 99999 7 -1 (Password set, MD5 crypt.)
This is what happened after changing the hashing to SHA512 and restoring a backup with a MD5 password:
Code: 
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-01 0 99999 7 -1 (Password set, SHA512 crypt.)
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
AllowUsers admin
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Last login: Fri Aug  1 11:32:22 2014 from localhost
[admin@vps2 ~]$ exit
logout

Connection to localhost closed.
[root@vps2 ~]#
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       AllowTcpForwarding no
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-01 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Permission denied, please try again.
admin@localhost's password:

[root@vps2 ~]#
 
Last edited:
Complete and unedited telnet session below. Short summery: the backup was from a server with default hashing method SHA512 and the admin password was also SHA512. The admin had SSH access. The server where the restore was done, had the same specs.

After the restore the admin had lost the SSH access (although the DA interface did not reflect that). On top of that the admin password was MD5 hashed now! I can not think of any method to do that unless you have the password in plain text. I surely do hope Directadmin does no such thing.

I am now making a new backup of the test server and will restore that on the same machine later. Then I will also check if the actual stored hash changes during the restore.
Code: 
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Last login: Fri Aug  1 15:42:38 2014 from localhost
[admin@vps2 ~]$ exit
logout

Connection to localhost closed.
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
AllowUsers admin
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-01 0 99999 7 -1 (Password set, SHA512 crypt.)
[root@vps2 ~]#
[root@vps2 ~]# echo restoring
restoring
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-02 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       AllowTcpForwarding no
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Permission denied, please try again.
admin@localhost's password:

[root@vps2 ~]# echo Putting admin's SSH access off and on in DA-interface
> ^C
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-02 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
AllowUsers admin
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Last login: Sat Aug  2 15:47:27 2014 from localhost
[admin@vps2 ~]$exit
Connection to localhost closed.
[root@vps2 ~]# authconfig --test | grep hashing
 password hashing algorithm is sha512
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-02 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]#
[root@vps2 ~]# echo Rebooting while keeping the telnet session open
Rebooting while keeping the telnet session open
[root@vps2 ~]#
[root@vps2 ~]# authconfig --test | grep hashing
 password hashing algorithm is sha512
[root@vps2 ~]# echo just to be sure
just to be sure
[root@vps2 ~]# authconfig --passalgo=sha512 --update
[root@vps2 ~]# authconfig --test | grep hashing
 password hashing algorithm is sha512
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
AllowUsers admin
[root@vps2 ~]#
[root@vps2 ~]# echo restoring the same backup once again...
restoring the same backup once again...
[root@vps2 ~]#
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       AllowTcpForwarding no
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers limedev
AllowUsers modx
AllowUsers peteremil
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-02 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]# authconfig --test | grep hashing
 password hashing algorithm is sha512
[root@vps2 ~]#
 
Jan_E said:
Complete and unedited telnet session below. Short summery: the backup was from a server with default hashing method SHA512 and the admin password was also SHA512. The admin had SSH access. The server where the restore was done, had the same specs.

After the restore the admin had lost the SSH access (although the DA interface did not reflect that). On top of that the admin password was MD5 hashed now! I can not think of any method to do that unless you have the password in plain text. I surely do hope Directadmin does no such thing.
Click to expand...
I checked this once again with a backup made on the testserver it self. How on earth can Directadmin change a SHA512 hashed password into a MD5 hashed password without having stored the password in plain text somewhere? Unedited telnet session below. Please note the change in the hash of the password in /etc/shadow.
Code: 
[root@vps2 ~]# tail /etc/ssh/sshd_config
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers modx
AllowUsers peteremil
AllowUsers limedev
AllowUsers admin
[root@vps2 ~]# authconfig --test | grep hashing
 password hashing algorithm is sha512
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-03 0 99999 7 -1 (Password set, SHA512 crypt.)
[root@vps2 ~]# cat /etc/shadow | grep admin
admin:$6$FljEOEP9$lN26IInicx0.QnnAEN7wNpX9n00u1iMVWIhrk.RiMs60b6Im7FAHhUlgDF8B3fMMSwGXsvMhaAf4FAZbNKXEx/:16285:0:99999:7:::
diradmin:!!:16031::::::
[root@vps2 ~]#
[root@vps2 ~]# echo Making a backup
Making a backup
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-03 0 99999 7 -1 (Password set, SHA512 crypt.)
[root@vps2 ~]# cat /etc/shadow | grep admin
admin:$6$FljEOEP9$lN26IInicx0.QnnAEN7wNpX9n00u1iMVWIhrk.RiMs60b6Im7FAHhUlgDF8B3fMMSwGXsvMhaAf4FAZbNKXEx/:16285:0:99999:7:::
diradmin:!!:16031::::::
[root@vps2 ~]#
[root@vps2 ~]# echo Restoring the backup
Restoring the backup
[root@vps2 ~]# echo Restored, let us check
Restored, let us check
[root@vps2 ~]# passwd --status admin
admin PS 2014-08-06 0 99999 7 -1 (Password set, MD5 crypt.)
[root@vps2 ~]# cat /etc/shadow | grep admin
admin:$1$VA5n3HVL$gxjuOFZwrX7ViBCKmzMdr/:16288:0:99999:7:::
diradmin:!!:16031::::::
[root@vps2 ~]# tail -n8 /etc/ssh/sshd_config
#       AllowTcpForwarding no
#       ForceCommand cvs server
AllowUsers root
AllowUsers jane
AllowUsers tammo
AllowUsers modx
AllowUsers peteremil
AllowUsers limedev
[root@vps2 ~]# echo Put the SSH access foradmin off and on in the DA interface
Put the SSH access foradmin off and on in the DA interface
[root@vps2 ~]# tail -n2 /etc/ssh/sshd_config
AllowUsers limedev
AllowUsers admin
[root@vps2 ~]# echo Log in with the password that has been SHA512 hashed
Log in with the password that has been SHA512 hashed
[root@vps2 ~]# ssh admin@localhost
admin@localhost's password:
Last login: Thu Jul 31 15:14:52 2014 from localhost
[admin@vps2 ~]$
 
You must log in or register to reply here.
Back
Top