How to Change Root Password in Linux: 3 Safe Ways (2026)

Losing the password to your own server feels worse than losing a house key. You can see the machine. You just cannot get in.

Learning how to change root password in Linux is the fix, and it splits into three situations: you still have a working shell, you have a normal account with sudo, or you have nothing at all. Each one has a different safe route.

Quick Answer: If you can still log in, run sudo passwd root, type the new password twice, and it applies instantly with no reboot and no service restart. If you cannot log in at all, boot the server into single user mode from the GRUB menu or start your provider's rescue environment, chroot into the disk, then run passwd root. As of September 2026, those three routes cover every mainstream Linux distribution in production.

Our engineers work through 20 to 30 client server issues every day, and a locked-out root account is one of the requests that lands at 2am. On a stack like Hostaccent's (UK-incorporated in 2018), the rescue console sits one click away, but every command below is identical on any Linux server you own. This is the walkthrough we give customers, written so you can do it yourself.

One warning before you start. All three methods need either an active session or console access to the machine, and that limitation is deliberate.

What the Root Password Actually Controls

Root is not a fancier admin account. Root is user ID 0, and UID 0 skips permission checks entirely, which is why one careless command as root can erase a disk that a normal user could not even read.

The password itself lives in /etc/shadow, one line per account, readable only by root. The second field of that line holds a hash. Ubuntu 24.04 hashes with yescrypt by default, while older builds and most RHEL-family systems use sha512crypt. Changing the password rewrites that one field and nothing else.

Changing the root password on a Linux server rewrites a single hashed field in /etc/shadow and takes effect at the next authentication attempt. Nothing restarts, no service reloads, and running SSH sessions stay connected. Key-based logins are untouched, because they authenticate against ~/.ssh/authorized_keys instead of the password file. That behaviour is identical on Ubuntu, Debian, AlmaLinux and Rocky as of September 2026.

Now the part that surprises people. A new root password does not:

• Enable root login over SSH. OpenSSH ships with PermitRootLogin prohibit-password, so root password logins stay refused until you edit sshd_config and reload the service.
• Touch your database credentials. The MySQL or MariaDB root user is a separate account inside the database engine, which is why How to Reset MySQL Root Password on Ubuntu (2026 Fix) is a different job with different commands.
• Change control panel, FTP or email passwords. Those live in their own user tables and their own config.
• Unlock a disabled account by itself. Ubuntu ships root with a locked hash, shown as ! or * in the shadow file.

Do I even need a root password on a VPS?

Yes, and the reason is practical rather than philosophical. If sshd breaks, a firewall rule locks you out, or the network config comes back wrong after a reboot, the serial or VNC console is the only door left. That console asks for a password, and SSH keys do not work there. A server whose root account has no usable password is a server you cannot rescue without rebooting it.

So set a long root password, store it in a password manager, keep PermitRootLogin disabled, and do daily work through a sudo user. The official Ubuntu Server documentation covers the account model in depth, and our Linux VPS Security Baseline (Ubuntu 24.04) in 30 Min turns the same principles into a checklist you can finish before lunch.

The 60-Second Access Check: Which Method You Need

Before touching anything, answer one question: what access do you still have right now? We call this the 60-Second Access Check, and it decides everything that follows. Choosing the wrong method turns a five-second job into a reboot in the middle of a working day.

Three access levels map to three methods. With a working shell, use passwd. With console access but no usable login, use single user mode from GRUB. With nothing but your provider's control panel, use rescue mode plus chroot. On a virtual machine, methods 2 and 3 both need the VNC or serial console, because the GRUB menu appears long before networking starts and never reaches your SSH client.

| What you still have | Method to use | Reboot required? | Typical downtime | |---|---|---|---| | A working root or sudo shell | Method 1: passwd | No | None | | Another user with sudo rights | Method 1 from that account | No | None | | Console access, no usable login | Method 2: single user mode | Yes | 2 to 5 minutes | | Provider panel access only | Method 3: rescue mode and chroot | Yes | 5 to 15 minutes |

