I'm configuring a server that sits behind a reverse proxy, in which an SSH tunnel is configured to the server due to firewall restrictions.

The reverse proxy is managed by someone else and I would like to control the tunnel from the server side by enabling reverse SSH tunnel.

I did some research and it seems very simple as enabling Gatewayports=yes on the sshd configuration of the reverse proxy.

I see that by default this option is set to false, which is probably for a good reason.

Is there any critical vulnerabilities or any other issue that I should consider before enabling reverse SSH tunnel on the reverse proxy?

  • I'm not entirely clear on the configuration here - if your server can only be accessed via the reverse proxy, then what's the point of enabling GatewayPorts on the server? Let's say you RemoteForwarded your system's 8080 to the server's 9090 on every address. Who's going to be able to access that 9090 port?
    – muru
    Commented Apr 5, 2018 at 4:17
  • Maybe I was not very clear. My idea is to enable GatewayPorts on the reverse proxy, so that I can control the tunnel from the application server by creating reverse tunnels. Right now I have on the reverse proxy an autossh session to keep the tunnel alive to the server. I want to enable the gatewayports on the reverse proxy, so that I can keep the autossh session running from the server, that is easier for me to manage. But my question is more generic. I would like to know what would be the disadvantage of using a reverse tunnel in this scenario. For example, am I compromising the security?
    – Pedreiro
    Commented Apr 5, 2018 at 4:24
  • Ah yes, that makes sense. In that case, I'd think that as long as whatever's on the listening end of the tunnel is properly secured, it should be safe. GatewayPorts defaulting to false is a safe default because it's safer to assume that whatever you're forwarding might not be secured and thus unsafe to expose to the wider network, not because of any vulnerabilities in SSH itself.
    – muru
    Commented Apr 5, 2018 at 4:27

1 Answer 1


SSH defaults to binding on localhost only for forwarding because SSH is merely the messenger in forwarding: it does not add additional checks on what it forwards. Thus, if service being forwarded does not perform its own authorization checks or rate-limiting, etc., it might be hacked or DoSed if connections are allowed from everybody on the same network as the forwarding point (which might even be the entire internet!). Thus, only enable GatewayPorts and binding to externally visible interfaces if the forwarded service itself is sufficiently secured (which it should be in your case, since you're already exposing it).

As a cautionary tale, some years ago, while playing around with VMs, I had SSH itself forwarded from a VM to my host laptop bound to all interfaces. The VM got pwned whilst on public WiFi because of the weak, throwaway passwords I was using then. (I wisened up and (a) stopped binding to all interfaces, and (b) learned the wisdom of disallowing password-based login.)

  • That is in line with what I was thinking. The vulnerability would be the same since it is already exposed. Thanks for sharing your experience.
    – Pedreiro
    Commented Apr 5, 2018 at 5:05

You must log in to answer this question.

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