How to Recover a Locked-Out Linux VPS

You changed something — sshd config, ufw rule, sudoers, or PAM — and now you can't get in. Or maybe you forgot the root password. Or fail2ban banned your own IP. Whatever happened, the VPS is running, your data is intact, but you can't reach it. This guide covers the recovery routes that actually work, in order from least to most disruptive: console access, rescue mode, snapshot rollback, and full rebuild as last resort.

Before you start: triage

Diagnose what kind of locked-out you are. The fix depends on it:

• SSH refuses connection — sshd may be stopped, port may be blocked by firewall, or fail2ban banned your IP.
• SSH connects but auth fails — wrong key, wrong password, or PAM/sudoers misconfigured.
• Connection times out — VPS may be down, firewall blocking, or network issue.
• Login works but you can't sudo — sudoers file broken or your user removed from sudo group.
• Forgot root password — and key login also doesn't work, or you never set up a key.

Console access (route 1 below) gives you a fix path for all of these without leaving the VPS. It's the first thing to try.

Route 1: Provider web console (try this first)

Every reputable VPS provider — including OliveVPS — gives you a browser-based serial or VNC console to your VPS. This works regardless of SSH state, firewall rules, or network issues, because it's connecting through the hypervisor, not over the public internet to your VPS.

On OliveVPS:

1. Log into app.olivevps.com with your account credentials.
2. Go to Services → My Services → click the affected VPS.
3. Click "Console" (or VNC, depending on the panel version).
4. A new browser tab opens with a terminal showing your VPS login prompt — same as if you were sitting in front of it.

From console, you can log in as root (with the password from your provisioning email or whatever you changed it to) and fix things directly: edit configs, restart services, flush firewall rules. No SSH or network needed.

If you've forgotten the root password, console alone won't help — you'll need rescue mode (next).

Route 2: Rescue mode

Rescue mode boots your VPS from a separate live Linux ISO with your existing disk attached but not mounted as root. You log into the rescue OS, mount your disk, and edit files from outside your broken system. It's the equivalent of booting a USB recovery stick on physical hardware.

When rescue mode helps:

• You forgot the root password (chroot in and reset it).
• Your /etc/sudoers file is broken (visudo from outside).
• An sshd config change made the daemon refuse to start (revert from outside).
• Filesystem corruption needs fsck (can't run on a mounted root).

On OliveVPS, switch to rescue mode from the control panel: Services → My Services → VPS → "Boot into Rescue Mode". The VPS reboots into a temporary rescue OS; you SSH in with credentials shown in the panel. Your real disk is at /dev/vda (typically). Mount it:

# Inside the rescue environment
sudo mkdir /mnt/recover
sudo mount /dev/vda1 /mnt/recover

# For chroot operations:
sudo mount --bind /dev /mnt/recover/dev
sudo mount --bind /proc /mnt/recover/proc
sudo mount --bind /sys /mnt/recover/sys
sudo chroot /mnt/recover

# You're now "inside" your real system.
# Fix what's broken, then exit and reboot.

When you're done, exit the chroot, unmount, and reboot back to normal mode from the control panel. The VPS comes up with your fixes applied.

Route 3: Snapshot rollback

If you took a snapshot before making the change that broke things, rollback restores the entire VPS to that point. Pros: fast (minutes), preserves filesystem state exactly. Cons: any changes after the snapshot are lost — including legitimate work, database writes, file uploads.

Decide before rolling back: is the data created since the snapshot more valuable than the time to fix the lockout? For a quick config break, rescue mode is usually the right call. For a deeply corrupted system, rollback may be faster.

On OliveVPS: Services → My Services → VPS → Snapshots → Restore. Restoration takes 2-10 minutes depending on disk size. The VPS reboots when complete.

Route 4: Rebuild (last resort)

Reinstalling the OS wipes the disk and gives you a fresh VPS with the same IP, same hostname, same plan — but no data. You're back to a clean Ubuntu install. This only makes sense if:

• You have full backups of all data, configs, and applications.
• You're confident you can rebuild the application stack from those backups.
• Other recovery routes have failed or aren't available.

On OliveVPS: Services → My Services → VPS → Reinstall. Choose your OS image. The VPS rebuilds in 1-3 minutes. New root password and SSH keys are emailed to you.

Common in-rescue fixes

Reset root password (rescue mode)

# After mounting and chrooting:
passwd root
# (set new password, exit chroot, reboot)

Fix broken sudoers

# In chroot:
pkexec visudo
# OR if visudo errors:
sed -i 's/^bad_line/#bad_line/' /etc/sudoers

Restore SSH access

# Re-enable password auth temporarily (in chroot)
sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

# Re-enable root login (if you want it; usually no)
sed -i 's/^PermitRootLogin .*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config

# Add a known SSH key for your user
mkdir -p /home/youruser/.ssh
echo 'ssh-ed25519 AAAA...' >> /home/youruser/.ssh/authorized_keys
chown -R youruser:youruser /home/youruser/.ssh
chmod 700 /home/youruser/.ssh
chmod 600 /home/youruser/.ssh/authorized_keys

Disable a broken firewall

# In chroot, flush iptables/ufw rules so you can reach the VPS again
ufw disable
# OR
iptables -F
iptables -P INPUT ACCEPT

Unban your IP from fail2ban

fail2ban-client unban 

# Or temporarily stop fail2ban so you can get in
systemctl stop fail2ban

OliveVPS-specific recovery

We try to make recovery boring. Specifically:

• Console access on every plan — no extra charge, available immediately from the panel.
• Rescue mode on every plan — boots a Debian live ISO with your disk attached. Takes ~60 seconds to switch.
• Snapshots at $0.50/snapshot/month — take one before any risky operation. Worth the coffee money.
• 24/7 support — if all routes above fail, open a ticket. We can intervene at the hypervisor level for legitimately stuck VPSes.

Prevention

• Take a snapshot before risky changes. Editing sshd, ufw, sudoers, PAM? Snapshot first. 30 seconds of effort, infinite future you's gratitude.
• Test sshd config before restarting. sshd -t validates the config without committing.
• Keep a separate emergency user. A non-root user with sudo access and a backup SSH key, in addition to your normal user. If something locks out your main account, the emergency user gets you in.
• Set up an out-of-band SSH key. Use a yubikey-backed key from a separate device, stored offline. If your laptop dies and your only key is on it, you're locked out for no good reason.
• Document your firewall rules. Comment what each rule is for. When you wonder why some service is broken three months later, you'll thank yourself.
• Don't disable the console. Some hardening guides suggest disabling serial console — don't. It's your last lifeline.

FAQ