So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
On 02/02/2011 15:44, James Bensley wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
If you can edit /etc/shadow then you could have changed roots password. Depending on your access (console required) you could have booted to single-user mode and edited /etc/shadow that way.
I would not recommend deleting the /etc/shadow file at all... don't think that would gain you access.
At Wed, 2 Feb 2011 14:44:01 +0000 CentOS mailing list centos@centos.org wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
No, it would not have. It would have resulted in NOONE having access.
What you could have done is chroot to the secondary device on the other VM and then simply reset the root password with the passwd command.
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
On 2 Feb 2011 15:07, "Robert Heller" heller@deepsoft.com wrote:
At Wed, 2 Feb 2011 14:44:01 +0000 CentOS mailing list centos@centos.org
wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
No, it would not have. It would have resulted in NOONE having access.
What you could have done is chroot to the secondary device on the other VM and then simply reset the root password with the passwd command.
Of course! Good idea, thanks.
--James. (This email was sent from a mobile device)
On Wed, Feb 2, 2011 at 9:44 AM, James Bensley jwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
:)
Nope... would lock everyone out!!
You can change the shadow to a known hash and that should work. But going through that exercise, though interesting, would not be the most direct method.
Had you changed the default expiration setttings on the system? You can run the "chage" command to see the settings on different users. Also you may want to check the faillog.
Is this system Internet accessible? I'd be very leery of trusting that system until you determine what caused it to lock out.
Anyhoo, coincidentally I was thinking of ways to change a root password on a 24/7 system. Some of the things I tested was to overwrite some of the cron scripts that I had access to, create a suid binary on a trusted and mounted fs (i.e., no root squash, noexec not enabled), exec a shell from with a sudo command that had shell out capability, etc..
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
-- Regards, James.
http://www.jamesbensley.co.cc/
There are 10 kinds of people in the world; Those who understand Vigesimal, and J others...? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Kwan Lowe wrote:
On Wed, Feb 2, 2011 at 9:44 AM, James Bensley jwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to
<snip>
Anyhoo, coincidentally I was thinking of ways to change a root password on a 24/7 system. Some of the things I tested was to overwrite some of the cron scripts that I had access to, create a suid binary on a trusted and mounted fs (i.e., no root squash, noexec not enabled), exec a shell from with a sudo command that had shell out capability, etc..
<snip> Well, if you could get on the system at all, and had sudo privileges, no problem.
mark
On 2 Feb 2011 16:36, m.roth@5-cent.us wrote:
Well, if you could get on the system at all, and had sudo privileges, no problem.
mark
No sudo priv's, remote VM so ssh only to a stanard user not in sudoers.
--James. (This email was sent from a mobile device)
On Wed, Feb 2, 2011 at 11:35 AM, m.roth@5-cent.us wrote:
<snip> Well, if you could get on the system at all, and had sudo privileges, no problem.
Well, the point was actually if you did not have sudo access to change the password, what else could you do. I.e., you had sudo to edit a particular file or do something else, but not run passwd.
On Wed, Feb 2, 2011 at 9:44 AM, James Bensley jwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
Deleting /etc/shadow is *BAD*. You just blew away everyone's password, and will cause enormous confusion.
If you can't restore it, use "pwunconv" to turn off the use of /etc/shadow, and "pwconv" to re-enable it. The passwords will be locked, I believe: then you can mount the idle filesystem, do a "chroot" to the idle filesystem, and run "passwd root" to set a new password.
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensley jwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system boots:
init=/bin/bash
This will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access ... you are in charge so you can:
- mount the / partition and chroot
- edit /etc/shadow and delete the password hash
- whatever you can imagine ... you decide ;)
HTH
Rafa
On 03/02/2011 14:40, Rafa Griman wrote:
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system boots:
init=/bin/bashThis will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access ... you are in charge so you can:
- mount the / partition and chroot - edit /etc/shadow and delete the password hash - whatever you can imagine ... you decide ;)
That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
It will give you the same result and mount stuff without the need to chroot etc...
Hi :)
On Thursday 03 February 2011 14:59 Giles Coochey wrote
On 03/02/2011 14:40, Rafa Griman wrote:
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system
boots: init=/bin/bash
This will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access
... you are in charge so you can: - mount the / partition and chroot
- edit /etc/shadow and delete the password hash - whatever you can imagine ... you decide ;)That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
It will give you the same result and mount stuff without the need to chroot etc...
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
Rafa
At Thu, 3 Feb 2011 20:12:17 +0100 CentOS mailing list centos@centos.org wrote:
Hi :)
On Thursday 03 February 2011 14:59 Giles Coochey wrote
On 03/02/2011 14:40, Rafa Griman wrote:
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system
boots: init=/bin/bash
This will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access
... you are in charge so you can: - mount the / partition and chroot
- edit /etc/shadow and delete the password hash - whatever you can imagine ... you decide ;)That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
It will give you the same result and mount stuff without the need to chroot etc...
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
RedHat / RHEL / CentOS does not do that! At least never on any of my machines -- is there some config option for that? Yes, for manual fchk it does, but not otherwise.
Rafa
Hey !!!
On Thursday 03 February 2011 20:42 Robert Heller wrote
At Thu, 3 Feb 2011 20:12:17 +0100 CentOS mailing list centos@centos.org
wrote:
Hi :)
On Thursday 03 February 2011 14:59 Giles Coochey wrote
On 03/02/2011 14:40, Rafa Griman wrote:
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com
wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system
boots: init=/bin/bash
This will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access
... you are in charge so you can: - mount the / partition and chroot
- edit /etc/shadow and delete the password hash - whatever you can imagine ... you decide ;)That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
It will give you the same result and mount stuff without the need to chroot etc...
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
RedHat / RHEL / CentOS does not do that!
True, just tried it with RHEL 6 and CentOS 5.3. Well it should ask for a passwd ... at least IMHO.
Then again ... an admin should configure grub/lilo to ask for a password if you pass parameters to the kernel during boot time :)
At least never on any of my machines -- is there some config option for that? Yes, for manual fchk it does, but not otherwise.
I'll check, but no idea.
Rafa
On Thu, Feb 3, 2011 at 3:14 PM, Rafa Grimán rafagriman@gmail.com wrote:
On Thursday 03 February 2011 20:42 Robert Heller wrote
At Thu, 3 Feb 2011 20:12:17 +0100 CentOS mailing list centos@centos.org
wrote:
Hi :)
On Thursday 03 February 2011 14:59 Giles Coochey wrote
On 03/02/2011 14:40, Rafa Griman wrote:
Hi :)
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com
wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
(This is past tense because its sorted now but I'm curious if this would have worked? And if not, what could I have done?).
As the other said: DON'T delete /etc/shadow.
Someone also mentioned you could modify the hash in /etc/shadow. This will work if you are root or have the right permissions with sudo.
If you can reboot the system, what really works great is passing the following option to the kernel on the lilo/grub screen when the system
boots: init=/bin/bash
This will give you a shell without being asked for a password (unless the sys admin has done his homework ;) Now that you have shell access
... you are in charge so you can: - mount the / partition and chroot
- edit /etc/shadow and delete the password hash
- whatever you can imagine ... you decide ;)
That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
It will give you the same result and mount stuff without the need to chroot etc...
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
RedHat / RHEL / CentOS does not do that!
True, just tried it with RHEL 6 and CentOS 5.3. Well it should ask for a passwd ... at least IMHO.
Then again ... an admin should configure grub/lilo to ask for a password if you pass parameters to the kernel during boot time :)
At least never on any of my machines -- is there some config option for that? Yes, for manual fchk it does, but not otherwise.
I'll check, but no idea.
In CentOS 5, use "~~:S:wait:/sbin/sulogin" in "/etc/inittab" to enter runlevel S with a password.
In CentOS 6, use "SINGLE=/sbin/sushell" in "/etc/sysconfig/init" to enter runlevel S without a password (default) and "SINGLE=/sbin/sulogin" in "/etc/sysconfig/init" to enter runlevel S with a password.
On Thu, 2011-02-03 at 14:42 -0500, Robert Heller wrote:
At Thu, 3 Feb 2011 20:12:17 +0100 CentOS mailing list centos@centos.org wrote:
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
RedHat / RHEL / CentOS does not do that! At least never on any of my machines --
Agreed. Adding 'single' to the kernel boot line boots up in run level 1 and no password is required.
My system is 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
Rafa Grimán wrote:
On Thursday 03 February 2011 14:59 Giles Coochey wrote
On 03/02/2011 14:40, Rafa Griman wrote:
On Wed, Feb 2, 2011 at 3:44 PM, James Bensleyjwbensley@gmail.com
wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore). Only I and one other know it and neither of us have changed it. No other account had the correct privileges to correct this so I'm wondering, if I had mounted that vdi as a secondary device on another VM, browsed the file system and delete /etc/shadow would this have wiped all users passwords meaning I could regain access again?
<snip>
That would do it... There is single-user-mode (runlevel 1), just add the word single to the kernel parameters line before bootup
Yes, but S|Single|1 asks for root password to login ... And he doesn't have the root password ;)
Boot from a rescue CD/DVD, then chroot and use passwd.
mark
Hi James,
On Wed, 2011-02-02 at 14:44 +0000, James Bensley wrote:
So on a virtual server the root password was no longer working (as in I couldn't ssh in anymore).
Any chance PermitRootLogin is set to "no" in /etc/ssh/sshd_config?
Regards, Leonard.
-
Always Learning -
Giles Coochey -
James Bensley -
Kwan Lowe -
Leonard den Ottolander -
m.roth＠5-cent.us -
Nico Kadel-Garcia -
Rafa Griman -
Robert Heller -
Tom H