Resetting a Forgotten Root Password on RHEL

Locked out of the root account on a Red Hat Enterprise Linux server is a situation every system administrator eventually faces. In Australian data centres from Sydney to Perth, RHEL remains a backbone for government, finance, and research workloads, and a forgotten root password on a critical box can stop a deployment in its tracks. The good news is that the recovery process is well documented, repeatable, and does not require reinstalling the operating system.

The procedure relies on interrupting the normal boot flow, mounting the filesystem in a writable state, and issuing a standard password change command before allowing the system to start up again. It works on RHEL 7, 8, and 9, although the exact key combination depends on whether the host uses the legacy GRUB or the newer BLSCAT-based boot loader.

Before touching any production server, confirm that you have direct console access, whether through a keyboard and monitor, an IPMI/BMC interface, or a virtual console from a hypervisor like KVM or VMware. Cloud instances on AWS or Azure in the ap-southeast-2 region use their own recovery workflows, which differ from the on-premises method covered here.

Preparing for the Recovery Process

A password reset on RHEL touches low-level boot parameters, so preparation reduces the chance of an outage extending from minutes into hours. Most Australian hosting providers, including those in Melbourne and Brisbane, recommend performing the change during a scheduled maintenance window even if the system appears unresponsive.

Make sure the machine is plugged into a reliable UPS or, at the very least, a power source you trust. If you are working remotely from Adelaide or Canberra, double-check the latency on your out-of-band management card before you begin, as a dropped KVM session mid-procedure can leave the host in an awkward state.

It is also worth photographing or noting the current GRUB entry, the kernel version, and any custom kernel arguments. These details help you restore the original boot behaviour once the password has been changed.

Reaching the GRUB Menu

Power cycle the server and watch the early boot screen closely. By default, RHEL hides the GRUB menu behind a short timeout, so timing matters. Tap the Escape key as soon as the vendor logo disappears to reveal the boot entries.

If the menu is still hidden, hold Shift during BIOS or UEFI handover on legacy systems, or press Escape on UEFI-based machines. Australian-built servers from local resellers often ship with a custom OEM bootloader that overrides the default key, so consult the vendor documentation if Escape does not respond.

Once the menu appears, highlight the kernel entry you normally boot, but do not press Enter. Press e to edit the entry before the system starts.

Editing Kernel Arguments

The edit screen lists several lines beginning with linux or linux16. Locate the line that ends with the words rhgb quiet or ro, depending on the RHEL release. Move the cursor to the end of that line using the arrow keys.

For RHEL 7 hosts, replace ro with rw and append init=/sysroot/bin/sh. For RHEL 8 and 9, the recommended approach is to append rd.break to the same line, which drops the system into an emergency shell early in the boot process. Both methods achieve the same outcome: a root shell with the root filesystem mounted but not yet activated.

Press Ctrl+X or F10 to boot with the modified arguments. You will see a switch_root prompt, or an emergency shell depending on the chosen method.

Resetting the Password and Rebuilding Context

At the shell prompt, the filesystem is mounted read-only at /sysroot. Begin by remounting it read-write and entering a chroot environment so that standard paths behave as expected during the password change.

Run the following sequence: mount -o remount,rw /sysroot, followed by chroot /sysroot. Inside the chroot, type passwd and enter a new root password twice. Choose a strong passphrase that meets your organisation's complexity rules, since weak credentials often trigger audit failures reported to the ACSC.

For RHEL 8 and 9, an extra command is required before rebooting. SELinux stores file labels separately from the file contents, and changing the /etc/shadow entry does not automatically update those labels. Run touch /.autorelabel to force a full filesystem relabel on the next boot. This step adds a few minutes to the startup time but prevents login failures caused by mismatched contexts.

Exit the chroot with exit, then type reboot at the original shell. The server will restart normally and apply the SELinux relabel before reaching the login screen.

Restoring Normal Operation and Hardening Access

Once the host is back online, log in as root with the new password and confirm that all services have started. A quick systemctl --failed check reveals anything that did not come up correctly.

After access is restored, take a moment to lock down remote root login. Edit /etc/ssh/sshd_config and set PermitRootLogin no, then restart sshd. This is a baseline expectation in most Australian compliance frameworks and pairs well with firewalld hardening rules that limit SSH to known administrative subnets.

Create a personal administrator account, add it to the wheel group, and distribute sudo privileges through a central identity provider wherever possible. The combination of a non-root login, audit logging, and a documented password reset runbook is what separates a healthy RHEL estate from a fragile one.

Steps to Verify Before Closing the Session

• Confirm the new password works over SSH from a workstation in a different Australian state.
• Check that journalctl -b shows no errors during the SELinux relabel.
• Validate that scheduled cron jobs and systemd timers are running as expected.
• Update your password vault and notify the on-call rotation in your team chat channel.

What stays with you long after the password is changed is the muscle memory of the recovery procedure. Practising it on a non-production RHEL virtual machine, ideally one hosted in a lab environment in your nearest capital city, turns a stressful outage into a routine task. The next time a root credential slips out of reach, the path back into the system is a matter of minutes rather than hours.