Ssh – How to create SSH reverse tunnel with iptables forwarding

iptableslinuxsshssh-tunneling

I have a server in my home network (cannot port forward) and a VPS on the WAN. I need requests on a certain port, to, not from, the VPS to be forwarded to my home server. I have an SSH tunnel which works fine if I send the request to localhost on VPS. However I want requests forwarded to VPS's localhost from internet be sent to my home server through the tunnel. And it needs to be bi-directional.

I have seen this question, however it doesn't work for me. It is quite possible that I did something incorrectly.

My exact procedure:
On server a, my home server, I ran this command to set up the tunnel:

ssh -v -N -R 2222:localhost:22 root@server-b.com

I ran the following command on server b (VPS):

iptables -t nat -A PREROUTING -p tcp --dport 2223 -j DNAT --to-destination 127.0.0.1:2222

And tried to ssh from another machine:

ssh root@server-b.com -p 2223

I set GatewayPorts yes in sshd_config however I am still finding the same problem:
ssh: connect to host server-b.com port 2223: Connection refused.

Best Answer

Set GatewayPorts yes and AllowTcpForwarding yes in sshd_config on server b. With GatewayPorts clientspecified explicitly mention IP 0.0.0.0 or * on server a to create reverse tunnel. So that sshd on server b accepts connections from public too:

ssh -NTR *:2222:localhost:22 root@server-b.com

Otherwise sshd listens on loopback interface only as is the case with GatewayPorts no.

Now ssh from another machine to port 2222:

ssh root@server-b.com -p 2222

You'll be logged in to server a after authentication.
No need to set up iptables forwarding. Btw, avoid user root for remote logins, if possible.

If you don't want to set GatewayPorts option, then you need to forward traffic from some other port, say 2223, to localhost:2222.

This can be done with iptables on server b:

iptables -t nat -I PREROUTING -p tcp -m tcp --dport 2223 -j DNAT --to-destination 127.0.0.1:2222

^{* REDIRECT works only for same interface}

But routing to loopback interface isn't allowed unless:

echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/route_localnet

Now ssh from another machine to port 2223:

ssh root@server-b.com -p 2223

Another option is to setup some minimal local forwarding server from port 2223 to 2222 using tools like ssh, socat, netcat, *inetd etc.

On server b, with socat:

socat TCP-LISTEN:2223,fork TCP:127.0.0.1:2222

Or with netcat:
```
nc -l -p 2223 -c "nc 127.0.0.1 2222"
```

Or with ssh:

ssh -4gfNTL 2223:localhost:2222 localhost

Any of the above can be combined with reverse tunnel to do a double forwarding from server a in a single step:

ssh -TR *:2222:localhost:22 root@server-b.com "ssh -4gfNTL 2223:localhost:2222 localhost"

Related Solutions

Ssh – Remote SSH Tunnel not working with certificates

The -v option will gives you more information on the client side.

plink.exe -v -R *:62050:127.0.0.1:9000 user@host -i ./np.ppk
Looking up host "host"
Connecting to 135.x.x.x port 22
Server version: SSH-2.0-OpenSSH_5.1
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Release_0.63
...
Opened main channel
Requesting remote port *:62050 forward to 127.0.0.1:9000
Remote port forwarding from *:62050 enabled              <---<<<
Allocated pty (ospeed 38400bps, ispeed 38400bps)
Started a shell/command
...

If you didn't manage to find the answer with plink verbose mode. Open sshd in debug mode on another port (or ask the root administrator to do that).
No need to stop the regular sshd deamon.

# /usr/sbin/sshd -dd -p  2222
debug2: load_server_config: filename /opt/ssh/etc/sshd_config
debug2: load_server_config: done config len = 514
debug2: parse_server_config: config /opt/ssh/etc/sshd_config len 514
debug1: Config token is port
debug1: Config token is protocol
debug1: Config token is hostkey
debug1: Config token is hostkey
....

Then connect to that sshd instance with plink option -P

plink.exe -v -P 2222 -R *:62050:127.0.0.1:9000 user@host -i ./np.ppk

You will have the debug information of both end.

EDIT

The solution is in man sshd at the "AUTHORIZED_KEYS FILE FORMAT" chapter.

It is likely that the no-port-forwarding option has been associated to your key but that no global option has been set.

 no-port-forwarding
         Forbids TCP forwarding when this key is used for authentication.  Any port forward requests by the client will return
         an error.  This might be used, e.g. in connection with the command option.

You should have access to your home ~/.ssh/authorized_keys , edit the file and remove that option.

Sometimes the authorized_keys are centralized in a protected directory in that case you will not be able to change it.

Ssh – Linux iptables ssh port forwarding (martian rejection)

The issue with doing a DNAT to 127.0.0.1:5000 is that when the remote side responds, these packets return into the routing engine as if they were locally originated (from 127.0.0.1) but they have an outside destination address. SNAT/MASQUERADE matching the outside interface would have caught them and rewritten them, but the routing decisions that have to be made for the packets to arrive at that interface come first, and they disallow these packets which are bogus by default. The routing engine can't guarantee you'll remember to do that rewrite later.

The thing that you should be able to do instead is reject any outside connections to 192.168.1.1:5000 at iptables INPUT other than those coming from 192.168.1.10 using the ! argument before the -s source address specification. If you use TCP reset as the rejection mechanism (-j REJECT --reject-with tcp-reset, instead of the default ICMP destination unreachable), it will be largely identical to the situation where nothing was even listening on that address:port combination as far as the outside world is concerned.

Best Answer

Related Solutions

Ssh – Remote SSH Tunnel not working with certificates

EDIT

Ssh – Linux iptables ssh port forwarding (martian rejection)

Related Question