SSH Connection Refused or Timed Out: How to Get Back Into Your Server

You type your SSH command. Instead of the familiar login prompt, you get one of these:

ssh: connect to host 203.0.113.10 port 22: Connection refused

ssh: connect to host 203.0.113.10 port 22: Connection timed out

Your site might be down. Your app might be broken. And you can't even get in to look at it. You're locked outside the building and the keys don't work.

Take a breath. These two errors mean different things, and once you know which one you have, you can figure out what happened.

"Connection refused" vs. "Connection timed out"

These look similar but they're telling you completely different things.

Connection refused means your computer reached the server, knocked on the door, and the server said "no." The server is running, it heard you, but nothing is listening on that port. Either the SSH service crashed, it's running on a different port, or a firewall explicitly rejected the connection.

Connection timed out means your computer knocked and nobody answered at all. Your request went out and disappeared into the void. Either the IP address is wrong, a firewall is silently dropping your packets, or the server itself is down.

Refused = the server is there but won't let you in. Timed out = you can't even reach the server.

The most common causes

1. You set up a firewall and locked yourself out

This is the number one cause. It deserves its own section, so keep reading.

2. The SSH service isn't running

SSH is a program that runs on your server. If it crashes or gets stopped, there's nothing listening for your connection. This can happen after a server reboot, a bad update, or if the disk filled up and the service couldn't start.

Signs: You get "connection refused," your website might still be working (the web server is a different program), and this started after a reboot or update.

3. You changed the SSH port and forgot

At some point — maybe because an AI suggested it for "security" — you changed SSH from the default port 22 to something else like 2222 or 2200. Now you're trying to connect on port 22 and nothing is there.

Try: ssh -p 2222 user@your-server — if that works, mystery solved.

4. Your IP address changed

If your VPS provider gave you a dynamic IP, or if you're connecting from home and your ISP changed your home IP, things can break. If your firewall only allows SSH from a specific IP and that IP changed, you're locked out.

5. SSH key permissions are wrong

SSH is very particular about file permissions. If your key file or the .ssh directory on the server has the wrong permissions, SSH will refuse to authenticate you. You'll usually see a more specific error like "Permission denied (publickey)" rather than "connection refused," but it's worth knowing about.

6. The disk is full

When the server's disk fills up, things start failing in weird ways. SSH might not be able to start, log files can't be written, and the whole system gets unstable. This happens more often than you'd think, especially on small VPS instances where log files or database backups grow unchecked.

The AI firewall disaster

This is the single most common way people lock themselves out of a server, and it happens the same way almost every time.

You ask the AI to help you secure your server. The AI tells you to set up a firewall. It gives you commands like this:

sudo ufw enable
sudo ufw allow 80
sudo ufw allow 443

That enables the firewall and opens ports for web traffic. Looks great. The AI even explains what each command does. What it doesn't tell you is that you needed to do this first:

sudo ufw allow 22

Port 22 is SSH. The moment you ran ufw enable without allowing port 22, the firewall started blocking your SSH connection. Your current session might keep working for a while, but the moment you disconnect, you're done. You can't get back in. And you can't undo the firewall because you'd need SSH to do that.

It's like locking yourself out of your car while the engine is running. Everything looks fine until you close the door.

The same thing happens with iptables. The AI gives you a set of rules, you apply them, and SSH wasn't in the list. Locked out.

What to try right now

Step 1: Is the server even reachable?

ping your-server-ip

If you get responses, the server is running and reachable. The problem is with SSH specifically. If you get no response, the server might be down or a firewall is blocking everything.

Step 2: Try from a different network

If you're on your home network, try from your phone's hotspot. If you're at a coffee shop, try from home. Some networks block outgoing connections on port 22. Some firewalls are configured to only allow certain source IPs. Trying a different network rules out both of these.

Step 3: Check if you changed the port

ssh -p 2222 user@your-server
ssh -p 2200 user@your-server

Try the common alternative ports. If one of them works, you just forgot which port you switched to.

Step 4: Use your VPS provider's web console

This is usually the way out. DigitalOcean, Vultr, Linode, Hetzner, AWS — every major VPS provider has a web-based console that lets you access your server through the browser. It works even when SSH is completely broken because it doesn't use SSH at all. It's a direct connection to the server's virtual screen.

Log into your VPS provider's dashboard and look for "Console," "VNC," "Web Console," or "Recovery Console." Once you're in, you can check the firewall rules, restart SSH, or fix whatever went wrong.

If the firewall locked you out, the fix from the console is:

sudo ufw allow 22
sudo ufw reload

Or if you want to start over with the firewall:

sudo ufw disable

Step 5: Rescue mode

If the server won't even boot properly, most VPS providers offer a "rescue mode" that boots the server from a temporary system. You can then mount your server's disk and fix configuration files. This is the nuclear option — but it works when nothing else does.

Step 6: Contact your VPS provider

If none of the above works, open a support ticket with your provider. They can see things you can't — whether the server is actually running, whether there are network issues on their end, and whether the server's disk or hardware has a problem.

How to never lock yourself out again

Once you're back in, here's how to make sure this doesn't happen again:

Always allow SSH before enabling a firewall. Always. The command order is:

sudo ufw allow 22
sudo ufw enable

Not the other way around. If the AI gives you firewall commands and ufw allow 22 isn't the very first one, add it yourself before running anything.

Keep a console session open while changing firewall rules. Open a second terminal, SSH into the server, and leave it connected. Make your firewall changes in the first terminal. Try to connect in a third terminal. If it works, great. If it doesn't, you still have that second session to undo the damage.

If you change the SSH port, write it down. Put it in a password manager, a notes file, anywhere you'll find it six months from now when you've forgotten.

Set up monitoring. A simple uptime check that pings your server and alerts you when it's down. You don't want to find out your server is unreachable from a customer email.