Crack root password

[Robert1]

Has anyone found a way to crack ROOT....listed on the RHSCA exam objectives?

I have found many videos...but I can not replicate.

I tried using a RHEL 7.5 VM in VirtualBox and VMware and get the same result....

Boots back up and NONE of the passwords work. Its like they all got erased during the process.

Anyone know a fix? Sound familiar?

THanks- R

[NunoMartins · Accepted solution]

What steps have you followed ? 

Once you have added the rd.break to your linux16 kernal command entry you do the following:

Press Ctrl+x to boot, 

Remount sysroot:     mount -oremount,rw /sysroot

Chroot:  chroot /sysroot

Change pass:   passwd root

Relabel shadow:  touch /.autorelabel                   --- This is important 

then you can exit and it will perform the selinux relabel and reboot

[Tracy_Baker]

---

@NunoMartins wrote:

Relabel shadow:  touch ./autorelabel                   --- This is important 

---

This is 100% wrong.

Firstly, you aren't relabeling shadow, per se -- you are relabeling the entire file system.

What is completely wrong, though, is the command:

The correct command is: touch /.autorelabel

The dot goes before "autorelabel" not before the "/".

The file that must be created for this to work must be a hidden file that resides in / -- hence, /.autorelabel

[Scott]

I think describing the response as 100% wrong, is a bit ... dramatic.  Yes there was a typo.  Also, while, yes, /.autorelabel does kick off an entire system relabel, the reason it's done here is to relabel /etc/shadow (and, consequently any other files that have had their SElinux contexts mangled by being adjusted in an environment without SElinux enforcement active).  But the main reason is /etc/shadow as without correct contexts, when root attempts to log in, the process verifying the password will be refused from accessing an /etc/shadow with incorrect/invalid SElinux contexts.  [resulting in not being able to authenticate as users listed in this file]  I have a suspicion that the lack of this relabeling is why the original author is having difficulty logging in as any defined user after their attempt to reset the root password.

-STM

[Tracy_Baker]

---

@Scott wrote:

I think describing the response as 100% wrong, is a bit ... dramatic.  Yes there was a typo.  

---

Yes, it was dramatic -- and in this case, intentionally so. (And let's not forget that I only quoted the relevant portion that was incorrect.) I was trying to make certain that the OP understood what was going awry.

I felt this was even more important because it was marked as a solution -- when it was incorrect.

Scott is absolutely correct as to the specifics of the relabeling process and why it needs to be done: Specifically, /etc/shadow needs to have its SELinux context fixed.

@NunoMartins: I apologize for being dramatic. It wasn't intended as a slight towards you. Again, I simply wanted to make certain that the OP got the point. I see that you've edited it since my previous reply :)

------

Incidentally, I tried it with the incorrect command (touch ./autorelabel) for the first time. (Sometimes, I don't do something because I know it is incorrect.) The results were interesting. When it rebooted, it allowed me to log in -- as a completely new user (this was on CentOS 7.6).

I got the Welcome, Typing, Privacy, Time Zone screens, and then at asked me to create an account. At that point, I did get a desktop but could really do anything except turn off or restart the machine.

Subsequent reboots simply repeated the scenario.

It was easy enough to fix the system by creating /.autorelabel -- afterwards everything returned to normal.

[NunoMartins]

appologies - this was a typo 

[Coding-01]

同意！
在linux16内核命令条目后将ro改为rw后接rd.break，并将同行后面的其他删除请
ctrl + x——>chroot /sysroot——>mount -o remount,rw /——>passwd root——>touch /.autorelabel——>exit——>exit

[upsetwithrh]

right - and/or add 'enforcing=0' and handle the relabel of /etc/shadow later..

The issue I had today during the "thin client" virtual exam was the applet provided to connect to "node1" or "node2" would show "working..." until after the login / network were up. There was no way to interrupt the boot to add the rd.break (and remove quiet and rhgb).  I reached out to the proctor who said he contacted exam support and the reply was that it "has to be reviewed" - meaning they expected me to find a workaround and not admit that there was something wrong. I posted a warning here that people should hold off on the virtual exam until this was resolved but the moderators saw fit to take the post down. Am i missing something here?  Am I correct in saying this was a show stopper?

[Robert1]

Thanks for all the responses to my initial post "crack root password"....sorry, but I can not reply to your responses. (working on that with tech-suport)

So let me try to reply here......

as for the ./ vs /. ---yes, it needs to be /.

but it still did not fix the problem.

when i look at the 134 course book, on page 26, resetting your lost root password...

it has all the same steps except, when you go to change the root password... instead of:

'passwd'  ...2 times, the text says to put in the followoing command:

'echo redhat | passwd --stdin root'

and it WORKS !!! yeah...happy dance.

But why? These are two different ways of accomplishing the same thing...right?

Can someone explain to me why 'passwd' (2x) does not work for me...(but everyone else on youtube and this chat it does)....but your text book command of 'echo redhat | passwd --stdin root'   does work for me.???

(I'm not trying to come off as flippint...I just want to learn something).

By the way...I'm running RHEL 7.5 as a VM on VMware on a Win10 host. (if that helps)

Thanks to anyone who replies ;-)

[Scott]

@Robert1 ,

I'm unable to reproduce the error you're describing, though the VMs I have to try it on are RHEL8Beta.  I'm able to change the root user's password using the procedure outlined above, by manually entering the password (twice as prompted by the passwd utility).

The echo redhat | passwd --stdin root command sends a single string to the passwd utility, which is told to accept it over the stdin filehandle (passed through the |).  The only thing I could imagine of why this is operating differently would be because you're typing the string a single time, and able to see said string on the commandline, which is different than how the passwd utility natively works.

-STM