Sooner or later a firewall rule, an SSH config edit or a failed upgrade will lock you out of your own VPS. This is recoverable almost every time, and panicking into a rebuild is the one action that turns it into real data loss. This guide gives you the recovery ladder - least destructive first - and how to work out which rung you need.
Step 1 - Work out what is actually broken
"Cannot reach the server" covers several very different problems. Two commands narrow it down:
ping your.vps.ip.address
ssh -vvv root@your.vps.ip.address| What you see | Likely cause | Go to |
|---|---|---|
| Ping works, SSH refused | SSH service stopped, or port changed | Console (Step 2) |
| Ping works, SSH times out | Firewall is dropping your connection | Console (Step 2) |
| SSH asks for a password you do not have | Key auth broken, or wrong user | Console (Step 2) |
| Nothing responds at all | Server off, kernel panic, or failed boot | Console, then reboot (Steps 2-3) |
| Works from your phone but not your office | Your own network, or your IP was banned | See "banned yourself" below |
| SSH host key warning | Server was rebuilt - or something is wrong | See below |
Always test from a second network first - mobile data is ideal. It takes ten seconds and distinguishes "the server is broken" from "my office is blocked", which are opposite problems.
Step 2 - Use console access
Console access connects you to the server below the network layer, so it works when SSH, the firewall and even networking are broken. It is the single most useful recovery tool you have.
- Sign in at my.fasthive.com.
- Open My Products & Services and select your VPS.
- Open the console from the service page.
- Log in as root at the prompt.
You now have a shell regardless of the network. Common fixes from here:
# SSH not running?
systemctl status sshd
systemctl start sshd
# Config broken? -t names the offending line
sshd -t
# Firewall locked you out
ufw allow OpenSSH # or: ufw disable (temporarily)
firewall-cmd --permanent --add-service=ssh && firewall-cmd --reload
# fail2ban banned you
fail2ban-client status sshd
fail2ban-client set sshd unbanip YOUR.IP.ADDRESS
# Disk full? A full disk breaks logins in confusing ways
df -h
journalctl --vacuum-size=200MStep 3 - Reboot, gently first
If the console shows a hung or unbootable system, try a graceful Reboot from the client area before a hard power cycle. A hard power off risks filesystem damage exactly as an unexpected power cut would.
If it will not boot after a kernel update, use the console to catch the boot menu and select the previous kernel - that gets you back in, and you can then fix or roll back the update properly.
Step 4 - Restore a snapshot
If you cannot repair it from the console, restore the snapshot you took before the change, or a nightly image.
Before confirming, copy off anything written since that point - a database dump, recent uploads, logs. A restore discards everything after the snapshot, and the console gives you a shell to rescue files from even when the network does not.
Step 5 - Rebuild, only as a last resort
A rebuild erases the disk and installs a fresh operating system. Do it only when the server is genuinely unrecoverable, or when it has been compromised and cannot be trusted.
Specific situations
You banned your own IP address
Use the console to unban it, then add your address to fail2ban's ignoreip so it cannot recur. If your office IP changes often, that list needs maintaining.
You disabled password auth before testing your key
Console in, set PasswordAuthentication yes temporarily, run sshd -t, restart SSH, then fix the key properly. Check ~/.ssh is 700 and authorized_keys is 600 - SSH silently ignores loose permissions, which is the usual cause.
You changed the SSH port and forgot it
# From the console
grep -i '^Port' /etc/ssh/sshd_config
ss -tulpn | grep sshdHost key warning on connecting
Expected after a rebuild or reinstall - clear the stale entry with ssh-keygen -R your.vps.ip.address. If you did not rebuild, stop and investigate: a changed host key can indicate interception.
The disk filled up
A full disk prevents logins from writing session files, so it can look like an authentication failure. Free space from the console, then find the cause with du -sh /* | sort -h.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Console shows a login prompt but the root password is rejected | You may never have set one, having deployed with an SSH key. Reset the root password from the client area, then use the console. |
| Console is blank | Press Enter to wake it. If still blank, the server may be off or mid-boot - check status and reboot. |
| Server boots into emergency mode | A filesystem problem, often a bad /etc/fstab entry. Read the message, comment out the offending mount, reboot. |
| SSH works for root but not your user | Key permissions or ownership on that user's ~/.ssh. Check from the console. |
| Everything looks fine but the site is unreachable | The server is up and only the web service is down. That is not a lockout - check the service and its logs. |
| You rebuilt and lost data | Ask Technical Support about the nightly off-server images immediately - retention is finite, so hours matter. |
Frequently asked questions
Does console access work when the firewall blocks everything?
Yes. It connects below the network layer, which is exactly why it is the first tool to reach for.
Can Fast Hive log in and fix it for me?
The operating system is yours on an unmanaged plan, so we do not hold your credentials. We provide console access, restore images, and confirm the platform is healthy - and we will help you interpret what you find. See the VPS support scope article.
Will rebooting lose my data?
A graceful reboot does not. A hard power off can lose unwritten data. A rebuild loses everything - do not confuse the two.
How do I avoid this next time?
Keep a second SSH session open during risky edits, validate with sshd -t before restarting SSH, allow SSH in the firewall before enabling it, and snapshot before changes to authentication.
Should I keep root password login enabled as a fallback?
No. The console is your fallback, and it does not weaken security. Keep SSH key-only.
My IP changes constantly and fail2ban keeps banning me.
Add your range to ignoreip, or raise the retry threshold. Repeatedly unbanning yourself from the console is a sign the configuration needs adjusting, not repeating.
