Connection Refused on SSH Port 22: Refused Is Not Timed Out

Connection refused and Connection timed out are different errors with different causes, and telling them apart cuts your debugging in half. Refused means a machine answered you and actively rejected the connection - the host is up and reachable, and nothing is listening on port 22 (or something sent a reset). Timed out means nothing answered at all - a firewall is silently dropping your packets, or the host is down, or you have the wrong address. If you are editing security-group rules because of a refused error, you are almost certainly fixing the wrong thing.

Table of contents

• What refused actually tells you
• Cause 1: sshd is not running
• Cause 2: sshd is listening on a different port
• Cause 3: a firewall that rejects rather than drops
• Cause 4: you are not connecting to the machine you think you are
• The order to check things in
• How this fits the rest of the stack
• FAQ

What refused actually tells you

When you connect to a TCP port with nothing listening on it, the operating system replies with a RST packet - an active rejection. Your SSH client reports that as Connection refused.

For that reply to reach you, three things must already be true:

1. You have the right IP address - some machine is there.
2. The host is up and its network stack is running.
3. Nothing blocked you on the way in. A firewall configured to DROP would have caused a timeout, not a refusal.

So refused is genuinely good news. It rules out most of the network. The problem is on the host, at the port, and it is almost always that sshd is not running or is listening somewhere other than where you looked.

Compare with Connection timed out: nothing came back. That points at a firewall dropping packets silently (cloud security group, iptables -j DROP, a network ACL), a host that is genuinely down, or an IP address that belongs to nothing.

One error sends you to the host. The other sends you to the network. Do not mix them up.

Cause 1: sshd is not running

The most common cause, and the first thing to check if you have any other way onto the box - a cloud console, a serial connection, a hypervisor session.

systemctl status ssh      # Debian, Ubuntu
systemctl status sshd     # RHEL, Rocky, Alma, Fedora

If it is inactive or failed, start it and find out why it stopped:

sudo systemctl start ssh
sudo systemctl enable ssh      # survive the next reboot
sudo journalctl -u ssh -n 50

The most instructive version of this failure: sshd refuses to start because of a syntax error in sshd_config that somebody introduced on the last edit. The service was fine until it was restarted - possibly weeks later, by a reboot - and then it did not come back, and now nobody can get in.

The lesson, learned expensively by many: after editing sshd_config, validate it before restarting, and keep your existing session open until you have confirmed a new one works.

sudo sshd -t      # test the config; silence means it is valid

On a fresh cloud image - some minimal Debian and Ubuntu server images especially - sshd may simply not be installed. sudo apt install openssh-server.

Cause 2: sshd is listening on a different port

Plenty of teams move SSH off 22, and then somebody tries to connect on 22 and gets refused - correctly, because nothing is there.

Check what is actually listening:

sudo ss -tulpn | grep ssh

tcp   LISTEN 0  128   0.0.0.0:2222   0.0.0.0:*   users:(("sshd",pid=812,fd=3))

There it is on 2222. Connect accordingly:

ssh -p 2222 user@host

And then stop typing that forever by putting it in ~/.ssh/config:

Host myserver
  HostName 203.0.113.10
  User deploy
  Port 2222

The related trap is the listen address. If sshd_config has ListenAddress 127.0.0.1, sshd is bound to loopback only - it works perfectly from on the machine and refuses every connection from outside. ss shows this clearly: 127.0.0.1:22 rather than 0.0.0.0:22.

Note that moving SSH to a non-standard port is not meaningfully a security measure - a port scan finds it in seconds. It does cut down log noise from automated bots hammering 22, which is a legitimate but modest benefit.

Cause 3: a firewall that rejects rather than drops

Firewalls have two ways to say no, and they produce different errors.

DROP - discard the packet silently. The client waits, and eventually gives up: connection timed out.

REJECT - send back an explicit rejection. The client gets it immediately: connection refused.

Cloud security groups (AWS, Azure, DigitalOcean) almost always DROP, which is why a missing security-group rule shows up as a timeout. A host firewall configured with REJECT - ufw reject, or an iptables rule with -j REJECT - produces a refused.