The pattern we see in the support queue is worth knowing before you reboot anything: most people who believe they need method 3 actually need method 1. Check /home for a second account, or try the deploy user your developer created last year. Roughly half the password-recovery cases that reach our team end with a single sudo passwd root from an account the customer had forgotten about, and that route costs zero downtime.

Pro Tip: Open a second SSH session and leave it running before you change anything. Authentication already happened in that window, so it survives the change. If the new password does not work, that spare terminal is the difference between a two-minute fix and a rescue boot.

Two edge cases change the maths. If GRUB is password-protected (some hardened images do this), method 2 is closed to you and you go straight to rescue mode. If the disk uses LUKS full-disk encryption, no method works without the encryption passphrase, because the filesystem holding /etc/shadow cannot be read at all. That is not a bug. It is the entire point of encrypting the disk.

Method 1: How to Change Root Password in Linux With passwd

If you can open a shell, this is a one-command job. From an account with sudo rights:

bashCopy
sudo passwd root

Type the new password twice. Nothing echoes to the screen, and you are never asked for the old password, because sudo already proved who you are. If you are already root, plain passwd does the same thing. The passwd root command works from any privileged shell when you want to be explicit about which account you are editing, which matters on a box with several admin users.

The passwd command takes effect immediately: run sudo passwd root, enter the new password twice, and the next login uses it. Verify with sudo passwd -S root, which prints P for a usable password, L for locked, and NP for no password at all. No reboot and no service restart is needed on any current distribution.

That verification step is worth building into your habit:

bashCopy
sudo passwd -S root
root P 09/06/2026 0 99999 7 -1

A few variations you will eventually need:

• Automation without a prompt: echo 'root:YourNewPassword' | sudo chpasswd. Useful in provisioning scripts, risky at the keyboard, because the password lands in your shell history. If you must run it interactively, prefix the line with a space when HISTCONTROL=ignorespace is set, then clear it with history -d.
• Force a change at next login: sudo passwd -e root expires the password so the next person to log in has to set a new one. Handy after handing credentials to a contractor.
• Lock and unlock: sudo passwd -l root disables password authentication for the account, sudo passwd -u root restores it.

Pick something long rather than clever. Sixteen random characters from a password manager beats a memorable phrase with substitutions, since the second kind is exactly what cracking dictionaries model.

One thing to rule out before you go further: if your actual problem is a login failure in some other service, the root password is the wrong lever. A failing file transfer login, for example, is a completely separate credential store, which FTP 530 Login Authentication Failed: How to Fix It walks through properly.

◆ Professional help available

Still working through this server issue?

Send the symptoms, error output, and what you have already tried. We can work with Hostaccent services or infrastructure hosted with another provider.

Request server help→How server support works↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

Method 2: Reset the Root Password From Single User Mode

No sudo account, no working login, but you can reach the console? Then you interrupt the boot process and get a root shell before any authentication exists to stop you.

Single user mode resets a forgotten root password without any existing login. Interrupt GRUB, edit the kernel line to replace ro with rw and append init=/bin/bash, boot with Ctrl+X, remount the filesystem read-write, then run passwd root. The sequence takes two to five minutes on a typical VPS and requires console access rather than SSH.

Step by step:

1. Reboot with the console already open. Hold Shift on BIOS systems, or tap Esc repeatedly on UEFI, until the GRUB menu appears.
2. Highlight your default kernel entry and press e to edit it. Nothing you type here is permanent; it applies to this boot only.
3. Find the line starting with linux. Change ro to rw, then append init=/bin/bash at the end of that line.
4. Press Ctrl+X to boot. You land at a root shell prompt with no login.
5. Remount the filesystem as writable if you skipped the rw edit: mount -o remount,rw /
6. Set the password: passwd root
7. Reboot properly: exec /sbin/init or reboot -f. A plain reboot will hang, because PID 1 is bash right now, not systemd.

Ubuntu offers a friendlier variant. From GRUB, choose Advanced options, pick the recovery-mode kernel, then select "Drop to root shell prompt", remount with mount -o remount,rw /, and run passwd root. Be aware that on some builds this prompt asks for the existing root password first, which defeats the purpose. If it does, go back and use the init=/bin/bash route above.

