Skip to main content
DevOps Insightsguides & answers

OpenSSH · troubleshooting

ssh: connect to host port 22: Connection timed out

Your packets left, but nothing came back: no answer, not even a refusal. Usually a firewall or cloud security rule silently drops them, the address is wrong or private, or the server is off or has no route back to you.

Reproduced on OpenSSH 9.6p1, . 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 · 10 sections

Before you start

  • The address and port you used, and if you can, a way to check the server's firewall or cloud network settings.

Run this first

step 1 of 2
ssh -v -o ConnectTimeout=5 HOST 2>&1 | grep -E 'Connecting to|connect to address'

Look for An address you did not expect, or timed out on the right one

Shows the exact address and port tried, and fails in 5 seconds instead of two minutes.

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

Does nc -vz -w 5 github.com 22 succeed from the same network?

Cause space

4 of 4 still possible

  • A firewall or cloud security rule drops the packetsCommon
  • The address is wrong, private, or out of dateCommon
  • The server is off, or its network has no route back to youOccasional
  • Your own network blocks outgoing port 22Occasional

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

Check it with a tool

Or diagnose it manually

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

  1. Step 1

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

    Shows the exact address and port tried, and fails in 5 seconds instead of two minutes.

    Look for An address you did not expect, or timed out on the right one

  2. Step 2

    nc -vz -w 5 HOST 22

    Tests the port without ssh, so keys and settings are out of the picture.

    Look for timed out (dropped on the way), refused (reached, nothing listening), or succeeded

Every cause, and how to fix it

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

A firewall or cloud security rule drops the packets

Common

Cloud security groups and most firewalls drop traffic they do not allow, with no reply. The rule may allow an old address of yours: many home and office networks change their public address.

Confirm

curl -s https://checkip.amazonaws.com

Your current public address, to compare with the addresses the firewall or security group allows on port 22

Fix

  • Allow TCP port 22 from your current address (or your network's range) in the server's firewall or cloud security rule.

The address is wrong, private, or out of date

Common

A private address (10.x, 172.16-31.x, 192.168.x) cannot be reached from outside its network. A cloud server that was stopped and started may also have a new public address.

Confirm

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

The address ssh will actually use: a private range, or not the server's current public address

Fix

  • Use the server's current public address, or connect from inside its network (a VPN or a bastion host).
  • For a server whose address changes, use a fixed address or a DNS name that is kept up to date.

The server is off, or its network has no route back to you

Occasional

The server is stopped, or its network cannot send replies out: in a cloud network, a subnet with no route to an internet gateway.

Confirm

ping -c 3 HOST

Replies prove the host is up (no replies proves nothing, because many networks block ping)

Fix

  • Start the server, or fix its network's outbound route, then try again.

Your own network blocks outgoing port 22

Occasional

Some company, hotel and public networks block outgoing SSH, so the packets never leave.

Confirm

nc -vz -w 5 github.com 22

A timeout to a host that certainly accepts SSH means your network is the problem

Fix

  • Try another network, or use a VPN. For GitHub, its documentation describes using SSH over the HTTPS port (ssh.github.com, port 443).

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

When you connect, your machine sends a hello packet and waits. A refusal is an answer; a timeout means silence, so your machine kept retrying until it gave up. Silence almost always means something on the path threw the packets away without saying so, which is exactly what most firewalls are set to do.

Words used on this page

Drop vs reject
A firewall that drops a packet says nothing, so you wait and time out. One that rejects replies at once, which you see as Connection refused.
SYN
The first packet of a TCP connection. A timeout means no reply to it ever arrived.
ConnectTimeout
An ssh option that sets how many seconds to wait before giving up, instead of the operating system's default.
What is actually happening

Reproduced on 22 October 2026 by connecting to 192.0.2.1, an address reserved for documentation that never answers. OpenSSH 9.6p1 on Ubuntu 24.04 printed "ssh: connect to host 192.0.2.1 port 22: Connection timed out" and exited 255, after 133 seconds. On macOS, OpenSSH 10.3p1 printed the same line ending in "Operation timed out", after 75 seconds. The two wordings are the same error: each operating system names it differently.

Those waits are the operating system's, not ssh's. On Linux, tcp(7) says the default of 6 retries of the first packet means about 127 seconds. ssh_config(5) says ConnectTimeout replaces that default: with -o ConnectTimeout=4, the same command gave up after 4 seconds. Setting it makes scripts and CI jobs fail fast instead of hanging for two minutes.

Compare Connection refused, where something answered no straight away: that page covers the other half. On AWS, the EC2 guide lists the security group, route table and public IP checks for an instance.

How to tell this is your problem
WhereWhat you see
ssh on Linuxssh: connect to host HOST port 22: Connection timed out
ssh on macOSssh: connect to host HOST port 22: Operation timed out
Timingssh sits silently for a minute or two before printing the error

How to know it is actually fixed

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

Stopping it happening again

  • Set ConnectTimeout in ~/.ssh/config or in CI so a dropped connection fails in seconds, not minutes.
  • Keep a record of which addresses your firewall allows, and update it when your network's address changes.

Security considerations

  • Do not open port 22 to 0.0.0.0/0 to make the timeout go away. Allow your own address, and remove the rule when you no longer need it.

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