So if you are getting refused and sshd is definitely running on port 22, check the local firewall:

sudo ufw status
sudo iptables -L -n --line-numbers | grep 22

Also check fail2ban. If you have been fat-fingering your password, fail2ban may have banned your IP - and depending on its banaction, that ban can appear as a refusal.

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.55

Being banned by your own intrusion-prevention system is a rite of passage.

Cause 4: you are not connecting to the machine you think you are

The embarrassing category, and worth ruling out early because it is free.

Stale DNS. The hostname points at an old IP - one that belongs to somebody else’s server now, which does not run SSH. dig +short myserver.example.com and compare it to what the box actually has.

A load balancer or proxy in front. You are hitting a load balancer that forwards ports 80 and 443 and knows nothing about 22. It refuses, correctly.

The wrong host entirely. A copied ~/.ssh/config entry, an IP from the wrong environment, a container instead of the host.

Prove reachability independently of SSH:

ping -c 3 203.0.113.10        # is the host there at all
nc -vz 203.0.113.10 22        # is port 22 open
nc -vz 203.0.113.10 2222      # what about the alternative

nc -vz is the cleanest test in this whole article: it tells you whether the port is open, without SSH’s own layers of key exchange and authentication confusing the picture. succeeded means the port is open and the problem is authentication. refused means nothing is listening. Timeout means something is dropping you.

The order to check things in

1. Read the error. Refused means the host answered - go look at the host. Timed out means it did not - go look at the network and the firewall rules.
2. nc -vz host 22. Confirm the port state without SSH in the way.
3. If you can reach the box another way - cloud console, serial - run systemctl status ssh and sudo ss -tulpn | grep ssh. Between them, those two commands identify the cause the large majority of the time.
4. Check the port and the listen address. Non-standard port, or bound to 127.0.0.1.
5. Check the local firewall and fail2ban. A REJECT rule or a self-inflicted ban.
6. Verify you have the right host. dig, and check it against reality.

The single most useful preventative habit, worth more than all of the above: after editing sshd_config, run sudo sshd -t before restarting, and keep your current session open until a second, new session connects successfully. Locking yourself out of a remote box because of a typo in a config file is a genuinely bad afternoon, and it is entirely avoidable.

How this fits the rest of the stack

Whatever you decide here, the cost of the decision only shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.

Useful related references:

• SSH Connection Refused: 7 Causes and the Right Fix
• SSH Port Numbers: The Default, the Risks, and the Safer Choices
• What Port is SSH: 22 (Default), How to Change, and Why
• Services on RunxBuild

FAQ

What does connection refused mean on SSH port 22?

A machine answered and actively rejected the connection - which means the host is up and reachable, and nothing is listening on port 22. It is different from a timeout, where nothing answers at all. Refused points at the host; timed out points at the network or firewall.

What is the difference between connection refused and connection timed out?

Refused means the host sent back a TCP reset - it is up, you reached it, and no service is on that port. Timed out means your packets vanished, usually into a firewall configured to drop silently, or the host is down, or the address is wrong. Cloud security groups drop, so a missing rule produces a timeout.

How do I check if sshd is running?

systemctl status ssh on Debian and Ubuntu, or systemctl status sshd on RHEL-family systems. Then sudo ss -tulpn | grep ssh to see which port and address it is actually bound to - a common cause is sshd listening on a non-standard port or only on 127.0.0.1.

Can a firewall cause connection refused rather than timeout?

Yes, if it is configured to REJECT rather than DROP. A REJECT sends an explicit rejection which the client reports as refused. Cloud security groups almost always DROP, which is why they cause timeouts, but a local ufw or iptables REJECT rule causes a refusal.

How do I avoid locking myself out when editing sshd_config?

Run sudo sshd -t to validate the config before restarting - silence means it is valid - and keep your existing SSH session open until you have confirmed a brand new session connects. A syntax error means sshd will not start, and if that is discovered at reboot time nobody can get in.