On AlmaLinux, Rocky and other SELinux systems the sequence differs: append rd.break instead, then mount -o remount,rw /sysroot, chroot /sysroot, passwd root, and finally touch /.autorelabel before rebooting. Skip that last command and SELinux will refuse the relabelled shadow file, locking you out again after the reboot. The ArchWiki guide to resetting a lost root password documents the same kernel-parameter approach with additional variants such as the systemd debug shell.

Pro Tip: On a cloud VPS the GRUB menu is usually hidden behind a zero-second timeout, so you never get a chance to press e. Set GRUB_TIMEOUT=5 and GRUB_TIMEOUT_STYLE=menu in /etc/default/grub, run update-grub, and you have bought yourself a five-second rescue window on every future boot. Do it now, while you still have access.

Method 3: Change Root Password via Rescue Mode (Fully Locked Out)

When GRUB is unreachable, your console keystrokes are not registering, or the filesystem needs repair anyway, rescue mode is how you recover a VPS root password. Your provider boots the server from a separate live system with your disk attached but not mounted, and you fix things over SSH instead of a laggy console.

Rescue mode changes the root password on a server you cannot boot into normally. The provider starts a temporary live environment with your disk attached; you mount the root partition, bind-mount /dev, /proc and /sys, chroot into the system, then run passwd root. Expect five to fifteen minutes of downtime, and confirm you are inside the chroot before setting anything.

bashCopy
# 1. Find the real root partition (skip the ~500MB boot or EFI one)
lsblk

# 2. Mount it
mount /dev/vda2 /mnt

# 3. Bring the kernel interfaces along
mount --bind /dev  /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys  /mnt/sys

# 4. Become your own system
chroot /mnt /bin/bash

# 5. Now, and only now, set the password
passwd root

# 6. SELinux systems only
touch /.autorelabel

# 7. Leave cleanly
exit
umount -R /mnt

If lsblk shows LVM volumes rather than a plain partition, run vgchange -ay first and mount the logical volume (something like /dev/mapper/ubuntu--vg-ubuntu--lv) instead. Then disable rescue mode in the panel and reboot into your normal system.

Insider Insight: The single most common failure in rescue mode is changing the wrong password. Run passwd before chroot and you have just reset the throwaway rescue system, which is destroyed the moment rescue mode ends. After chrooting, run ls / and look for your own directories, such as /var/www or /home/yourclient. If they are not there, you are not inside your system yet.

Across the 4,000+ sites Hostaccent has migrated since 2016, that missing chroot is the step people get wrong more than any other during a recovery boot, and it is the reason a password "does not work" after the reboot even though passwd reported success.

While you are in there, consider skipping passwords entirely. Appending your public key to /mnt/root/.ssh/authorized_keys (correct permissions: 700 on .ssh, 600 on the file) gets you back in over SSH without ever typing a password, which is the more durable fix for a machine you administer alone.

After the Reset: The Mistakes That Cause Real Outages

The most common failure after a root password change is not the change itself. It is the assumption that root can now log in over SSH. OpenSSH refuses root password logins by default under PermitRootLogin prohibit-password, so your new credential works on the console and nowhere else until sshd_config is edited and the service reloaded. The authentication methods a server will even offer are negotiated at connection time, as specified in RFC 4252, the SSH Authentication Protocol.

The rest of the list comes from cleaning up after other people's password changes:

• passwd: Authentication token manipulation error. Almost always a read-only filesystem (remount with rw), a full disk, or exhausted inodes. Check df -h and df -i before blaming PAM.
• A weak password on a box with password authentication exposed. Port 22 gets scanned constantly on any public IP. If you enable root password logins, you have handed brute-force bots a known username. The OWASP Cheat Sheet Series covers credential handling properly, and our How to Secure a VPS: Complete 2026 Hardening Guide covers the server side, including fail2ban and key-only access.
• Cloud-init overwriting your work. On some images, rebuilding or reimaging resets credentials from the provider's metadata service. Change the password after the rebuild, never before.
• Forgetting the SELinux relabel. Covered above, and the reason for a specific kind of second lockout that feels like the first one all over again.
• Closing your only session before testing. Verify from a second terminal first, always.

