What to do when you've forgotten your root password

Suppose that you have a GNU/Linux server sitting somewhere that's gone untouched for a while. Maybe it's yours, or perhaps it's someone else's. But now, for whatever reason, you need to connect to it and do something with the software inside of it. You might pull up your credential management system (provided that you use one, be it a specialized webapp, or even something like KeePass), try to look up the server's details and discover... nothing.

Things could go wrong for you for a variety of reasons - perhaps someone deleted the information a while back by accident and no one spotted that, and now there are no backups of it anywhere. Or maybe another person kept it on their local drive, the drive being wiped when they left to pursue other things in life. Regardless of why, now it's your responsibility and you'll just have to pick up the slack.

So, what can you do? Should you metaphorically reach for the plug, wipe everything and start anew? Perhaps. But before you do that, there are a few things that you can try to recover from this situation with your existing server, by changing the password through the recovery mode. This post describes just how to do that. Note, that this won't work in all setups, though there are many out there without a protected bootloader, in which case these steps could just be useful, at least before trying the alternative.

The process will typically be fairly simple, with minor differences based on the OS that you use. Thus, i'll test it out and offer you examples for two groups of distros: DEB (Debian, Ubuntu, ...) and RPM (RHEL, Fedora, CentOS, Rocky Linux, ...). Without further ado, let's get going!

Using recovery mode in DEB distros

For this demonstration i've created a Debian VM, the password for which i set at random and promptly deleted from the open notes text file that i have:

As expected, i can no longer log in:

First, you'll want physical access to the server (or the hypervisor), so that you can interact with the bootloader when the server boots:

(some sources suggest that you might need to hold down Shift or ESC during boot to get to it, depending on the setup)

Debian offers you the option to access "Advanced options for Debian GNU/Linux", which you'll want to pick. There, you'll find the recovery mode option:

Now, the thing about Debian is that you would normally still be asked for the password when entering recovery mode. Thankfully, there is a way around that, just press "e" to edit the boot command:

You'll want to add the following to the end of the kernel line (that starts with linux):

init=/bin/bash

Thus, it should look a bit like the following:

Then, follow the instructions and press F10 to boot! You should find yourself with bash running in a few short moments...

(you might have to press ENTER once for the shell to actually start up properly)

From there, the rest becomes pretty easy, mount the root filesystem for writes and change your password:

mount -o remount,rw /
passwd root

After that is done, you should be able to reboot:

(of course, sometimes the poweroff/reboot commands might not work in this context, so maybe do a physical power cycle, or just use the "exit" command)

The next time when you boot into regular mode, your new credentials should work:

Furthermore, if you need to make any other changes to the file system, you can use the same approach to do so.

Using recovery mode in RPM distros

For this demonstration i've created a Rocky Linux VM, the password for which i set at random and promptly deleted from the open notes text file that i have:

As expected, i can no longer log in:

First, you'll want physical access to the server (or the hypervisor), so that you can interact with the bootloader when the server boots:

(some sources suggest that you might need to hold down Shift or ESC during boot to get to it, depending on the setup)

Similarly to Debian, Rocky also gives you a recovery mode option. Similarly, it would also ask you for the password, so we also need to do a bit of editing here.

However, for some odd reason the recovery mode option didn't work out for me, so you might want to try editing the regular boot option first. Either way, "e" to go into editing mode:

You'll want to add the following to the end of the kernel line (that starts with linux):

rd.break enforcing=0

Thus, it should look a bit like the following:

Then, follow the instructions and press CTRL+X to boot! You should find yourself with a shell running in a few short moments...

(notice how the "whoami" command doesn't really work? we're not really running your usual Bash shell here with everything you'd expect)

From there, the rest becomes pretty easy, mount the root filesystem for writes and change your password:

mount -o remount,rw /sysroot
chroot /sysroot
passwd root
exit
mount -o remount,ro /sysroot
exit

With all of that done, the system should reboot. For whatever reason, just power cycling didn't really work for me, so it might be important to use the proper "exit" commands.

When the OS proceeds to boot, your new credentials should work:

Furthermore, if you need to make any other changes to the file system, you can use the same approach to do so.

Summary

Now, there are a few differences between the different OSes out there, but it's nice that the default installs give us this ability to change the password when needed!

Of course, you cannot do this remotely, which is why this can't really be considered hacking - if someone has physical access to your hardware, in many cases they'll be able to do almost anything with it. So perhaps it's also a good idea to use full disk encryption and also setup a password for your bootloader.

But what if the above doesn't work? Well, one option would be to use a live rescue CD (which you can just write to a flash drive) and try to work with the system that way. After all, if your install isn't too hardened, it's all just a bunch of files anyways and in lieu of encryption that you can't work around, it should all read like an open book to you.

Until then, good luck with your recovery and remember to keep track of access credentials so you don't need to count on such recovery processes in the first place!