SSH Connection Refused or Timing Out: A Debugging Checklist

Locked out of your VPS? Work through connection refused vs timeout, firewall rules, sshd state and key problems methodically.

The error message is the map
SSH failures announce their category if you read them precisely. "Connection refused" means a machine answered and actively rejected you: the network path works, but nothing (or the wrong thing) listens on that port. "Connection timed out" means packets vanished: a firewall silently drops them or you are aiming at the wrong address. "Permission denied (publickey)" means SSH itself works fine and authentication is the problem. Each category has a completely different checklist, so classifying first halves the work.

Timeouts: walk the firewalls, outside in
Verify the IP: ping it, and check the provider dashboard, VPS IPs change after rebuilds, and stale SSH configs point at ghosts
Provider/cloud firewall: does a rule allow TCP 22 from your current IP? Office and home IPs change; allowlists silently go stale
Host firewall: ufw or iptables on the server itself, easy to lock yourself out by enabling ufw without ufw allow ssh first
Your side: corporate and hotel networks sometimes block outbound 22, test via phone hotspot to rule it out in one minute
fail2ban or provider intrusion protection may have banned your IP after repeated failed attempts, check from a different IP
Refused: get on the box out-of-band
Every serious VPS provider offers a web console (VNC/serial) that works even when SSH does not, this is your lifeline. Log in through it and inspect the daemon:

Common causes: a bad sshd_config edit (always run sshd -t before restarting), the daemon disabled after an update, or sshd moved to a non-standard port you forgot
Disk 100% full can also prevent sshd from accepting sessions, check df -h while you are there
systemctl status sshd # running? crashed? failed config?
journalctl -u sshd -n 50 # recent errors, bad config lines
ss -tlnp | grep sshd # which port is it actually on?
sshd -t # validate config syntax before restarting
Permission denied (publickey)
Authentication failures are almost always one of four things:

Wrong key offered: ssh -v shows which keys the client tries; specify explicitly with -i ~/.ssh/the_right_key
Wrong user: images differ, ubuntu on Ubuntu cloud images, root on many VPS defaults, debian, admin... check the provider docs
Server-side permissions: ~/.ssh must be 700 and authorized_keys 600, owned by the user; sshd silently ignores world-readable key files (visible in journalctl -u sshd)
PasswordAuthentication no with your key missing from authorized_keys entirely, fix via the web console
Lock-out-proofing for the future
Three cheap habits make lockouts a non-event: keep a second SSH key from a different machine in authorized_keys; when changing sshd config, keep your current session open and test a new connection before closing it; and know where your provider’s web console lives before you need it. Deployment platforms reduce day-to-day exposure too, with Peon managing servers over its own configured SSH access, your personal SSH sessions become rare, so there is less config churn to get wrong.