How to fix channel 2: open failed: connect failed: Connection timed out in SSH

First confirm that the basic SSH connection to the remote server succeeds:

ssh -v user@remote-host.com

If this fails, you have an SSH authentication or reachability issue with the SSH server itself, not a channel issue. Fix basic SSH connectivity before proceeding. If this works, the SSH session is fine and the problem is the onward connection to your forwarding destination, so continue to the next step.

SSH into the remote server and try connecting to the destination host the same way the tunnel would. This is the single most useful test, because the destination is resolved and connected from the remote server, not from your local machine:

ssh user@remote-host.com
# Now you are on the remote server
nc -zv destination-host 8080
# or
curl -v http://destination-host:8080/

If this times out or is refused from the remote server, the tunnel will fail in exactly the same way. Check, in order:
- The destination service is actually running and listening (ss -tlnp | grep 8080 on the destination)
- The destination host/port is correct
- The remote server has a route to the destination
- No firewall (on the remote server or the destination) is blocking the path

In ssh -L local_port:host:dest_port, the host:dest_port is resolved and connected from the remote SSH server, not from your laptop. A common cause of this timeout is pointing at an address the remote server cannot reach.

If the service runs on the SSH server itself and listens on loopback, use 127.0.0.1:

ssh -L 8080:127.0.0.1:8080 user@remote-host.com

If the service listens on a specific interface or another internal host reachable from the remote server, use that address instead:

ssh -L 8080:192.168.1.10:8080 user@remote-host.com

Verify what the service is bound to (loopback vs a specific IP vs 0.0.0.0) with ss -tlnp on the machine running it, and match the forwarding target to that.

If forwarding is disabled server-side, channels will fail. SSH into the server and check /etc/ssh/sshd_config:

grep -i AllowTcpForwarding /etc/ssh/sshd_config

The default (when unset) is yes. If it is explicitly set to no, enable it:

sudo nano /etc/ssh/sshd_config
# Find or add:
AllowTcpForwarding yes

Validate the config and restart SSH:

sudo sshd -t
sudo systemctl restart sshd

The connection that times out is an outbound connection made by sshd on the remote server to your destination. If the remote server has an egress firewall, that outbound traffic may be dropped silently (a drop, not a reject, is what produces a timeout rather than an immediate refusal). On the remote server, allow the outbound connection to the destination port.

For iptables (allow outbound to the destination port; add the matching inbound ESTABLISHED rule if your OUTPUT policy is restrictive):

# Inspect current rules
sudo iptables -L OUTPUT -n --line-numbers

# Allow outbound connections to the destination port (example: 8080)
sudo iptables -A OUTPUT -p tcp --dport 8080 -j ACCEPT

For ufw, this is an outbound (egress) allow rule:

sudo ufw allow out to any port 8080 proto tcp

firewalld does not filter outbound traffic in its default zones, so a normal --add-port (which opens *inbound* traffic) will not help here. If you have an explicitly restrictive egress policy, add a direct/rich rule allowing the outbound connection instead, for example:

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 \
  -p tcp --dport 8080 -j ACCEPT
sudo firewall-cmd --reload

Do not use firewall-cmd --add-forward-port for this: that sets up NAT/port redirection on the firewall host and does not authorize sshd's outbound connection to the destination, so it will not resolve this error.

Also remember the firewall on the destination host must accept the inbound connection from the remote server.

If the destination resolves to an IPv6 address but only IPv4 connectivity works (or vice versa), the connect can hang and time out. Force the destination address family by specifying the literal address.

For an explicit IPv4 destination:

ssh -L 8080:192.168.1.10:8080 user@remote-host.com

For an explicit IPv6 destination, wrap it in square brackets:

ssh -L 8080:[::1]:8080 user@remote-host.com

You can also influence which family SSH uses to reach the remote server with -4 or -6, but the destination timeout itself is decided by what host resolves to on the remote server.

Add verbose flags to see the detailed channel and connection attempts:

ssh -vvv -L 8080:localhost:8080 user@remote-host.com

Look for lines such as:
- Requesting port forward... / Local forwarding listening... (the local listener is set up)
- channel N: connecting to <host> port <dest_port> (the remote-to-destination attempt begins)
- connect failed: Connection timed out (the onward connection is what failed)

Seeing the failure only after the connecting to line confirms the problem is the remote server reaching the destination, which points you back to steps 2 and 5.

If many forwarded connections fail at once, the SSH server may be limiting concurrent sessions or new connections. Check the server's sshd_config:

grep -iE 'MaxSessions|MaxStartups' /etc/ssh/sshd_config

If MaxSessions is very low (for example 1), raise it:

MaxSessions 10

Then validate and restart:

sudo sshd -t
sudo systemctl restart sshd

Note: limits typically surface as open failed: administratively prohibited or connection drops rather than a timeout, so treat this as a secondary check once network reachability (steps 2 and 5) is confirmed.