SSH times out on port 22 while the host still serves HTTPS

Agent diagnostic brief

Exact symptom

ssh: connect to host <host> port 22: Operation timed out

Where it has been observed

Linux VPS behind a cloud-provider firewall allowlist; operator laptop on changing networks; OpenSSH client connecting on port 22.

Likely distinct causes

The client's public egress IP changed and is no longer allowlisted.
The host or its SSH daemon is down: unlikely when ports 80 and 443 still respond.
The local network blocks outbound port 22: test port 22 against an unrelated host.
An identity or key problem: that produces 'Permission denied (publickey)', not a timeout.

How to distinguish them

Probe ports 80 and 443 on the same host.
Test outbound port 22 against an unrelated public host.
Measure the egress IP with two independent services and resample it.
For 'Permission denied (publickey)', check which identity is offered (explicit identity file, IdentitiesOnly).

Current approaches

Compare the current egress IP with the firewall allowlist (solution-ssh-timeout-egress-allowlist, revision 1).

Known obsolete approaches

Treating a single successful connection as proof that the allowlist is stable.

Versions and freshness

Observed 2026-09-07..08; OpenSSH manual rechecked 2026-09-11
Editorial and primary-source review date: 2026-09-11.

What remains unknown

How often a given network rotates its egress address.
Independent reproduction by a different operator has not been established.

Deeper evidence

Problem

SSH times out on port 22 while the host still serves HTTPS

Observed symptom

SSH to a production host times out on port 22 while the same host keeps serving HTTP and HTTPS, because a provider firewall admits SSH only from an allowlisted client IP and the operator machine's public egress IP changed.
This historical observation is same-operator evidence and does not establish prevalence.

Operator goal

Reach a production host over SSH for a maintenance window.

Current understanding

A provider firewall that admits SSH only from allowlisted client addresses silently drops packets from a new egress IP, which appears as a connect timeout rather than an authentication error.
OpenSSH reports authentication results only after a TCP connection is established; ConnectTimeout bounds the wait.

Known limitations

Same-operator evidence from one host and one firewall type.
Networks with rotating egress addresses may need a stable path (VPN or bastion) chosen by the operator.

Known negative results

Trust one successful connection right after a network change. Result: Timeouts resumed because the egress IP moved again. Why it misleads: Resample the egress IP and verify with several fresh connections.
Treat 'Permission denied (publickey)' as the same problem. Result: That separate failure came from invoking ssh without the pinned identity, so default identities were offered. Why it misleads: A publickey denial is an authentication result after connecting; a port-22 timeout never reaches authentication.
No same-operator execution in this release counts as an independent reproduction.

Primary and recurrence sources

OpenSSH ssh_config manual
Primary · Primary documentation · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
Current primary material reviewed for claude-historical-corpus-1: OpenSSH ssh_config manual.

Rights and provenance

Origin

Based on a real operator execution; identifying project details removed.

Rights

State: allowed_to_summarize
Review basis: Owner-authorized factual synthesis of the operator's own Claude-assisted execution, independently written from reviewed current primary sources; no transcript expression is published.

Editorial review date

2026-09-11

Known approaches

solution · Revision 1

Compare the current egress IP with the firewall allowlist

Production corpus importer · 2026-09-11T20:00:00.000Z
Operator Knowledge for Agents editorial · Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned

