Ssh – What does “bind_address” mean in SSH port forwarding

It looks like you should be using local port-forwarding instead of remote port-forwarding. You may want to refer to the following helpful blog post by Dirk Loss:

• SSH port forwarding visualized

It includes the following illustrative diagram:

In order to read the diagram you need to know that it describes the relationships between 4 different roles involved in creating and utilizing an SSH tunnel:

• an ssh client (i.e. ssh - the OpenSSH command-line client) used to establish the tunnel;
• an ssh server (i.e. sshd - the OpenSSH server daemon) used to maintain the other end of the tunnel;
• an application server (e.g. another ssh server or an http server);
• an application client (e.g. another ssh client or a web-browser) which wants to access the application server via the tunnel.

It's also important to understand that the two different types of forwarding correspond to two different use cases:

• Local Forwarding: where the application client connects via the ssh client

• Remote Forwarding: where the application client connects via the ssh server

Remote forwarding is so called because the forwarding is performed remotely (at the ssh server) rather than locally (at the ssh client). I also find "remote forwarding = reverse forwarding" to be a useful mnemonic.

So as you can see, in order to initiate a connection from an ssh client at the origin host through an sshd server on a proxy jumphost to a third target host you would have to use local port-forwarding. Remote port-forwarding is for the case in which you want the entry point to the tunnel to be located at the host running the sshd server rather than at the host running the ssh client.

In the man page the local port-forwarding syntax is written as follows:

ssh -L [bind_address:]port:host:hostport user@remote

This can be written more intuitively as the following:

ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host

Or, using your naming conventions:

ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host

If we modify your command to use local port-forwarding instead then we end up with the following:

user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost

First, with your kind of setting, what would work, requiring anyway two ssh:

Host foo
    LocalForward 10022:bar:22

Host bar
    Hostname localhost
    Port 10022
    LocalForward 33389 rdp:3389

term1$ ssh foo # or use ssh -f -N -o ExitOnForwardFailure=yes foo for background task
term2$ ssh bar

What you'd really need wouldn't be RemoteCommand but ProxyJump, really simplifying your configuration, with goal reached only with:

ssh -L 33389:rdp:3389 -J foo bar

Or the equivalent (only) configuration:

Host bar
    ProxyJump foo
    LocalForward 33389 rdp:3389

With zero intermediate port needed.

Unfortunately ProxyJump is available only starting from openssh 7.3

But it's easily replaced with the ProxyCommand/-W combo you were using before.

ssh -L 33389:rdp:3389 -o 'ProxyCommand=ssh foo -W %h:%p' bar 

or as configuration file:

Host bar
    ProxyCommand ssh -W %h:%p foo
    LocalForward 33389 rdp:3389

There are still two ssh running: the hidden one is the one as ProxyCommand parameter still running on the local host doing the link using a pair of pipes with the main ssh, instead of an extra tcp port. Trying to involve the intermediate host in participating with the port forwarding is insecure or can clash (other users of foo can access the tunnel or use the same port), and prone to errors. Tunnel ends should always be kept on the client host if possible, where there's full control. Intermediate tunnels should either not exist or point to the next ssh entry point (that's the -W 's usage here).