Recover lost root access

Losing root access happens for ordinary reasons: forgotten password, deleted SSH key, overly strict firewall rule, full disk or broken sshd configuration. The right reaction is not to reinstall immediately, because a reinstall destroys data. Take time to diagnose through the console and back up before any irreversible action.

First, locate the failure

Answer these questions before touching the system:

• Does the panel show the VPS running?
• Does the console show a login prompt, a kernel panic or an error message?
• Do df -h and journalctl -xb reveal a full disk or a failing service?
• Is the SSH port still listening?

A system container does not boot from a rescue image like a dedicated server. "Rescue mode" is limited to the console and the tools already present in the system. You must first observe the real state.

Regain control through the console

Open the noVNC console from the dashboard. If a local account with sudo exists:

sudo -i

Otherwise, log in as root with the known password, or use the reset offered by the panel. Once inside, inspect:

passwd -S root
ss -tlnp | grep :22
systemctl status ssh
ufw status verbose
df -h

passwd -S root reveals a locked account. ss shows whether sshd still listens. ufw explains a network block. df detects a full disk that prevents session keys from being written.

Repair without a network

• Locked account: passwd -u root then passwd root.
• sshd stopped: systemctl start ssh.
• Broken configuration: sshd -t, fix /etc/ssh/sshd_config, then systemctl restart ssh.
• Too strict firewall: allow the SSH port before re-enabling, or disable UFW temporarily from the console.
• Full disk: remove logs or caches, never random system files.
• Read-only filesystem: mount -o remount,rw / if the kernel allows it, then find the cause.

After each fix, test a new SSH login in a second session without closing the console.

Recover the data

If the system cannot be repaired, back up before reinstalling. From the console, with the network restored, copy the essentials to another server:

tar czf /root/backup.tar.gz /var/www /etc /home
scp /root/backup.tar.gz utilisateur@DESTINATION:/path/

Verify the archive (tar tzf) and test extracting it elsewhere. An unverified backup is not a backup.

Reinstall as a last resort

Reinstalling from the panel replaces the whole disk: files, databases, users, keys and certificates. It is justified only when data is exported and the cause is known, otherwise the problem may return. Before confirming, record the network configuration, domain names, ports and services. After reinstallation, recreate a sudo user, an SSH key and a firewall, then restore your data. When in doubt, contact support through the dashboard before destroying the service.