How to reset ROOT password in RHEL/CentOS

Hello Linux-Fanatics, this tutorial explains how to reset a forgotten root password on RHEL and CentOS from the system console. It is a useful recovery procedure to know, and it is also a common RHCSA lab exercise.

Use it only on a machine you own or are authorized to recover. The process requires a reboot, so arrange a maintenance window and make sure you have a recent backup or snapshot before changing a production system.

Resetting the root password from GRUB

You need access to the local, hypervisor, or remote-management console; an ordinary SSH session cannot interrupt the boot process.

1. Reboot the system. When the GRUB kernel-selection screen appears, press e to edit the selected boot entry. If the menu disappears too quickly, press a cursor key to pause the timeout first.
2. Find the kernel command line. It commonly starts with linux16; depending on the release and firmware, it may instead start with linux or linuxefi. Move to the end of that logical line, add a space followed by rd.break, and press Ctrl+X. Do not add it as a separate line or replace parameters already present.

The system should stop in an emergency shell before switching to the installed root filesystem. At this point /sysroot is usually mounted read-only. Make it writable and enter the installed system:

mount -o remount,rw /sysroot
chroot /sysroot

The chroot step matters: running passwd in the temporary boot environment would not reliably update the installed system's account database. Now set the new password explicitly for root:

passwd root

Enter the new password twice. Nothing appears on screen while you type, which is normal. Choose a unique passphrase and store it in your organization's approved password vault rather than reusing an old or shared password. Do not reboot yet: the SELinux step below is essential on a standard RHEL or CentOS installation.

The step everyone forgets: relabeling SELinux

On SELinux-enabled RHEL and CentOS systems, resetting the password through rd.break changes /etc/shadow while SELinux is not fully running. The file can end up with a context that the normal login process is not allowed to read. Skipping this repair can therefore leave even the new password unable to log in.

While you are still inside the chroot, run:

touch /.autorelabel

Because you used chroot /sysroot, this creates the marker on the installed root filesystem. It asks SELinux to relabel the filesystem during the next boot. Now leave the chroot and then leave the emergency shell:

exit
exit

Allow the boot and relabeling process to finish without interrupting it, even if it takes longer than usual; the machine may reboot again. Then test the new password from the console. Keep that successful session open while you test any remote access separately.

Troubleshooting a failed recovery

• passwd reports an authentication-token or read-only-filesystem error: make sure mount -o remount,rw /sysroot succeeded before chroot /sysroot. If /sysroot/etc does not contain the machine's normal configuration, stop and check that you are working with the correct installation rather than an empty or unrelated rescue filesystem.
• You rebooted without creating .autorelabel: if another sudo-capable account can still log in, repair the password file's context with sudo restorecon -v /etc/shadow. If nobody can log in, repeat the rd.break procedure and create .autorelabel before exiting. Do not permanently disable SELinux just to avoid this step.
• The console password works but SSH still rejects root: this is often intentional. Many systems set PermitRootLogin no or disable password authentication in the SSH server. Resetting a Unix password does not change those rules. Prefer signing in as a normal user and using sudo; do not weaken SSH policy merely to prove the recovery worked.
• GRUB returns to a normal boot: check that you edited the entry you actually booted, put rd.break on the kernel line, and pressed Ctrl+X rather than Enter.

A word on physical and boot security

This procedure demonstrates why console and boot access must be treated as highly privileged. On an unencrypted disk, someone who can reboot the machine and alter its boot parameters can usually take control of the operating system.

Restrict physical consoles, remote-management interfaces such as IPMI/iDRAC/iLO, hypervisor consoles, and cloud snapshot or volume-attachment permissions to authorized administrators. Require strong authentication where the platform supports it and review access logs. A GRUB password can discourage casual edits, but it is not a substitute for disk encryption when someone can boot other media or remove the disk.

Full-disk encryption with LUKS changes the recovery requirements: you still need the LUKS passphrase to unlock and modify the encrypted root filesystem. Keep that recovery passphrase in a secure, accessible escrow system so encryption does not turn a forgotten login into permanent data loss. We cover encrypting partitions in this guide. If a password reset or console session was unexpected, treat it as a possible security incident and review authentication logs, local accounts, and SSH keys.

If it is a cloud VPS instead

A cloud serial console does not always expose GRUB, so follow the provider's documented recovery process first:

• Many VPS panels offer rescue mode or a recovery ISO. After booting it, use lsblk -f to identify the installed root filesystem, mount that filesystem, and use chroot followed by passwd root. On an SELinux-enabled system, create /.autorelabel inside the chroot as above. Prefer passwd to manually editing /etc/shadow; one malformed shadow entry can create another lockout.
• A provider's one-click password reset can be useful, but it cannot override an SSH configuration that only accepts keys or denies root login.
• On AWS, GCP, or Azure, a common approach is to snapshot the root disk, attach the original disk or a recovered copy to a helper instance, and repair the password or SSH keys there. Follow the platform's stop/start requirements, never mount the same volume read-write on two instances, and unmount it cleanly before detaching it.

Once access is restored, configure an SSH key for a normal sudo-capable user and test it in a fresh session while keeping the recovery session open. Protect the private key with a passphrase and maintain a controlled backup of your recovery method. Our SSH key setup guide walks through the key-setup process.