I have a problem with network setup, and my poor networking knowledge or my local linux community can't help me.

I have server A (right near my PC), which is hidden behind a NAT-router, and server B, which is VPS with static IP.

I want to use my server A as network server, accessible from everywhere in the Internet (and, thereafter, as own small web-hosting). I have realized how I can access server A through server B through SSH from internet - reverse SSH tunelling. But this thing has two defects:

  • it passes only ONE port (I want all of them, for example, to simultaneously maintain web-, ssh- and some more servers)
  • I can't access server A right from web - I must connect to server B, then do ssh -p 22222 username@localhost

Is there any solution to pass all ports to existing tunnel? All things that I found in Internet are about OR making reverse tunnel OR passing ports to direct tunnel, but not about passing to existing reverse tunnel.

2 Answers 2


maybe you already know this 'two additional notes about reverse ssh tunnels', but if you missed it:

  1. reverse ssh tunnel single command can include many (not just one) port forward
  2. reverse ssh tunnel can listen on local or public IP too (not only on localhost of B)

To achieve (1) you just need to add multiple -R parameters, for (2) you must put GatewayPorts clientspecified inside /etc/ssh/sshd_config of server B and restart sshd service. Usually we also want listening ports below 1024 of server B which is only allowed to root so PermitRootLogin yes should also be inside that sshd_config file.

full ssh command running on server A can look like this:

ssh -R serverBpublicIP:2222:serverAlocalIP:22 \
    -R   serverBpublicIP:80:serverAlocalIP:80 \
    -R serverBpublicIP:5901:serverAlocalIP:5901 \
    -R serverBpublicIP:8080:serverAlocalIP:8080 root@serverBpublicIP
#     new listening B side | already listening local A side

and it will forward 4 ports to public IP of server B. When this command is checked and confirmed to works well, you can add daemon -fNT params and autostart it with systemd.

if forward fails, be sure that new ports are free:

serverB$ netstat -anpt | grep '2222\|80\|5901\|8080'

so if you need finite number of TCP ports (and not using some specific sip-phone or rtp application with udp port-range demands), reverse tunneling should be enough for most situations.

  • This looks like what I need, but when I add those two options in sshd_config and restart sshd, it stops accepting any incoming connections include tunnels. Maybe need to add "userspecified" ports in config?
    – J. Doe
    Commented Dec 27, 2017 at 17:14
  • @J.Doe my mistake, clientspecified, (not userspecified)... just a word (means client ssh-user will specify on which interface will server listen) Commented Dec 27, 2017 at 23:07
  • Now it refuses to forward port 22 to local 2222 (and vice versa), but do it without "gatewayports clientspecified". Just print "remote forward failure" on tunnel creation, but forwards port 80 without any questions.
    – J. Doe
    Commented Dec 28, 2017 at 9:36
  • @J.Doe hm, yes 22 and 2222 should be switched, because serverB already listen on ssh (22) port, if 80 works well, then any other should work too, if it is free (no app listen on it on public-B side) Commented Dec 29, 2017 at 21:03
  • It's all my errors, noit works without any problem. Thanks.
    – J. Doe
    Commented Dec 30, 2017 at 11:01

Check sshuttle project.

According to documentation it solves the following common case:

  • Your client machine (or router) is Linux, FreeBSD, or MacOS.
  • You have access to a remote network via ssh.
  • You don't necessarily have admin access on the remote network.
  • The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
  • You don't want to create an ssh port forward for every single host/port on the remote network.
  • You hate openssh's port forwarding because it's randomly slow and/or stupid.
  • You can't use openssh's PermitTunnel feature because it's disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance (see below).
  • I tried sshuttle. It was so slow for some reason.
    – nurettin
    Commented Jul 12, 2019 at 8:29

You must log in to answer this question.

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