Losing SSH access to your VPS is stressful, but most causes are fixable without needing to rebuild the server. This guide walks through diagnosis in order, from simplest to most serious.
Step 1 — Verify Basic Connectivity
ping YOUR_SERVER_IPIf ping fails entirely, the server may be down at the network level, or ICMP is simply blocked (common and not necessarily a problem) — proceed to check the actual SSH port.
Step 2 — Check If the SSH Port Is Reachable
nc -zv YOUR_SERVER_IP 22Or your custom port if changed:
nc -zv YOUR_SERVER_IP 2222"Connection refused" means SSH isn't listening; "timed out" suggests a firewall or network-level block.
Step 3 — Confirm You're Using the Correct Port
If you previously changed the SSH port (see SSH Hardening guide), confirm you're specifying it:
ssh -p 2222 deploy@YOUR_SERVER_IPStep 4 — Check for "Permission Denied"
If you get a connection but authentication fails:
- Confirm the username is correct
- If using a key, verify the path:
ssh -i /path/to/key deploy@IP - If password authentication was disabled, only a valid key will work — no amount of retrying the password will succeed
Step 5 — Use Your Provider's Web Console (Critical Fallback)
Nearly every VPS provider offers a browser-based console/VNC that bypasses SSH entirely, logging in as if you had physical keyboard/screen access. This is the standard recovery path when SSH itself is misconfigured.
Step 6 — From the Console, Check the SSH Service
sudo systemctl status ssh
sudo systemctl start sshStep 7 — Check the SSH Configuration for Errors
sudo sshd -tIf this reports a syntax error, you likely introduced it during a recent edit. Review and fix:
sudo nano /etc/ssh/sshd_configsudo systemctl restart sshStep 8 — Check the Firewall from the Console
sudo ufw statusIf the correct SSH port isn't allowed:
sudo ufw allow 22/tcpOr your custom port. If UFW itself is misconfigured and blocking everything unexpectedly, you can temporarily disable it from the console to restore access, then fix the rules properly:
sudo ufw disableStep 9 — Check for Fail2Ban Having Banned Your Own IP
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR_IPThis happens more often than expected — several failed login attempts (even legitimate typos) can trigger a self-ban.
Step 10 — If PermitRootLogin/PasswordAuthentication Was Misconfigured
From the console, review and correct:
sudo nano /etc/ssh/sshd_configPermitRootLogin yes
PasswordAuthentication yesRestart SSH, log in, fix the actual intended configuration properly, then re-harden.
Common Errors and Fixes
| Error | Likely Cause |
|---|---|
| Connection timed out | Firewall blocking, or server unreachable |
| Connection refused | SSH service not running, or wrong port |
| Permission denied (publickey) | Wrong key, or password auth disabled |
| Host key verification failed | Server was reinstalled/changed; remove the old entry from your local known_hosts file after confirming it's expected |
Preventing This in the Future
- Always test a new SSH configuration in a second terminal before closing your current session
- Keep provider console access credentials documented and accessible
- Add your own IP to Fail2Ban's ignore list if you frequently trigger self-bans while developing
Related Articles
- SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys
- How to Install and Configure Fail2Ban on Ubuntu & Debian
- How to Configure UFW Firewall on a Linux VPS
