Locked Out of Your VPS? How to Regain SSH Access Fast

You SSH into your VPS the way you always do, and instead of a prompt you get "Connection refused" or the terminal just hangs. No error message that actually tells you what's wrong — just silence. If you've hardened SSH recently or tweaked a firewall rule, this is almost always self-inflicted, and it's fixable without reinstalling anything.

Symptom: what a lockout actually looks like

The exact message tells you a lot before you even open a recovery console:

• "Connection refused" — something is actively rejecting the connection on port 22. Usually the firewall (UFW/iptables) or sshd itself isn't running.
• Connection just hangs, then times out — packets are being silently dropped. Classic sign of a cloud provider's security group or a default-deny firewall rule with no allow for port 22.
• "Permission denied (publickey)" — the server is up and answering, but it doesn't accept your key or password. Usually a lost/wrong key, or PasswordAuthentication got disabled after you swore your key was already working.
• "Too many authentication failures" — you're bouncing between several keys in your SSH agent and the server is rejecting the connection before it even gets to yours.

Cause: the five usual suspects

Fix: get back in without touching SSH

Every path below assumes one thing: your VPS provider gives you an out-of-band console — a browser-based VNC/serial console that connects directly to the virtual machine, bypassing the network entirely. On Getwebup this is under VPS → Manage → Console in the control panel. If you've never opened it before, do it now, before you're locked out — it's the one thing that gets you in no matter what SSH is doing.

1. Log in through the console, not SSH

Open the web console and log in with your root/local credentials (not your SSH key — this is a direct terminal to the VM, like sitting at the machine). This works even if sshd is dead, the firewall is blocking every port, or your key is gone.

2. If it's Fail2Ban, unban your IP

From the console, check which jail banned you and clear it:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR.IP.ADDRESS.HERE

Find your current public IP with curl ifconfig.me from any other machine if you're not sure what got banned. If this keeps happening on a stable home/office IP, whitelist it permanently in /etc/fail2ban/jail.local:

[sshd]
ignoreip = 127.0.0.1/8 YOUR.IP.ADDRESS.HERE

Then sudo systemctl restart fail2ban.

3. If it's UFW, check and fix the rule

sudo ufw status numbered

If port 22 (or your custom SSH port) isn't in the allow list, add it before you do anything else:

sudo ufw allow 22/tcp
sudo ufw reload

If UFW is enabled and you genuinely can't tell what's wrong, disable it temporarily from the console to confirm that's the actual cause, fix the rule, then re-enable:

sudo ufw disable
# test SSH from another terminal
sudo ufw enable

4. If it's a cloud firewall / security group

This one won't show up in anything on the server itself — the block happens before traffic even reaches the VM. In the Getwebup control panel, open the VPS's Firewall tab and confirm there's an inbound rule allowing TCP 22 from your IP (or 0.0.0.0/0 if you want it open to anywhere, though a specific IP or range is safer). Provider-level firewalls and the OS firewall are two separate layers — you need both to agree.

5. If your key is lost or wrong

From the console, add a fresh public key to the authorized list:

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA...yourkey... you@laptop" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Generate a new key pair locally first if you don't have one handy: ssh-keygen -t ed25519. Copy the contents of the .pub file, not the private key, into authorized_keys.

6. If sshd itself won't start

Check the config for syntax errors before restarting — a bad edit will stop sshd from reloading and lock out everyone, including console-based root if you disabled that too:

sudo sshd -t
sudo systemctl status sshd
sudo systemctl restart sshd

sshd -t tells you exactly which line in sshd_config is broken before you restart the service, so you're not guessing.

7. Reset the root password if all else fails

If you can't get in even through the console (rare, but it happens with a corrupted PAM config), most providers offer a password reset from the VPS dashboard that regenerates root credentials and reboots the VM. On Getwebup, that's VPS → Manage → Reset Root Password. This is a last resort since it forces a reboot, but it always gets you back to a working login prompt.

Prevention: don't get locked out again

• Test firewall changes in a second session. Never close your only active SSH session until you've confirmed a new connection works from a fresh terminal.
• Always allow SSH before enabling UFW. ufw allow 22/tcp first, ufw enable second — not the other way around.
• Whitelist stable IPs in Fail2Ban so your own office or home connection never gets auto-banned after a typo.
• Keep a backup SSH key stored somewhere other than the laptop you SSH from daily.
• Bookmark your provider's console URL before you need it — digging through a dashboard while locked out wastes time you don't have.
• Run sshd -t after every sshd_config edit, before restarting the service.