Skip to main content
DevOps Insightsguides & answers

OpenSSH · troubleshooting

ssh: connect to host port 22: Connection refused

Your machine reached the server, and something there answered that nothing accepts connections on that port. Usually sshd is not running, you are using the wrong port, or a firewall rejects the connection.

Reproduced on OpenSSH 10.3p1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The exact command, and if you can, another way into the server: a console from your provider, or another account.

Run this first

step 1 of 2
nc -vz HOST 22

Look for Connection refused, or succeeded

Tests the port without ssh: refused here means the problem is the port, not keys or ssh settings.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

On the server (via a console), does sudo ss -tlnp show sshd or systemd listening?

Cause space

5 of 5 still possible

  • sshd is not running, or not installedCommon
  • You are connecting to the wrong portCommon
  • Port changed on Ubuntu 24.04, but the socket still listens on the old oneOccasional
  • A firewall or security policy rejects the connectionOccasional
  • In a container or VM, the port is not published or forwardedOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    nc -vz HOST 22

    Tests the port without ssh: refused here means the problem is the port, not keys or ssh settings.

    Look for Connection refused, or succeeded

  2. Step 2

    ssh -v HOST 2>&1 | grep -E 'Connecting to|connect to address'

    Shows the exact address and port ssh tried.

    Look for An address or port you did not expect

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

sshd is not running, or not installed

Common

The server rebooted without starting SSH, the service crashed, or a minimal image never had an SSH server.

Confirm

sudo ss -tlnp | grep -E ':22\b'

On the server: no line means nothing listens on port 22

Fix

  • Start it: on Debian and Ubuntu the unit is ssh (sudo systemctl enable --now ssh); on Red Hat-family systems it is sshd.
  • If no SSH server is installed, install your distribution's openssh-server package.

You are connecting to the wrong port

Common

The server runs SSH on another port, or your ~/.ssh/config sets a Port for this host that is out of date.

Confirm

ssh -G HOST | grep -E '^(hostname|port) '

The port ssh will actually use, to compare with the port the server listens on

Fix

  • Use the right port with ssh -p PORT HOST, or correct the Port line for that Host in ~/.ssh/config.

Port changed on Ubuntu 24.04, but the socket still listens on the old one

Occasional

With socket activation, systemd owns the listening socket. A new Port in sshd_config is picked up by a generator only after daemon-reload, and the socket must be restarted. Documented by Ubuntu; not reproduced here.

Confirm

systemctl is-active ssh.socket; sudo ss -tlnp | grep -E 'ssh|systemd'

ssh.socket active and listening on a port other than the one in sshd_config

Fix

  • Apply the new port: sudo systemctl daemon-reload, then sudo systemctl restart ssh.socket. Keep your current session open until a new connection on the new port works.

A firewall or security policy rejects the connection

Occasional

A host firewall set to reject, rather than drop, answers with a refusal even though sshd is running. (A firewall that drops packets gives a timeout instead.)

Confirm

sudo ss -tlnp | grep -E ':22\b'

sshd is listening on the server, yet connections from outside are refused

Fix

  • Allow your address on port 22 in the host firewall, then try again.

In a container or VM, the port is not published or forwarded

Occasional

sshd listens inside the container or VM, but nothing maps the host's port to it, so the host has nothing listening.

Confirm

nc -vz HOST PORT

Refused on the host's port while sshd runs inside

Fix

  • Publish or forward the port (for a container, the port mapping when it starts), then connect to the host's port.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

A refused connection is a fast, definite no: the server's network stack replied that no program is listening on that port. That is different from a timeout, where nothing replies at all. So the address is probably right, and the question is what is, or is not, listening on the other end.

Words used on this page

sshd
The SSH server program. If it is not running, or listens on another port, connections are refused.
Refused vs timed out
Refused means something replied no. Timed out means nothing replied, usually because a firewall dropped the packets silently.
Socket activation
On Ubuntu 22.10 and later, systemd listens on the SSH port itself (ssh.socket) and starts sshd when a connection arrives.
What is actually happening

Reproduced on OpenSSH 10.3p1 by connecting to a port with nothing listening: "ssh: connect to host 127.0.0.1 port 22998: Connection refused", exit code 255. ssh -v showed the same at the line "connect to address 127.0.0.1 port 22998", and nc -vz to the port was refused too, which shows the problem is the port, not ssh.

On this site's Ubuntu 24.04 server, SSH is socket-activated: ssh.socket listens on port 22 for IPv4 and IPv6 and starts sshd for each connection. Ubuntu's announcement of the change says that from 24.04 the port and address settings in sshd_config are read by a systemd generator, which runs again on systemctl daemon-reload. So after changing Port, a reload and a restart of ssh.socket are what apply it; restarting only ssh.service may leave the old port listening. That was not reproduced here.

How to tell this is your problem
WhereWhat you see
sshssh: connect to host HOST port 22: Connection refused
ssh -vdebug1: connect to address IP port 22: Connection refused

How to know it is actually fixed

  • nc -vz HOST 22 succeeds, and ssh reaches the login step.

Stopping it happening again

  • Keep a provider console or second way in before changing SSH ports or firewall rules.
  • After changing the port, test a new connection before closing your current session.

Security considerations

  • Do not open port 22 to the whole internet just to test this; allow your own address, then narrow it again.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next