SSH connection refused: what it means and how to fix it

ssh: connect to host port 22: Connection refused is the kind of error that looks alarming but usually has a straightforward explanation. The server actively rejected your connection request. That is different from a timeout, which means the server did not respond at all.

Quick Answer: An "SSH Connection Refused" error means your client reached the server, but the server actively rejected the connection on port 22. To fix it, verify that the SSH daemon is running (sudo systemctl status sshd), check if SSH is listening on a non-standard port (like 2222), and ensure no host-level or cloud firewalls (like AWS Security Groups) are blocking inbound TCP port 22 traffic.

Here is a step-by-step diagnostic checklist to find the exact cause, starting with the most common culprits.

1. Cloud Provider Firewalls (AWS, Google Cloud, DigitalOcean)

If you are on a cloud provider, this is almost always the issue. A perfectly configured Linux server with the port blocked at the cloud level will still refuse connections. Security groups and VPC firewall rules sit entirely outside the operating system.

How to fix it:

• AWS EC2: Go to your EC2 dashboard, click your instance, and check the "Security" tab. Look at the attached Security Group. You need an Inbound Rule allowing TCP Port 22 from either 0.0.0.0/0 (anywhere) or your specific IP address.
• DigitalOcean: Check your Droplet's Cloud Firewalls under the Networking tab.
• Google Cloud: Check the VPC network firewall rules for an ingress rule on tcp:22.

2. SSH is not running on the server

If your firewalls are clear, the SSH daemon itself might be stopped or crashed. If you have another way to access the server (a cloud web console, VNC, or a physical keyboard), log in and check:

sudo systemctl status sshd

If it shows as inactive or failed, start it:

sudo systemctl start sshd
sudo systemctl enable sshd

3. The server is listening on a non-standard port

Many administrators move SSH off the default port 22 to reduce automated bot scanning. If SSH is running but you still get "connection refused", it might be listening somewhere else.

Check the active listening ports:

sudo ss -tlnp | grep ssh

If you see it listening on port 2222 or something similar, connect by specifying the port:

ssh -p 2222 user@host

(Note: If you use SSHDock, simply change the Port field in the connection form to match).

4. An internal firewall is blocking port 22

If the cloud firewall is open, check the internal OS firewall (iptables or UFW).

On Ubuntu/Debian using UFW:

sudo ufw status

If UFW is active and has no rule for port 22, add it:

sudo ufw allow 22/tcp

For CentOS/RHEL using firewalld:

sudo firewall-cmd --list-all
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

5. You are connecting to the wrong IP

DNS can point to old records. Run ping yourdomain.com and compare the IP address to what your server's dashboard shows. It sounds obvious, but verifying the IP saves a lot of wasted debugging time.

---

Still stuck? How to debug deeper

If nothing above works, try connecting with verbose output to get more information:

ssh -vvv user@host

The output will show exactly where in the handshake things fail. Look for lines starting with debug1: or debug3: that describe what the client tried and what it got back.

You should also check /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (RHEL/CentOS) on the server for any log entries around the time you tried to connect. Refused connections often leave a trace there.

Frequently Asked Questions

Is "Connection Refused" the same as "Connection Timed Out"?

No. "Connection Timed Out" means your computer sent a request and heard absolutely nothing back (usually indicating a strict drop firewall rule or a completely offline server). "Connection Refused" means your computer reached the server, but the server actively said "No" (usually because nothing is listening on that port, or a reject firewall rule is in place).

Can wrong SSH keys cause a connection refused error?

No. Wrong SSH keys, bad passwords, or incorrect file permissions on your ~/.ssh directory will result in a "Permission Denied (publickey)" error, not a connection refused error. If you get connection refused, you are failing at the network layer before authentication even begins.

Why does a fresh EC2 instance immediately refuse connections?

If this is a fresh server you just provisioned, give it 2-3 minutes. Some cloud images take time to fully boot, generate host keys, start the SSH daemon, and reach a ready state. Connecting within 30 seconds of launching the instance sometimes hits the daemon before it is fully up.