In my last article I gave you an overview on SSH port forwarding, types of SSH port forwarding and an example for SSH local port forwarding. Now since we know we also have OpenSSH Remote Port Forwarding so let me give you one example to help you understand more on the OpenSSH Remote Port Forwarding.
Up until now we have reviewed the –L Local port forwarding within SSH. In this section we'll discuss the –R Remote port forwarding feature within OpenSSH. Let us review that the –L Local port forwarding is a listening port on the client and initiated by the client waiting for the connection to be tunnelled out to the server. The –R Remote port forwarding is just the opposite—the tunnel is initiated from the server-host back to the client and the listening port lives on the client that is forwarded back to the server.
Remote port forwarding is less common and can be used to connect to a local port that cannot be reached from the internet, to a port on the server that is available on the internet,
By passing firewalls with OpenSSH Remote Port Forwarding Tunnel
In OpenSSH the –R [bind_address:]port:host:hostport] command specifies that a given port on the remote (server) host is to be forwarded to the given host and port on the local side. For example: command ssh –R 4444:localhost:23 username@host will forward all server traffic coming into port 4444 to port 23 on the client.
Assuming the security department does not allow you to connect to your corporate location (node1) from your home (node2) as it will be blocked by the corporate firewall. SSH port forwarding to the rescue! As long as you are allowed to SSH out from your corporate server to your home server, you have the ability to tunnel and connect back to your node1 from home!
Our first step is to initiate SSH connection from our node1 to our node2 and chose the right options to tunnel back to the node1 from our node2 over SSH. In this command we are using the –R Remote forwarding command initiated from our node1: ssh -R 7777:node1:22 root@node2 which will open up a 7777 TCP port on our node2 and forward all connections to it back to our node1 on port 22(ssh).
[root@node1 ~]# ssh -v -fN -R 7777:node1:22 root@node2 debug1: Remote connections from LOCALHOST:7777 forwarded to local address node1:22
–v option for verbose debug mode.SSH version 2 introduced the “-N” option which prevents execution of commands on the remote host. This option is useful if you just want to forward ports and not execute any commands on the remote host after you create your SSH tunnel.
We now have an SSH tunnel created between our node1 and node2 and all that is left for us to do is to go home to our node2 and connect back to our node1, which would normally be blocked by corporate firewall. Let's get on our node2 and verify this. Use netstat command to verify that port 7777 is still up and listening for a connection coming only from our local loopback IP address.
Most firewalls will close down sessions that are idle too long for security measures. If it takes you a long time to get home from work your session between your node1 and node2 could idle out and close. To bypass this and keep your session active simply ping on the other side of the tunnel.
[root@node2 ~]# netstat -ntlp | grep 7777
tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN 4972/sshd: root
tcp6 0 0 :::7777 :::* LISTEN 4972/sshd: root
[root@node1 ~]# ps aux | grep ssh
root 4360 0.0 0.1 154548 5520 ? Ss 11:08 0:00 sshd: root@pts/0
root 4944 0.0 0.1 154548 5516 ? Ss 11:57 0:00 sshd: root@pts/1
root 5497 0.0 0.1 112756 4316 ? Ss 12:20 0:00 /usr/sbin/sshd -D
root 5516 0.0 0.0 178544 1464 ? Ss 12:20 0:00 ssh -v -fN -R 7777:node1:22 root@node2
root 5517 2.0 0.1 154548 5536 ? Ss 12:21 0:00 sshd: root@pts/2
root 5556 0.0 0.0 112708 976 pts/0 R+ 12:21 0:00 grep --color=auto ssh
Below command shows us our node2 initiating a connection back to node1 on port 7777. And we are in! We have successfully SSH back to our work machine from home.
[root@node2 ~]# ssh -p 7777 root@localhost root@localhost's password: Last login: Tue Apr 9 12:19:43 2019 from 10.0.2.30 [root@node1 ~]#
A verbose message is printed on node1 related to the connection which was established using port forwarding.
-v) option.[root@node1 ~]# debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768 debug1: client_request_forwarded_tcpip: listen localhost port 7777, originator ::1 port 41226 debug1: connect_next: host node1 ([10.0.2.30]:22) in progress, fd=4 debug1: channel 0: new [::1] debug1: confirm forwarded-tcpip debug1: channel 0: connected to node1 port 22
SSH port forwarding using firewalld
You can also do a port forwarding using firewall rules but this is not exactly same as what we have achieved above but if the idea is to use an alternate port to connect to a node then firewalld can also be used.
As you can see currently I don't have any active rules in my firewalld zone.
[root@node2 ~]# firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: ssh dhcpv6-client ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Let me add a port forwarding rule wherein any connection on port 2233 will be routed to port 22 on node2 incoming connection.
[root@node2 ~]# firewall-cmd --add-forward-port=port=2233:proto=tcp:toport=22 success
Now verify the new rule
[root@node2 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: ssh dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports: port=2233:proto=tcp:toport=22:toaddr=
source-ports:
icmp-blocks:
rich rules:
Let us try to connect to node2 from any other node using the new port what we have configured for port forwarding.
[root@node1 ~]# ssh -p 2233 root@node2 root@node2's password: Last login: Tue Apr 9 12:26:39 2019 from 10.0.2.30 [root@node2 ~]# logout Connection to node2 closed.
And looks like our port forwarding is working as expected.
Lastly I hope the steps from the article to configure remote port forwarding on Linux using firewalld and openssh was helpful. So, let me know your suggestions and feedback using the comment section.