## Candidate action - Compare the current egress IP with the firewall allowlist. Separate transport from authentication: if 80/443 work but 22 times out, compare the current egress IP (two independent services, resampled) with the allowlist and have the firewall owner update it; then verify with several fresh connections. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix. ## Applicability - Use when the observed signature is: ssh: connect to host <host> port 22: Operation timed out. - Observed scope: Linux VPS behind a cloud-provider firewall allowlist; operator laptop on changing networks; OpenSSH client connecting on port 22. - Stop if the first failing stage or product boundary differs. ## Procedure - Record the measured egress IP from two services over several samples. - Ask the firewall owner to update the allowlist; do not change firewall rules without authorization. - Verify with several fresh connections that do not reuse an existing one. - Measure again before resuming work if the network may rotate its address. ## Limitations - Same-operator evidence from one host and one firewall type. - Networks with rotating egress addresses may need a stable path (VPN or bastion) chosen by the operator. ## Obsolete approaches - Treating a single successful connection as proof that the allowlist is stable. ## Negative results - Trust one successful connection right after a network change. Result: Timeouts resumed because the egress IP moved again. Why it misleads: Resample the egress IP and verify with several fresh connections. - Treat 'Permission denied (publickey)' as the same problem. Result: That separate failure came from invoking ssh without the pinned identity, so default identities were offered. Why it misleads: A publickey denial is an authentication result after connecting; a port-22 timeout never reaches authentication. - No external or same-operator report was promoted to independent reproduction credit. ## Evidence boundary - Grounded in current primary source records src-openssh-ssh-config-current. - Grade A same-operator observation (2026-08-18..2026-09-08): After the firewall allowlist was updated to the freshly measured egress IP, five of five new SSH connections succeeded while HTTP/HTTPS had stayed up throughout. - Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes. ## What remains unknown - How often a given network rotates its egress address. - Whether the approach works outside the stated environment remains unknown.

Candidate id

claude-ssh-timeout-egress-allowlist

Historical period

2026-08-18..2026-09-08

Historical date

2026-09-08

Verification grade

Operator relationship

same_operator

Independent reproduction

false

History source

same-operator Claude agent session history

Provenance disclosure

Based on a real operator execution; identifying project details removed.

Applicability

State

partial

Text

Applies when the failed stage matches: ssh: connect to host <host> port 22: Operation timed out.

Facts

Component: provider firewall allowlist
Operation: open an SSH session to a production host
Protocol: SSH over TCP port 22

Pack

Candidate action: Compare the current egress IP with the firewall allowlist. Separate transport from authentication: if 80/443 work but 22 times out, compare the current egress IP (two independent services, resampled) with the allowlist and have the firewall owner update it; then verify with several fresh connections. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix.
Applicability: Use when the observed signature is: ssh: connect to host <host> port 22: Operation timed out.
Observed scope: Linux VPS behind a cloud-provider firewall allowlist; operator laptop on changing networks; OpenSSH client connecting on port 22.
Stop if the first failing stage or product boundary differs.
Steps: Record the measured egress IP from two services over several samples.
Ask the firewall owner to update the allowlist; do not change firewall rules without authorization.
Verify with several fresh connections that do not reuse an existing one.
Measure again before resuming work if the network may rotate its address.
Limitations: Same-operator evidence from one host and one firewall type.
Networks with rotating egress addresses may need a stable path (VPN or bastion) chosen by the operator.
Obsolete approaches: Treating a single successful connection as proof that the allowlist is stable.
Negative results: Trust one successful connection right after a network change. Result: Timeouts resumed because the egress IP moved again. Why it misleads: Resample the egress IP and verify with several fresh connections.
Treat 'Permission denied (publickey)' as the same problem. Result: That separate failure came from invoking ssh without the pinned identity, so default identities were offered. Why it misleads: A publickey denial is an authentication result after connecting; a port-22 timeout never reaches authentication.
No external or same-operator report was promoted to independent reproduction credit.
Evidence boundary: Grounded in current primary source records src-openssh-ssh-config-current.
Grade A same-operator observation (2026-08-18..2026-09-08): After the firewall allowlist was updated to the freshly measured egress IP, five of five new SSH connections succeeded while HTTP/HTTPS had stayed up throughout.
Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes.
What remains unknown: How often a given network rotates its egress address.
Whether the approach works outside the stated environment remains unknown.

Rights

State: allowed_to_summarize
Review basis: Original diagnostic procedure synthesized from owner-authorized execution facts and linked current primary sources; no private source code, logs, or transcript expression is published.

Source ids

src-openssh-ssh-config-current

Editorial review date

2026-09-11

Seo metadata

Meta title: Compare the current egress IP with the firewall allowlist | Knowledge for Agents
Meta description: Candidate procedure for ssh times out on port 22 while the host still serves https: applicability, steps, current sources, limitations, negative results, and unknowns.

Historical execution

Disclosure: Based on a real operator execution; identifying project details removed.
Operator relationship: same_operator
Independent reproduction: false

Problem id

problem-ssh-timeout-egress-allowlist

Page 1 · 1 children total

Sources and related records

No source relations recorded.