9

I'm running ssh -N -f -R127.0.2.3:23000:127.1.2.3:23000 user@remote , and I expect the tunnel on remote has opened on 127.0.2.3:23000, but it only opens on 127.0.0.1:23000, and it's inconvenient because I need to open several tunnels on remote, but listen to the same tcp port.

In the local machine, the tunnel points to the right ip address (127.1.2.3:23000).

I have tried creating several loopback devices on remote, to no avail.

The same is for Linux and Freebsd servers (openbsd-ssh)

So, why is ssh -R not binding to loopback ip's on remote other than 127.0.0.1?

Thank you.

(sorry for bad redacting :)

2 Answers 2

15

While the local optional bind address is at the control of SSH's client side (specified with -L/LocalForward or altered with -g/GatewayPorts in the client's configuration), the remote optional bind address specified by the client with -R/RemoteForward is at the control of SSH's server side with the server configuration GatewayPorts. By default it's no. It should be set to clientspecified to allow the client to choose which address to bind to:

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be no to force remote port forwardings to be available to the local host only, yes to force remote port forwardings to bind to the wildcard address, or clientspecified to allow the client to select the address to which the forwarding is bound. The default is no.

Moreover, the client's RemoteForward entry tells likewise:

[...]
If the bind_address is not specified, the default is to only bind to loopback addresses. If the bind_address is ‘*’ or an empty string, then the forwarding is requested to listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).

So you must be able to change the ssh's server configuration on the server (usually with root access), and add (or edit) this entry in the sshd_config file, so it shows:

GatewayPorts clientspecified

If you can't, you could use other available tools if present (or locally installable) on the server side to overcome this (quite weak) security limitation. For example socat, or ssh itself by using a LocalForward from the server to itself (even if it's uselessly adding a layer of encryption).

3
  • It works!, though I looked at this option before, but as it talked about "non loopback addresses" I just didn't try it out. I wonder if there should be an option to let you choose among loopback addresses only. Regards,
    – Auxorro
    Dec 30, 2019 at 18:09
  • I admit the way it's written leads to think any loopback address should work, but reality tells otherwise. The check is there for example: salsa.debian.org/ssh-team/openssh/blob/buster/channels.c#L3285 . One could say it's plural: ipv4 and ipv6.
    – A.B
    Dec 30, 2019 at 18:42
  • Usually, this file is /etc/ssh/sshd_config Dec 19, 2022 at 14:01
1

It turns out you can achieve it without changing GatewayPorts on remote server. The trick is to create another ssh connection on the remote server to forward

  • On client side, same as your code
ssh -N -f -R127.0.2.3:23000:127.1.2.3:23000 user@remote
  • On remote side, in addition to existing listening port 23000, create a new connection from remote
# Should be on your remote node
ssh -g -L 23001:localhost:23000 user@remote_ip
                 Remote         
--------         |-------------------------------------------------
|client|-------->| Port 23000 ----    // (127.0.0.1:23000  LISTEN)
--------         |                |
                 | Port 23001 <---    // (0.0.0.0:23001    LISTEN)
                 |--------------------------------------------------

Reference: Kudo to @FaST4 : https://askubuntu.com/a/789275/523440

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .