SSH Connection Refused — How to Fix It

What you're seeing

$ ssh [email protected]
ssh: connect to host example.com port 22: Connection refused

Variants you might see:

• Connection refused (most common — nothing listening on port)
• No route to host (different — network can't reach the IP at all)
• Operation timed out (different — packets sent but no response, usually firewall dropping silently)

If you see "No route to host" or "Operation timed out," this isn't your error — check ssh: connect to host port 22 operation timed out or your routing setup.

What's causing this error

Connection refused is a specific TCP-level signal: your client reached the server's IP, the network path is fine, but the kernel actively rejected the connection because no process is listening on that port. The four real causes:

1. sshd isn't running on the server. Either it crashed, was never started, or was disabled after a config change.
2. sshd is listening on a different port. Common after security hardening — sshd_config often has Port 2222 or similar. Your client is asking for 22, server only listens on 2222.
3. Firewall is blocking the port at a layer above sshd. Could be ufw/iptables on the host, an AWS Security Group, DigitalOcean Cloud Firewall, Hetzner firewall, or a corporate firewall on your network.
4. Wrong IP or hostname. DNS pointing at an old server, typo in the hostname, server moved to a new IP.

How to fix it

Step 1: Confirm the port-level problem

Before touching SSH, test the port directly. This tells you whether the issue is reachability or anything SSH-specific.

$ nc -vz your-server.com 22
# OR
$ telnet your-server.com 22

Three outcomes:

• Connection succeeded — port is open, problem is auth (you shouldn't be seeing "Connection refused" then; check ~/.ssh/config for the right host/port)
• Connection refused — nothing listening on that port. Go to step 2.
• Timeout / no response — firewall is silently dropping packets. Go to step 4.

Step 2: Check sshd is running on the server

You'll need shell access via your hosting provider's web console (DigitalOcean Console, AWS EC2 Serial Console, Hetzner Rescue) if SSH is your only way in.

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

If it's inactive or failed:

sudo systemctl start ssh
sudo systemctl enable ssh    # ensures it starts on boot

If it fails to start, check the logs for the actual error:

sudo journalctl -u ssh -n 50 --no-pager

The most common reason sshd refuses to start: a syntax error in /etc/ssh/sshd_config. Test the config:

sudo sshd -t

This prints the exact line number of any error.

Step 3: Check which port sshd is actually listening on

sudo ss -tlnp | grep ssh
# or
sudo netstat -tlnp | grep ssh

Expected: a line showing :22 or whatever port your sshd_config specifies. If it shows :2222 and your client is trying port 22, either:

• Connect explicitly: ssh -p 2222 [email protected]
• Or revert sshd to port 22: edit /etc/ssh/sshd_config, change Port 2222 to Port 22, restart sshd

To find the configured port:

sudo grep -E "^Port " /etc/ssh/sshd_config

Step 4: Check the firewall

Even if sshd is listening, a firewall above it can refuse the connection. Check in this order:

Host firewall (on the server):

# Ubuntu/Debian
sudo ufw status

# RHEL/CentOS/Fedora
sudo firewall-cmd --list-all

# Direct iptables check (any distro)
sudo iptables -L INPUT -n -v | grep -E "22|ssh"

If ufw shows port 22 not allowed:

sudo ufw allow 22/tcp
sudo ufw reload

Cloud provider firewall (above the OS):

• AWS EC2: Check the Security Group attached to the instance. Inbound rule for port 22 from your IP (or 0.0.0.0/0 if you don't need IP restriction).
• DigitalOcean: Networking → Firewalls. Confirm SSH (22) is in inbound rules.
• Hetzner Cloud: Project → Firewalls. Confirm port 22 TCP is allowed.
• GCP: VPC Network → Firewall. Confirm default-allow-ssh exists and applies to your instance.

Network firewall (your local side):

If you're on a corporate or hotel network, port 22 may be blocked outbound. Test by connecting from a different network (mobile hotspot is the fastest A/B test).

Step 5: Confirm the hostname resolves to the right IP

dig +short your-server.com
# or
nslookup your-server.com

Compare to what you expect. If DNS still points at an old server, update the A record and wait for propagation (or use the IP directly to verify).

Common edge cases