VMware ESXi and vSphere Cluster Management

Recover and Reset the Root Password on CentOS

Learn how to reset a CentOS root password with sudo or recover it through GRUB and a local, serial, or virtual-machine console.

Purpose, terminology, and access requirements

root is the privileged Linux superuser account. Its password is the credential associated with that account. Changing a known or otherwise accessible root password is different from recovering a lost password: the first can usually be done from a running system, while the second requires an alternate administrative path.

Perform password recovery only on CentOS systems you are authorized to administer. Unauthorized boot-loader editing or password recovery can provide complete control of a system.

There are two main recovery paths:

  • Sudo-enabled account: An administrator who can log in and use sudo can set a new root password without rebooting.
  • Console and GRUB recovery: If no usable sudo account exists, use physical, serial, or virtual-machine console access to edit the boot entry and start a recovery shell.

An ordinary SSH session is generally insufficient for the GRUB method because GRUB must be interrupted during startup. SSH can be used only when it is paired with an out-of-band console, such as a server-management console or hypervisor console.

Root password reset methods compared

MethodRequired accessReboot requiredMain command or actionBest use caseKey limitations
Sudo-enabled accountLogged-in account authorized by sudoers, commonly through the wheel groupNosudo passwd rootThe administrator can log in and knows the current account passwordDoes not work without a permitted sudo account
GRUB and chroot recoveryPhysical, serial, or virtual-machine console accessYesEdit the kernel command line, then use chroot /sysroot and passwdNo usable sudo account is availableRequires console access and may require SELinux relabeling

Reset the root password with a sudo-enabled user

sudo permits an authorized user to execute a command with elevated privileges. On CentOS, membership in the wheel group commonly grants this ability through the sudoers policy, although the exact policy should always be checked.

Log in as the authorized administrative user and run:

sudo passwd root

The prompts have an important order:

  1. sudo asks for the password of the currently logged-in administrative user. It does not ask for the old root password.
  2. passwd asks for the new root password.
  3. passwd asks you to enter the new password again for confirmation.
$ sudo passwd root
[sudo] password for admin:        # enter admin's password
New password:                     # enter the new root password
Retype new password:              # enter it again
passwd: all authentication tokens updated successfully

Password input is not displayed while it is being typed. A successful completion message confirms that the local root account password was updated.

Verify the change

Test the new credential through an approved local console or administrative workflow. For example, from an authorized administrative account, you can test root authentication with:

su -

Enter the new root password when prompted. This test may be affected by account policy. Direct root login over SSH may be disabled even when the password is correct, so a failed SSH root login does not by itself prove that the password reset failed.

Recover the root password through GRUB

Use this method when the root password is unavailable, no sudo-capable account can be used, and you have console-level access. A VM administrator should open the hypervisor's virtual console rather than relying on an ordinary SSH session.

1. Open the GRUB menu

Restart the CentOS machine. During startup, interrupt the boot sequence so the GRUB menu appears. The exact key and timing depend on firmware, console software, and GRUB configuration.

Select the normal CentOS boot entry, usually the first suitable entry. Enter GRUB edit mode using the key shown by the menu, commonly e.

2. Edit the kernel command line

Locate the line containing the Linux kernel boot arguments. On some older CentOS releases, this line begins with linux16. Other releases may use a different directive, so search for the line that contains the kernel path and its arguments rather than relying only on that label.

Temporarily modify the boot arguments so the installed filesystem is mounted read-write and a shell is started through the installed system's root mount. A historical pattern is:

rw init=/sysroot/bin/sh

The exact recovery syntax varies by CentOS release and boot configuration. Preserve the existing kernel arguments unless the release-specific procedure tells you otherwise, and place the recovery parameters on the kernel command line.

3. Boot the edited entry

Boot the temporarily edited entry with the key combination indicated by the GRUB screen, commonly Ctrl+X. This change normally applies only to this startup and does not permanently modify the boot-loader configuration.

4. Enter the installed system with chroot

The resulting shell initially runs outside the normal installed operating system. In this workflow, /sysroot is the directory where the recovery environment has mounted the installed system filesystem.

chroot changes a process's apparent filesystem root. Run:

chroot /sysroot

After this command, paths are interpreted as if the installed CentOS filesystem were the root directory. Running passwd now updates the installed system's authentication data instead of the temporary recovery environment.

5. Set the new root password

passwd

Enter the new root password twice. A successful result usually includes a message that all authentication tokens were updated successfully.

