Locked out of your own VPS is a special kind of frustrating. SSH just sits there rejecting your password, you can't remember what you set six months ago, and the person who provisioned the server left the company. If you're staring at a "Permission denied (publickey,password)" message right now, don't panic and don't reinstall the whole server. In almost every case you can get back in through rescue mode without losing a single file.

This guide covers the three ways to recover root access on a Linux VPS, from easiest to "last resort," plus what to do afterward so this never happens again.

Why This Happens

A forgotten or lost root password usually comes down to one of these:

  • The server was handed off from a previous admin, developer, or agency who didn't share credentials
  • You disabled password auth in sshd_config for security but never tested key-only login before rebooting
  • A password manager entry got deleted, overwritten, or the vault was never set up for that server
  • The VPS was restored from an old snapshot with an outdated password
  • Someone fat-fingered a passwd change and the new one didn't stick

None of these damage your data. Root password resets happen at the OS level, completely separate from your files, databases, and websites.

Before You Start

You'll need access to your SkyServer client area (or WHM/VPS control panel) with permission to manage the server — that's it. You do not need the old password, SSH access, or a working console session. If your site is live and serving traffic, none of the methods below cause downtime for visitors; only your own admin access is affected during the process.

Method 1: Reset via the VPS Control Panel (Try This First)

Every modern VPS platform, including SkyServer's, has a built-in password reset that doesn't require booting into anything special. It works because the hypervisor can inject a new password directly into the guest OS on next boot.

  1. Log in to your SkyServer client area and open the VPS in question
  2. Look for Manage → Root Password (or Reset Password, depending on the panel version)
  3. Generate or type a new strong password — 16+ characters, no dictionary words
  4. Confirm the reset. Most platforms apply it live; some require one reboot
  5. Wait 60-90 seconds, then try ssh root@your-server-ip with the new password

If this option isn't visible or the reset silently doesn't take effect (common on older KVM images without guest agent support), move on to Method 2.

Method 2: Rescue Mode + chroot (When the Panel Reset Fails)

Rescue mode boots your server from a temporary recovery image instead of its own disk. Your actual disk gets mounted as a secondary volume, so you can edit files on it — including the password database — without your normal OS running at all.

  1. In the VPS control panel, find Rescue Mode or Recovery Mode and boot into it. You'll usually get temporary root credentials for the rescue environment itself — save those, they're different from your real server's password
  2. SSH into the rescue environment: ssh root@your-server-ip (using the rescue password, not your old one)
  3. Find your real disk. It's often already mounted, or list partitions with lsblk or fdisk -l
  4. Mount it if it isn't already: mount /dev/sda1 /mnt (adjust the device name to match your setup)
  5. Chroot into your actual OS so commands run against it instead of the rescue image: chroot /mnt
  6. Reset the password normally: passwd root, type the new one twice
  7. Exit the chroot with exit, unmount with umount /mnt
  8. Go back to the control panel and reboot the server into its normal disk (not rescue mode)
  9. Once it's back up, SSH in with the new password

If your root partition is on LVM, you'll need an extra step: run lvm vgscan and lvm vgchange -ay before the volume shows up for mounting.

Method 3: Single-User Mode via GRUB (VNC/Console Only)

This is the fallback when there's no rescue mode option at all — usually on bare-metal or older VPS nodes. It requires access to a VNC or serial console from your provider, since you're interrupting the boot sequence itself.

  1. Open the VNC/console session and reboot the VPS
  2. The moment the GRUB menu appears, press e to edit the boot entry (you may need to tap a key repeatedly to catch the menu before it auto-boots)
  3. Find the line starting with linux or linux16 and add rd.break at the end (RHEL/CentOS/AlmaLinux) or add single at the end (Debian/Ubuntu) to boot straight into a root recovery shell
  4. Boot with Ctrl+X or F10
  5. On RHEL-family systems you'll land in a limited shell — run mount -o remount,rw /sysroot, then chroot /sysroot, then passwd root
  6. On Debian/Ubuntu you'll drop straight to a root shell — the filesystem is often read-only, so run mount -o remount,rw / first, then passwd root
  7. Run touch /.autorelabel on SELinux-enabled systems (RHEL family) to avoid a login lockout from mismatched security contexts
  8. Reboot normally: exec /sbin/init or a hard reset from the console, then log in with the new password

After You're Back In

Don't stop at the password reset. Do these three things in the same session:

  • Check /var/log/auth.log or /var/log/secure for failed login attempts around the time you lost access — rule out that this was an actual compromise, not just a forgotten password
  • Confirm PermitRootLogin and PasswordAuthentication in /etc/ssh/sshd_config are set the way you intend, then restart SSH: systemctl restart sshd
  • If you use CSF or another firewall, verify your own IP isn't accidentally blocked from a previous brute-force lockout

Prevention: Don't Let This Happen Twice

Do thisWhy it helps
Switch to SSH key authenticationNo password to forget, and it's harder to brute-force
Store credentials in a shared password manager (Bitwarden, 1Password)Survives staff turnover — no more "only Dave knew the password"
Create a named sudo user instead of using root day-to-dayGives you a second way in if one account gets locked
Test console/VNC access once, before you need it in an emergencyYou don't want to be learning the interface while a site is down
Enable 2FA on your SkyServer client areaProtects the account that controls password resets in the first place

Frequently Asked Questions

Will resetting my root password delete any data?

No. All three methods only touch the password/shadow file on your existing disk. Websites, databases, and email accounts are untouched — you're not reinstalling or reformatting anything.

What if I can't find a rescue mode option in my control panel?

Open a support ticket with your hosting provider and ask for VNC/console access instead. Every VPS provider offers at least one recovery path; it's just not always labeled "rescue mode."

I reset the password but SSH still rejects it. What's wrong?

Check that PasswordAuthentication yes is actually set in /etc/ssh/sshd_config — if key-only login is enforced, no password will ever work over SSH. In that case, add your public key to /root/.ssh/authorized_keys while you're still in the rescue chroot.

Is it safe to keep using root for everyday login after this?

It works, but it's worth creating a separate sudo user while you're already in maintenance mode. If that account ever gets locked or compromised, root stays available as a fallback instead of being your single point of failure.

Can I avoid rescue mode entirely by using cloud-init?

Yes, if your VPS image supports it. Cloud-init can inject a fresh SSH key or password on every boot from the control panel, which is effectively what Method 1 relies on. It's worth confirming it's enabled when you first provision a server, not after you're already locked out.