SSH Connection Refused on Port 22: How to Fix It

You try to connect, and the error comes back instantly:

ssh: connect to host 203.0.113.10 port 22: Connection refused

The important word is instantly. Unlike a timeout — which hangs for 30 seconds or more before failing — "Connection refused" comes back right away. That's actually good news: it means your network reached the server, and something on the other end actively said no.

That narrows the problem down a lot. Here's how to find it.

Connection refused vs. timed out

These two errors get confused constantly, but they mean opposite things:

• Connection refused (instant) — you reached the machine, but nothing is listening on that port, or a firewall actively rejected the connection
• Connection timed out (hangs, then fails) — you never reached a listening service at all: wrong IP, a network block, or a firewall silently dropping packets

If yours hangs before failing, it's a timeout — a different problem with different causes. This guide is for "refused."

Step 1: Is the SSH service running?

The most common cause is simple: the SSH server (sshd) isn't running on the host. Open the server's console — your cloud provider's web terminal — and check:

sudo systemctl status ssh      # Debian / Ubuntu
sudo systemctl status sshd     # RHEL / CentOS / Fedora

If it's not running, start it and enable it on boot:

sudo systemctl start ssh
sudo systemctl enable ssh

Some minimal server images don't ship with SSH installed at all:

sudo apt update && sudo apt install openssh-server -y

Step 2: Is SSH on a different port?

If the server runs SSH on a non-standard port — a very common hardening step — connecting to port 22 gets refused. Try the actual port:

ssh -p 2222 user@server

Not sure which port? From the server console:

sudo grep -i port /etc/ssh/sshd_config
sudo ss -tlnp | grep ssh

Once you know it, save it in ~/.ssh/config so you never think about it again:

Host server
  HostName 203.0.113.10
  User deploy
  Port 2222

Step 3: Check the firewall

A firewall on the server can reject SSH outright. Check the common ones from the console:

sudo ufw status                # Ubuntu
sudo firewall-cmd --list-all   # RHEL / CentOS

Allow your SSH port:

sudo ufw allow 22/tcp          # or your custom port
sudo ufw reload

On cloud providers there's a second firewall outside the OS — AWS Security Groups, DigitalOcean Cloud Firewalls, Hetzner Firewall, Oracle Cloud security lists. Open your provider's dashboard and make sure inbound TCP on your SSH port is allowed.

Step 4: Confirm you've got the right host

"Refused" can also mean you reached a machine — just not the one running your SSH server. Double-check:

• The IP address is current. Cloud instances often get a new public IP after a stop/start.
• You're not connecting to a load balancer or proxy that doesn't forward port 22.
• DNS for your hostname points where you think it does:

dig +short server.example.com

Step 5: Test the port directly

Isolate whether it's SSH or the network. From your Mac:

nc -vz server.example.com 22

• succeeded → the port is open; the problem is your SSH config or credentials, not the connection
• Connection refused → nothing is listening there; go back to Steps 1–3
• hangs / timed out → it's a network or firewall drop, not a refusal

From the server side, confirm sshd is bound correctly:

sudo ss -tlnp | grep :22

If sshd is listening on 127.0.0.1:22 instead of 0.0.0.0:22, it only accepts local connections — check the ListenAddress line in sshd_config.

Quick checklist

• sshd is installed and running on the server
• You're connecting to the correct port
• The OS firewall (ufw / firewalld) allows your SSH port
• The cloud provider's firewall or security group allows it too
• The IP address and DNS are current and correct
• nc -vz host 22 confirms the port is actually open

A faster way to manage connections

"Connection refused" is almost always a port or firewall mismatch — and the more servers you run, the more often a forgotten custom port or a stale IP trips you up.

Pluto Door keeps each server's port, IP, and username stored together, so you connect with one click instead of remembering which box runs SSH on 2222. When a connection fails, it shows you the real reason — refused, timed out, or auth — so you know exactly which step above to jump to.

Work down the list in order and you'll find it fast: service, port, firewall, host. It's nearly always one of those four.