Handling 20 to 30 client server issues every day, the Hostaccent team sees the same follow-on failure repeatedly: the password change worked, the reboot worked, and then a backup job, a monitoring agent or a deployment script that stored the old credential starts failing quietly at 3am. Nobody notices until a restore is needed. Make a list of everything that authenticates to the server, then work through it. That list usually includes cron jobs, your uptime monitor, any CI runner, and anything renewing certificates, which is one route into the situation described in Certbot Renewal Failed? Fix Let's Encrypt SSL (2026).

Pro Tip: After any root password change, run sudo passwd -S root and then authenticate once from a second terminal with su -. Two commands, ten seconds, and you find out now rather than during your next emergency.

One last honest point about threat models. Rotating the root password does nothing against an attacker who already has a foothold through your web application, because they are not knocking on port 22. Application-layer abuse needs application-layer defences, which is the job Nginx Rate Limiting: Basic DDoS & Bot Protection handles.

Your Next Step: A Server You Can Always Get Back Into

Now that you know how to change root password in Linux from a live shell, from single user mode, and from a rescue environment, the real question is whether your host gives you that third door when your server stops answering. Plenty of cheap boxes do not. You could keep hoping you never need it, or start somewhere the rescue console is already waiting for you. Start on the Basic Linux VPS at $7.99/mo: full root access, free 30 Gbps DDoS filtering, a 99.99% uptime guarantee, and support from our own engineers. One honest limit: no VPS under $10 includes a cPanel licence, since the licence alone costs more than the server, so budget separately or take Standard at $12.00/mo. What Hostaccent quotes is what you renew at.

Frequently Asked Questions About Changing the Root Password

How to change root password in Linux without the old password?

You need privilege from somewhere else, because passwd will not overwrite root's hash for an unprivileged user. With a sudo account, sudo passwd root sets a new password and never asks for the old one. With no usable account at all, boot into single user mode from GRUB or start your provider's rescue mode, chroot into the disk, then run passwd root there. Console or hypervisor access is the requirement in every case, which is why physical security still matters.

Does changing the root password disconnect my current SSH session?

No. Authentication happens once, when the session opens, so an existing shell keeps running normally after the hash changes. Only the next login attempt uses the new password. That is exactly why you should keep one terminal open while testing the new credential in a second window. If you typed something you cannot reproduce, that open session is your way back in without a reboot or a rescue boot, and it costs you nothing to leave running.

Why does passwd say "Authentication token manipulation error"?

Three causes cover nearly all of them. The filesystem is mounted read-only, which is normal in single user mode until you run mount -o remount,rw /. Or the disk is full and /etc/shadow cannot be rewritten, so check df -h for space and df -i for inodes. Or a PAM password policy rejected your value. Fix the mount or the disk first, then run passwd again and it usually succeeds immediately.

Can I reset the root password on a VPS without console access?

Usually yes, through your provider's panel. Most VPS platforms offer a rescue or recovery boot that starts a separate live system with your disk attached, which you then mount and chroot into over SSH. Hostaccent customers get that rescue environment plus 24/7 help from our own engineers, so a locked-out server is a ten-minute job rather than a rebuild. Without console or rescue access, restoring from a backup is the only remaining route.

Should the root account be enabled on a production server?

Give root a strong password so the console works in an emergency, then keep password logins disabled over SSH. That combination gives you recovery without exposure. Day to day, work through a sudo user with its own credential and its own audit trail. Shared root logins across a team make incident review nearly impossible, because every action in the logs belongs to the same anonymous account and nobody can say who ran what.

How often should I change the root password on a Linux server?

Rotate on events, not on a calendar. Change it when someone with access leaves, when a device holding it is lost, when a support case required sharing it, and after any suspected compromise. Forced 90-day rotation pushes people toward weak, predictable variations, which is why modern security guidance dropped the practice. A long random passphrase stored in a password manager beats a short one changed four times a year.