SSH port forwarding not working

The Tryssh team · July 22, 2026

ssh tunnel port forwarding not working becomes manageable when the investigation identifies the last successful SSH boundary before changing configuration.

TL;DR: SSH authenticates, but the local, remote, or dynamic forwarding endpoint cannot carry the expected application traffic. Confirm the effective target and platform layer first. Name the tunnel direction and both endpoints, prove the target from the SSH host, select an unused local port, and check server forwarding policy.

Audience: developers, founders, homelab users, and on-call operators with basic command-line familiarity. Read every command, replace example names, and keep a recovery path before changing access.

SSH diagnostic boundaries from client to platform policy

What ssh tunnel port forwarding not working means

SSH authenticates, but the local, remote, or dynamic forwarding endpoint cannot carry the expected application traffic.

SSH crosses name resolution, TCP transport, protocol negotiation, host verification, user authentication, channel creation, and the remote program. Record the last stage that succeeded and the first line that contradicts the expected path.

Read-only diagnostic path

Run these from the same account and network that sees the problem:

ssh -vvv -N -L 8080:127.0.0.1:80 example-host; lsof -nP -iTCP:8080 -sTCP:LISTEN; curl -v http://127.0.0.1:8080/; ssh example-host 'ss -lntp'

Record the UTC time, target, exit status, and first decisive line. Do not paste private keys, passphrases, tokens, complete environment dumps, or unredacted authentication logs into a shared transcript.

Interpret the evidence

Local bind failure means the chosen client port is occupied or disallowed.
A successful tunnel can still target the wrong address from the server's point of view.
Administrators can restrict forwarding with AllowTcpForwarding or PermitOpen.
Testing the target on the remote host separates application reachability from tunnel transport.
If two observations conflict, trust effective runtime state and the narrow timestamped log over a remembered configuration file.

If two observations conflict, effective configuration and timestamped runtime evidence outrank a remembered file. A successful client-side check does not prove that a server, identity provider, cloud firewall, or second SSH hop agrees.

Choose the platform boundary

Linux distributions, macOS, Windows, WSL, cloud VMs, containers, CI runners, VS Code, Tailscale, NAS appliances, and bastions expose different authorities and recovery routes. Use the SSH platform diagnostics guide for the relevant environment instead of applying every platform command to one host.

Decision tree

Confirm the target. Expand the SSH configuration and verify the hostname, address, port, and user. A correct command aimed at the wrong machine is still dangerous.
Locate the failure stage. Use verbose client output once. Stop at the first decisive error rather than interpreting every debug line as a problem.
Compare with server evidence. If you have console or an existing session, read a tight log window around one reproduction attempt.
State one hypothesis. Name the observation that would disprove it. This prevents a plausible story from becoming an untested conclusion.
Choose the smallest reversible repair. Name the tunnel direction and both endpoints, prove the target from the SSH host, select an unused local port, and check server forwarding policy.
Verify from a second session. Keep the recovery path open and repeat the original user action, not merely a local status check.

Repair and rollback

Before any change, save the current effective setting or file metadata, write down the rollback, and keep an existing SSH or provider-console session open. Validate sshd configuration with the platform-supported test command before reload. Prefer reload over restart when the service and change allow it.

The key caution for this failure is: Do not bind a sensitive forwarded service to every local interface unless other machines must reach it. Use an independent recovery path when the network path is unavailable. A repair is complete only when a new connection works from the user's original network and the old access path is intentionally closed.

Do not bundle cleanup into recovery. Rotating every key, upgrading the host, rewriting the firewall, and changing DNS at once creates four new explanations. Restore the narrow capability, confirm it, then schedule hardening as a separate reviewed change.

Investigate it in Tryssh

Tryssh › example-host › Terminal ⌘K

OverviewTerminalFilesActivity example-host

$ ssh -G example-host | sed -n '1,24p'
Capture the first decisive result, timestamp, and exit status.

Tryssh keeps the host, diagnostic conversation, and bounded SSH evidence together.

Tryssh separates the copilot's SSH execution channel from the visible terminal. Read-only commands must pass a default-deny risk gate; state-changing commands remain explicit human approvals. That helps organize evidence, but it does not make Tryssh the incident owner or remove the need for independent recovery.

Common operator questions

Can Tryssh fix this automatically?

Tryssh can gather and explain safe evidence, but it should not silently change authentication, firewall, routing, or service state. It proposes consequential commands for review so the person responsible for the host keeps control of blast radius.

Should I restart SSH first?

Usually not. A restart can erase useful state or lock out the only session. Capture effective configuration, service status, and a narrow log window first. If a reload or restart becomes necessary, keep a recovery session open and validate a second login before disconnecting.

What if I do not have console access?

Stop before changing access controls. Establish the provider console, physical access, another administrator, or a tested rollback path. Without one of those, even a correct change can turn a small SSH error into a full lockout.

Evidence and review status

This page consolidates twenty-five platform-targeted drafts into one canonical problem guide. Its commands and claims were checked against the linked upstream and platform sources. Only explicitly labeled reproduced output is presented as first-hand evidence; use the platform guide and current first-party documentation before executing a repair.

Limits and trade-offs

Managed services can replace local SSH files with IAM, metadata, policy, or generated configuration. Verbose output can expose users, hostnames, paths, fingerprints, and topology. A one-host success is evidence, not permission for a fleet rollout; use canaries, stop conditions, bounded concurrency, and independent rollback.

Related Tryssh guides

Continue with SFTP or SCP fails over SSH, SSH config file not applied, the SSH platform diagnostics guide, SSH config guide, and SSH hardening checklist.