CODEWITHSUNDEEP
sshtelnetportforwarding
Alban
Alban

Reputation: 3215

Why the forwarded SSH port still seem open even with the endpoint failing?

I mount a SSH port forwarding tunnel to a remote server RemoteServerSSH and forward the 55555 port to a non-existing equipment (this is what I try to test).

$ hostname
MyMachine

Setting the forwarding tunnel

$ ssh -q -N -p 22 -vvv \
    -i ~/.ssh/MyKey \
    -o Compression=yes \
    -o ServerAliveInterval=3 \
    -o serverAliveCountMax=3 \
    -L *:55555:RemoteDownItem:9100 user@RemoteServerSSH

Testing the tunnel

When I telnet the device directly I got the correct behavior (not connected). However, when I try to reach it through the tunnel, telnet says it's connected:

$ telnet RemoteDownItem 9100   # Not Connected = OK
$ telnet MyMachine 55555       # Connected! Why? should be same as above

When I measure the telnet time connection, it is instantaneous (1ms!). It is the SSH client that answers me, it does not cross the ssh tunnel! Why ?

Verbose

...
debug1: Local connections to *:55555 forwarded to remote address 10.220.9.183:9100
debug3: channel_setup_fwd_listener: type 2 wildcard 1 addr NULL
debug1: Local forwarding listening on 0.0.0.0 port 55555.
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [port listener]
debug3: sock_set_v6only: set socket 5 IPV6_V6ONLY
debug1: Local forwarding listening on :: port 55555.
debug2: fd 5 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [port listener]
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug1: Requesting [email protected]
debug1: Entering interactive session.


debug1: Connection to port 55555 forwarding to 10.220.9.183 port 9100   requested.
debug2: fd 6 setting TCP_NODELAY
debug2: fd 6 setting    O_NONBLOCK debug3: fd 6 is O_NONBLOCK
debug1: channel 2: new    [direct-tcpip]

Question

Is there an SSH parameter to forward the telnet connection directly to the endpoint?

Project Related Question

Telnet connect to non-existing adress

Upvotes: 3

Views: 997

Answers (1)

Kenster
Kenster

Reputation: 25390

Consider how a tunnel works. When you run something like ssh -L *:55555:RemoteDownItem:9100 user@host, the port forward is handled like this:

  1. The local ssh instance binds to TCP port 55555 and listens for connections.
  2. An "originator" connects to port 55555 on the local system. The local ssh instance accepts the TCP connection.
  3. The local ssh instance sends a "direct-tcpip" request through the SSH connection to the remote ssh server.
  4. The remote ssh server attempts to connect to host "RemoteDownItem" port 9100.

At step 4, if the ssh server is able to connect to the target of the tunnel, then the ssh client and server will each relay data between the originator and the target through the direct-tcpip channel.

Alternately, at step 4, the server may not be able to make the TCP connection to the target. Or the server may be configured not to permit forward requests. In either case, it will respond to the client with an error (or a message saying the channel is closed).

At this point, the only thing that the local ssh instance can do is to close the TCP connection to the originator. From the perspective of the originator, it successfully connected to a "server" (the ssh client), and then the "server" almost immediately closed the connection.

The OpenSSH software doesn't contain any logic to handle this in a more sophisticated way. And handling it in a more sophisticated way may be difficult. Consider:

  • The remote SSH server has no idea whether it can connect to "RemoteDownItem" port 9100 until it tries. So it's problematic for ssh to figure out in advance that the port forward won't work.

  • Even if one attempt to connect to the target fails, the next attempt might succeed. So it's problematic for ssh to assume the port forward won't work, just because one attempt failed.

  • The remote SSH server could successfully connect to the target, and then the target could immediately close the TCP connection. So the ssh server, ssh client, and originator all have to handle this behavior anyway.

Upvotes: 1

Related Questions