6. Prepare an SELinux relabel when applicable

SELinux uses security labels in addition to traditional Unix permissions. When authentication-related files are changed from an offline recovery environment, an enforcing system may require its labels to be rebuilt.

When required by the CentOS version and recovery method, create the relabel trigger while still inside the installed system:

touch /.autorelabel

On the next boot, SELinux can relabel the filesystem. That boot may take considerably longer than usual. Do not interrupt it while labels are being rebuilt.

7. Force a reboot from the recovery shell

Leave the recovery shell or use the recovery environment's reboot procedure. From a limited recovery shell, the specified forceful command is:

reboot -f

After the system starts normally, test the new credential through an approved local console or administrative workflow.

Filesystem root and chroot explained

chroot
TermMeaning in this procedure
Recovery shellA minimal shell started during early boot, outside the normal installed operating system environment
/sysrootThe mount location representing the installed CentOS filesystem
A command that changes the apparent root directory for the current process
passwdThe password utility that changes the account database belonging to the current filesystem root

The order matters. If passwd is run before chroot /sysroot, it may change credentials in the temporary recovery environment rather than in the installed system.

Recovery commands and their purposes

Command or boot parameterPurposeWhere it is usedExpected result
sudo passwd rootSet a new root password using delegated privilegesRunning CentOS systemSudo authenticates the current user, then passwd updates root's password
rw init=/sysroot/bin/shRequest a read-write installed filesystem and a sysroot recovery shellEditable GRUB kernel command lineBoot enters an early recovery shell; syntax varies by release
chroot /sysrootEnter the installed filesystem contextRecovery shellCommands operate against the installed CentOS system
passwdAssign a new password to rootAfter chrootingNew root password is written to the installed system
touch /.autorelabelRequest an SELinux filesystem relabelAfter chrooting, when applicableRelabeling occurs during the next boot
reboot -fForce a restart from a limited recovery environmentRecovery shellSystem restarts so normal boot can continue

Access prerequisites by environment

EnvironmentSuitable recovery accessExamples
Physical serverDirect keyboard and display access during startupRack console, attached monitor, and keyboard
Serial-managed serverSerial console with boot-time input enabledOut-of-band management controller or serial concentrator
Virtual machineHypervisor virtual display and keyboard consoleVM console used to interrupt startup and edit GRUB
Remote-only server without out-of-band consoleUsually insufficient for GRUB recoverySSH alone cannot normally interact with the boot loader

Troubleshooting

Sudo rejects the password

Check that you entered the current user's password, not the old root password. Also verify that the account is authorized by sudoers policy and, where applicable, is a permitted member of the wheel group. If no authorized account is available, use the console recovery route.

The GRUB menu or edit option does not appear

Boot-time input may have been sent too late, the menu may be hidden or have a short timeout, or the firmware, hypervisor, or console may not pass keyboard input correctly. Retry using the local, serial, or hypervisor console. A GRUB administrator password may also intentionally prevent boot editing.

No linux16 line is present

The CentOS release or selected boot entry may use another GRUB kernel-entry directive. Find the line containing the Linux kernel boot arguments and follow the recovery syntax appropriate for that release.

The new password fails after reboot

Common causes include running passwd before chroot /sysroot, modifying the wrong mounted filesystem, mistyping the password, or using an authentication policy or directory service that affects root authentication. Repeat the procedure and confirm the command order.

SELinux denials appear after recovery

Offline changes may have left incorrect SELinux labels. If appropriate for the system, create /.autorelabel before rebooting and allow the next boot to complete without interruption.

Direct root login remains unavailable

SSH root login may be disabled by policy, or PAM and the login service may prohibit root authentication. Test locally first, then review the applicable SSH and PAM configuration. Do not weaken those controls merely to make a remote test succeed.

Post-recovery validation and security follow-up

  1. Verify root authentication through an approved local console or administrative workflow.
  2. Confirm that the system completes a normal boot and that sudo access still works for authorized administrators.
  3. Use a strong, unique root password and store it through the organization's approved password-management process.
  4. Review whether direct root login, especially over SSH, is permitted by policy. Keeping it disabled is often appropriate.
  5. Protect GRUB and physical, serial, and virtual console access. Unrestricted boot editing can provide a path to password recovery and therefore administrative control.

Related learning

Continue with CentOS root password recovery procedures when reviewing the complete recovery workflow, or apply the same concepts while studying sudoers, SSH root-login policy, GRUB protection, SELinux labels, and out-of-band console management.