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
sudocan 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
| Method | Required access | Reboot required | Main command or action | Best use case | Key limitations |
|---|---|---|---|---|---|
| Sudo-enabled account | Logged-in account authorized by sudoers, commonly through the wheel group | No | sudo passwd root | The administrator can log in and knows the current account password | Does not work without a permitted sudo account |
| GRUB and chroot recovery | Physical, serial, or virtual-machine console access | Yes | Edit the kernel command line, then use chroot /sysroot and passwd | No usable sudo account is available | Requires 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 rootThe prompts have an important order:
sudoasks for the password of the currently logged-in administrative user. It does not ask for the old root password.passwdasks for the new root password.passwdasks 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 successfullyPassword 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/shThe 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 /sysrootAfter 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
passwdEnter 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 /.autorelabelOn 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 -fAfter the system starts normally, test the new credential through an approved local console or administrative workflow.
Filesystem root and chroot explained
| Term | Meaning in this procedure |
|---|---|
| Recovery shell | A minimal shell started during early boot, outside the normal installed operating system environment |
/sysroot | The mount location representing the installed CentOS filesystem |
| A command that changes the apparent root directory for the current process | |
passwd | The 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 parameter | Purpose | Where it is used | Expected result |
|---|---|---|---|
sudo passwd root | Set a new root password using delegated privileges | Running CentOS system | Sudo authenticates the current user, then passwd updates root's password |
rw init=/sysroot/bin/sh | Request a read-write installed filesystem and a sysroot recovery shell | Editable GRUB kernel command line | Boot enters an early recovery shell; syntax varies by release |
chroot /sysroot | Enter the installed filesystem context | Recovery shell | Commands operate against the installed CentOS system |
passwd | Assign a new password to root | After chrooting | New root password is written to the installed system |
touch /.autorelabel | Request an SELinux filesystem relabel | After chrooting, when applicable | Relabeling occurs during the next boot |
reboot -f | Force a restart from a limited recovery environment | Recovery shell | System restarts so normal boot can continue |
Access prerequisites by environment
| Environment | Suitable recovery access | Examples |
|---|---|---|
| Physical server | Direct keyboard and display access during startup | Rack console, attached monitor, and keyboard |
| Serial-managed server | Serial console with boot-time input enabled | Out-of-band management controller or serial concentrator |
| Virtual machine | Hypervisor virtual display and keyboard console | VM console used to interrupt startup and edit GRUB |
| Remote-only server without out-of-band console | Usually insufficient for GRUB recovery | SSH 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
- Verify root authentication through an approved local console or administrative workflow.
- Confirm that the system completes a normal boot and that sudo access still works for authorized administrators.
- Use a strong, unique root password and store it through the organization's approved password-management process.
- Review whether direct root login, especially over SSH, is permitted by policy. Keeping it disabled is often appropriate.
- 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.