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?). -- Regards, James. http://www.jamesbensley.co.cc/ There are 10 kinds of people in the world; Those who understand Vigesimal, and J others...?
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. -- Best Regards, Giles Coochey NetSecSpec Ltd NL T-Systems Mobile: +31 681 265 086 NL Mobile: +31 626 508 131 GIB Mobile: +350 5401 6693 Email/MSN/Live Messenger: giles at coochey.net Skype: gilescoochey -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5137 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.centos.org/pipermail/centos/attachments/20110202/f56e01a7/attachment-0001.p7s>
At Wed, 2 Feb 2011 14:44:01 +0000 CentOS mailing list <centos at 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?).>-- Robert Heller -- 978-544-6933 / heller at deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
On Wed, Feb 2, 2011 at 9:44 AM, James Bensley <jwbensley at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos >
On Wed, Feb 2, 2011 at 9:44 AM, James Bensley <jwbensley at 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 at 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
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. -- mount -t life -o ro /dev/dna /genetic/research