When establishing an SSH tunnel from an office machine to a home server, the following error occurs during the second hop connection:

ssh_exchange_identification: Connection closed by remote host
channel 3: open failed: connect failed: Connection timed out

The tunnel setup works fine for the first connection:

ssh -gL 12345:my.home.domain:22 my.home.domain

But fails when attempting to connect through the tunnel:

ssh -p 12345 127.0.0.1

1. Verify basic SSH connectivity:

telnet my.home.domain 22

Output shows expected SSH banner:

SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

2. Check tunnel connection:

telnet 127.0.0.1 12345

Shows connection but no SSH banner, indicating the tunnel isn't properly forwarding SSH traffic.

Running with -v flag reveals:

ssh -vp 24600 127.0.0.1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 24600.
debug1: Connection established.
ssh_exchange_identification: Connection closed by remote host

1. SSH Version Mismatch:

# Check versions on both ends
ssh -V

2. Firewall/IPTables Issues:

# Check iptables rules
sudo iptables -L -n -v

3. SSH Configuration Problems:

# Compare /etc/ssh/sshd_config settings
# Pay attention to:
# PermitRootLogin
# AllowTcpForwarding
# GatewayPorts

Try this more explicit forwarding syntax:

ssh -N -g -L 12345:localhost:22 user@my.home.domain

Then connect with:

ssh -p 12345 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null localhost

Check system logs on the server:

tail -f /var/log/auth.log

Or increase SSH debug level:

sudo /usr/sbin/sshd -d -p 22

Test with netcat if SSH is too complex:

# On server:
nc -l 2222
# Through tunnel:
nc localhost 12345

---

After switching from Ubuntu to Debian on my home machine, I encountered a peculiar SSH tunneling issue. The setup that previously worked perfectly now fails with:

ssh_exchange_identification: Connection closed by remote host
channel 3: open failed: connect failed: Connection timed out

My standard tunneling workflow was:

# First terminal (creates tunnel)
ssh -gL 12345:my.home.domain:22 my.home.domain

# Second terminal (uses tunnel)
ssh -p 12345 127.0.0.1

While the initial connection succeeds, the tunneled connection fails after the OS change.

Telnet tests reveal different behaviors:

# Direct connection (works)
$ telnet my.home.domain 22
Trying ...
Connected to .
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

# Tunneled connection (fails)
$ telnet 127.0.0.1 12345
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

Running with -v reveals more details:

$ ssh -vp 24600 127.0.0.1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 24600.
debug1: Connection established.
debug1: identity file /home/jacob/.ssh/id_rsa type -1
debug1: identity file /home/jacob/.ssh/id_rsa-cert type -1
debug1: identity file /home/jacob/.ssh/id_dsa type -1
debug1: identity file /home/jacob/.ssh/id_dsa-cert type -1
debug1: identity file /home/jacob/.ssh/id_ecdsa type -1
debug1: identity file /home/jacob/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

1. Check SSH Configuration

Verify /etc/ssh/sshd_config on the home machine:

# Important settings
AllowTcpForwarding yes
GatewayPorts yes
LoginGraceTime 120
PermitRootLogin no
MaxStartups 10:30:60

2. Test Without GatewayPorts

Try without -g flag:

ssh -L 12345:localhost:22 my.home.domain

3. Check Firewall Rules

Inspect iptables on both machines:

sudo iptables -L -n -v

4. Alternative Tunneling Method

Try reverse SSH tunneling:

# From home machine (initiates persistent connection)
autossh -M 20000 -N -R 2222:localhost:22 user@office.machine

Additional diagnostic tools:

# Check SSH daemon logs
journalctl -u ssh --no-pager -n 50

# Network connectivity test
nc -zv 127.0.0.1 12345

# Check process list
ps aux | grep ssh

Based on the symptoms, this appears to be either:

1. A MaxStartups limit being hit in the new Debian configuration
2. Firewall rules blocking forwarded connections
3. SSH version incompatibility between client and server

The most likely fix would be to adjust MaxStartups in sshd_config and restart the SSH service.