0

I have setup a reverse ssh tunnel using the following command between a Linux laptop and a remote server:

ssh -4nNT -R 2222:localhost:22 somehost.com

That is, the laptop, which is behind a firewall, can be accessed over ssh using the following command:

ssh -p 2222 -l joe somehost.com

on sshd_config of somehost.com, i have enabled Gatewayports=yes.

I am glad to say all these work fine. However, one thing beats me: there is an iptables running on somehost.com that does NOT have the port 2222 opened. In spite of this tunnel works, how is that possible? How does remote ssh tunnel work behind the scenes? could anyone kindly explain?

here is the output of iptables -L:

  target     prot opt source               destination

  ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable
  ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded
  ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
  ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
  DROP       tcp  -f  anywhere             anywhere
  DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
  DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
  DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN/FIN,SYN
  DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,ACK/FIN
  DROP       tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN,RST
  DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
  DROP       udp  --  anywhere             anywhere             udp spt:bootps dpt:bootpc
  DROP       tcp  --  anywhere             anywhere             tcp dpt:kazaa
  DROP       udp  --  anywhere             anywhere             udp dpt:kazaa
  LOG        tcp  --  anywhere             somehost.com  tcp dpt:ssh state NEW LOG level warning tcp-options ip-options prefix "firewall-> ssh1: "
  ACCEPT     tcp  --  anywhere             somehost.com  tcp dpt:ssh
  LOG        tcp  --  anywhere             somehost.com  tcp dpt:2023 state NEW LOG level warning tcp-options ip-options prefix "firewall-> Check: "
  ACCEPT     tcp  --  anywhere             somehost.com  tcp dpt:2023
  LOG        tcp  --  anywhere             somehost.com  tcp dpt:http state NEW LOG level warning tcp-options ip-options prefix "firewall-> HTTP: "
  ACCEPT     tcp  --  anywhere             somehost.com  tcp dpt:http
  LOG        tcp  --  anywhere             somehost.com  tcp dpt:https state NEW LOG level warning tcp-options ip-options prefix "firewall-> HTTPS: "
  ACCEPT     tcp  --  anywhere             somehost.com  tcp dpt:https

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination
  ACCEPT     tcp  --  anywhere             anywhere             tcp spt:http

1 Answer 1

0

On somehost.com there runs an ssh daemon called sshd. Your call of ssh with -R 2222:localhost:22 tells sshd on somehost.com that it should tunnel the traffic which is send to port 2222 to your laptop behind the firewall through port 22. Because you set Gatewayports=yes, sshd sends all traffic form other hosts which is send to port 2222 to your laptop through the tunnel on port 22.

For further reading I refer to https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work.

3
  • thank you, marli! i did read the page you have suggested. i also found a couple of more links that might be of interest: 1. vimeo.com/54505525 and 2. blog.trackets.com/2014/05/17/…. but, one thing that is not clear is the interplay between Gateway ports and the IPTABLES.
    – Tagsense
    Commented Jan 29, 2017 at 4:34
  • As I said above you need only the ssh port 22 and that is open via the ACCEPT in the table above for incoming requests. Outgoing connections are not blocked from your iptables.
    – marli
    Commented Jan 29, 2017 at 11:47
  • Please, instead of thanking me accept my answer if you are satisfied.
    – marli
    Commented Jan 29, 2017 at 11:48

You must log in to answer this question.

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