This must be something asked of RedHat support quite a bit because it was covered thoroughly in their UNIX sysadmin training material for Redhat 7 and there's a published solution on their site from years ago. [1]

Redhat documentation is pretty decent and access is free via their developer program [2]. The program gives one free bare metal license for a system with up to 8 sockets that can host unlimited VMs. [3]

I realize HN is all about open source and free software but for people looking to work in a corporate environment that uses RHEL, Redhat does try to make entry at least possible for those who can self study.

[1] https://access.redhat.com/solutions/1192 [2] https://developers.redhat.com/ [3] https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

False advertising. The title says recovering your root password, but the article only talks about bypassing having to enter one.

Agreed. It would be more clear if it had been titled “resetting your root password.” For most of the (physical) Linux computers I’ve dealt with, the full disk encryption password would prevent even making it into any recovery mode without a passphrase, but maybe that’s atypical. The folks I work with tend to value security over recoverability.

That is how you reset the root password on Linux. If you have physical access to any computer, then you can do what you like. If you need to recover administrator on a Windows box then you go in with a systemrescue CD and edit the SAM database.

The choice is yours. You can deploy disc encryption, BIOS passwords etc but be prepared for being locked out.

RECOVERING your password usually means retrieving the plaintext representation. Not just "resetting" it.

It could also mean recovering the access to root, this is just splitting hair anyway.

> It could also mean recovering the access to root,

No! Even for me as a non native speaker this is obvious since I have worked in the field for a few years.

A car is a vehicle but saying that "a vehicle means a car is wrong".

In the same way recovering access to the root account might give you the same effect as recovering the password, but often not.

This is a situation were correct wording isn't hard and a situation where it matters in my opinion. People come here to learn and we shouldn't mislead them especially when the cost of fixing it is trivial.

If I recover the access to root, fine, I have access to that machine.

If I recover the root password I have access to all that the root password gives me access to.

On systems where for example home or certain configuration files are encrypted using the password as a key (yes, a bit simplified), this is the difference between getting access to the data or not.

> this is just splitting hair anyway.

No. This is trying to avoid potentially costly misunderstandings.

Agreed, there is a big difference between recovering root password and recovering root access

> If I recover the access to root, fine, I have access to that machine.

> If I recover the root password I have access to all that the root password gives me access to.

In POSIX that's the same thing.

That might technically be true, but as far as I know, with my setup, if I reset my Linux password and use the new password to access my account, my data will be gone as the home folder encryption key was encrypted with my password or something to that effect.

Now I cannot say for sure that this is possible on the root account as well - I've hardly used the actual root account since Ubuntu taught me otherwise in 2006 - but I see no obvious reason why you shouldn't be able to encrypt roots home folder the same way we encrypt other home folders.

I'm interested in knowing though in case I'm missing something.

If you’re encrypting your whole disk (encrypting /root doesn’t give you any benefit) then you will need to enter your passphrase before your system gets as far as reading /etc/shadow.

So that guide basically assumes you either already know your decryption passphrase or you don’t have full disk encryption. In either case, changing roots password wouldn’t lock you out of the root file system

> If you’re encrypting your whole disk

Not what I am talking about.

I'm talking about encrypted home folders.

I've never seen a system set up where root's home folder is encrypted. But also you wouldn't run the system as root normally, so there shouldn't be anything in the root folder to be lost even if that was the case. Getting access so you can fix what's not working is the primary reason for wanting root if you've somehow lost the password, or sudo broke, etc.

That's ecryptfs. It's no longer supported by newer versions of Ubuntu. The key is not your password. It's somehow protected by a pam module I believe to remember. I once noticed that being root allows you to su into their account, but not decrypting their home directory. So possibly the encryption key is encrypted using the password. One might need the old password to reencrypt the encryption key with the new password.

I had no interest to dig deeper, so I am not sure.

ecryptfs is one way that encrypted home has been done, but it's also been done with encfs and ZFS (very recently).

And I already said there’s no point encrypting /root. “Root” isn’t a user you should be using day to day so the root home directory should be mostly empty.

Thus if an attacker has root access then it’s literally everything else apart from /root that you need to be worried about. Hence why I discuss disk encryption.

In a literal sense you're right but the end result is ostensibly same (ie you've gained root access). Sure the title could have been more accurate but the OPs claim of "false advertising" is just as exaggerative and frankly it's dumb that instead of congratulating someone for a helpful walk-through people are arguing semantics about the fucking title.

I was seriously disappointed when I read the article.

You might be more experienced than the target audience of that piece. I'm sure there will be people who do find that content useful.

It's seriously hard creating useful content and I really do feel like your negativity towards this is excessive compared to the faux pas in question.

My negatively is just my personality. I didn't single this article out.

Don't tell me how to be.

Ironically I’ve tried not to be negative towards you (eg saying “you might be more experienced than the target audience”) and you’ve still taken my comments like a personal attack. So imagine how harshly your actual negativity would have been received by the content creator you’ve been targeting.

This is why I say it’s hard creating useful content for the web. Everyone is quick to attack but very few people are there to support. It’s a problem we should be even more accurately aware of during these difficult times of being on lockdown.

Obviously there will be times when constructive criticisms need to be raised but use of language is important — which I know is the same point you were making at the start but it’s just as relevant to you as it is the author. In fact HNs own policies ask that people write their corrections politely and constructively too.

Recovering the password means also that someone who doesn't know it can steal it and log in to the system without the real admin noticing. Resetting the password means the admin will notice it immediately as they won't be able to use their old password. That's just one of the many practical differences between these two different terms.

Yeah, I still wouldn't call it password recovery.

Btw konboot-cd is awesome for resetting/bypassing windows passwords (not free tho).

I would guess most folks here use full disk encryption, which would generally preclude you from reading the filesystem if you don't have the password any longer. If not, this is a good article to convince you to do so since anyone could do something similar to your laptop with no encryption.

I am scared to use full disk encryption or $HOME encryption because of potential loss of speed, hardware failures because of fragmenting or SSD grinding, the inability to use file recovering tools and being locked out if anything goes wrong. I just read changing the password might lock me out if the key is encrypted (or something).

Any tips?

Run 'cryptsetup luksHeaderBackup' and store it in a safe place. If you manage to corrupt your LUKS header, you can restore it from the backup.

The master encryption key in the LUKS header is still encrypted by your passphrase, so don't use this as an alternative to remembering your passphrase!

Speed loss is unnoticeable with any recent hardware (less than a decade old) and typical workloads (even for developers).

If concerns about losing data are a roadblock, then you need a good backup strategy. You're already rolling the dice that you'll never have a hardware failure, human error, natural disaster, theft...

I can't speak to your SSD wear concern or potential issues during password changes.

There is no loss of speed on any CPU that supports AES instructions, which is pretty much any CPU released after 2010.

encryption password ≠ root password , at least not for me :-)

The root password is pretty useless by itself if you can't decrypt the data.

Sure but you might have forgotten your root password and remembered your disk encryption pw

This is good, but why not just post the original URL? https://martinheinz.dev/blog/22

This is a nice write up. I was not aware of the rd.break option. Very helpful when you have an kernel module that hangs boot trying to configure failing hardware.