SSH Tunnel That Listens To Non Loopback (Non Localhost) IP

In order for ssh tunnel to listen to non localhost interface, we have to enable "GatewayPorts" in /etc/ssh/sshd_config

1. Open /etc/ssh/sshd_config using your preferred text editor. I use vi

$ sudo vi /etc/ssh/sshd_config

2. Turn on "GatewayPorts" by adding below into /etc/ssh/sshd_config

GatewayPorts yes

3. Save and exit the text editor

4. Restart ssh

$ sudo systemctl restart ssh

5. Now we can create a local/remote tunnel, and the tunnel can be made to listen to non loopback (non localhost). For example, we can forward a port from another machine, and make it to listen to all ipv4 address in our local machine

$ ssh -R 0.0.0.0:1111:localhost:22

6. We can verify it by using ss command

$ sudo ss -tulpn | grep 1111

...

tcp   LISTEN 0      128                             0.0.0.0:1111        0.0.0.0:*                   users:(("sshd",pid=xxxxx,fd=10))

Forward local connection to a remote server that is accessible to public using ssh

When we use standard ssh remote forwarding, the listening ip address on the remote side will always be 127.0.0.1 or localhost, and cannot be accessed using the remote machine's IP address. If you have no idea what this is about, please refer to this guide on how to create a reverse ssh tunnel.

In order to make the remote port accessible from any ip address available in the remote machine, we can use an option, -g. This option will allow remote host to connect to local forwarded port, and in turn, make our forwarded port available on the non loopback network interfaces.

Just use this command to achieve that:

$ ssh -R 18080:localhost:8080 myremotemachine -t 'ssh -g -L 8080:localhost:18080'

The meaning of the options are:

"ssh -R 18080:localhost:8080 myremotemachine" means that, local port 8080 will be forwarded to remote host's (myremotemachine) port 18080

"-t" means, force pseudo-terminal allocation, to allow running a command on a remote ssh session

"ssh -g -L 8080:localhost:18080" means that, the local port 18080 will be available on port 8080 locally, on all interfaces.

To verify, just run ss command. You will see that port 18080 is available only for localhost, and port 8080 is available for all interfaces (0.0.0.0).

$ ss -tulpn | grep 8080 

tcp    LISTEN   0        128               0.0.0.0:8080           0.0.0.0:*      users:(("ssh",pid=20656,fd=4))                                                 

tcp    LISTEN   0        128             127.0.0.1:18080          0.0.0.0:*                                                                                     

tcp    LISTEN   0        128                  [::]:8080              [::]:*      users:(("ssh",pid=20656,fd=5))                                                 

tcp    LISTEN   0        128                 [::1]:18080             [::]:*                                                                                     

Now you are able to use port 8080 on the remote machine, and you will be tunneled to port 8080 on local machine via ssh.

SSH tunnelling to bind on all interfaces

Most of the time, we would not need this, since tunneling to a localhost is all we need to achieve our objective. Until one day, I have the requirement to actually tunnel my "behind the firewall" port to a public IP of a remote server. And here is how I do it.

Actually you can specify which IP you want the tunnel to be set up to. Let's say we want to set up a local tunnel on port 2222 of the address 10.20.30.40, connected to localhost port 22 at the remote server.

$ ssh -L 10.20.30.40:2222:localhost:22 user@remote.server.ip.address

If we want the tunnel to listen to all IPV4, we can do like below

$ ssh -L 0.0.0.0:2222:localhost:22 user@remote.server.ip.address

If we want just IPV6, we can do as below

$ ssh -L "[::]:2222:localhost:22" user@remote.server.ip.address

If we want the tunnel to listen on all interfaces, we can do like below

$ ssh -L \*:2222:localhost:22 user@remote.server.ip.address

That's all, happy tunnelling :)

Using socks proxy to tunnel apt command in ubuntu 18.04

This is useful when we have a machine (m1) that does not have an internet connection to do apt update/upgrade, but we have another machine (m2) that is able to access internet, and accessible via ssh from the m1.

Create a dynamic tunnel (socks5 proxy) from m1 to m2, using port 8888
$ ssh myuser@m2 -fN -D 8888

Set apt to use the socks proxy created above
$ echo "Acquire::http::proxy "socks5h://localhost:8888";"  | sudo tee -a /etc/apt/apt.conf.d/12proxy

Run apt command as usual in m1, and your apt command will be tunneled via the socks5h proxy
$ sudo apt update
...
0% [Connecting to SOCKS5h proxy (socks5h://localhost:8888)] [Connecting to SOCKS5h proxy (socks5h://localhost:8888)]

...

Once you are done, do not forget to kill the tunnel

$ kill `pidof ssh`

and remove the proxy option from apt
$ sudo sed -i 's/Acquire/#Acquire/' /etc/apt/apt.conf.d/12proxy 

Create a persistent reverse tunnel for a server behind firewall

To do this, you need to have a middleman server (middleman) to act as intermediaries between your workstation and the server behind firewall (target). The best is to have your middleman server running ssh server on the usual port that firewall allows, for example 80 and 443.

Step 1: In the target server, create a passwordless ssh access to your middleman server. Please refer here on how to accomplish that

Step 2: Create a simple bash script in target server that will check for the reverse tunnel connection, and restart the tunnel if the tunnel is broken. Lets say in this case, my middleman ssh server is running on port 443, you want to create a reverse tunnel on port 2222 on middleman server, and you want to use a user called foo in the middleman server. Don't forget to make the script executable by the owner.

$ cat /home/foo/bin/tunnelcheck.sh

#!/bin/bash

SERVER=middleman

SPORT=443

PORT=2222

USER=foo

ssh $USER@$SERVER -p $SPORT -t nc -vz localhost $PORT > /dev/null 2>&1

if [ $? -ne 0 ];

  then ssh -R $PORT:localhost:22 -l $USER -fN $SERVER -p $SPORT

fi

$ chmod u+x /home/foo/bin/tunnelcheck.sh


Step 3: Set a crontab to run the above script every 10 minutes (or whatever interval you think is appropriate)
$ crontab -e
*/10 * * * * /home/foo/bin/tunnelcheck.sh


Step 4: Test the persistency by killing the ssh tunnel, and wait for crontab to run the tunnelcheck.sh script, and restart the tunnel

Step 5: You are now able to access the target server, simply by ssh'ng into port 2222 on middleman server
$ ssh foo@middleman -p 2222

Connecting to your machine using vnc

To setup and use vncserver in redhat flavored distro, please follow below steps:

1. Install the package:

   $ sudo yum install tigervnc-server tigervnc

2. Set a password for a user that you want to use to login to the vnc server:

   $ vncpasswd

3. Start the vncserver:

   $ vncserver

4. Check the display number of your newly created vnc session:
   

   $ vncserver -list
   TigerVNC server sessions:
   X DISPLAY #     PROCESS ID
   :1              9168

5. Check the port that your vnc session is using:

   $ sudo netstat -tulpn | grep 9168
   tcp        0      0 0.0.0.0:5901                0.0.0.0:*                   LISTEN      9168/Xvnc
   tcp        0      0 0.0.0.0:6001                0.0.0.0:*                   LISTEN      9168/Xvnc
   tcp        0      0 :::6001                     :::*                        LISTEN      9168/Xvnc

6. Test your vncserver locally (only if you are using GUI, else test it from the other machine with vncviewer installed), using vncviewer (belongs to tigervnc package):
   

   $ vncviewer :1

To connect from a redhat flavored linux distro client:

1. Install the tigervnc package:
   

   $ sudo yum install tigervnc

2. Run the vncviewer: vncviewer :

   $ vncviewer 192.168.0.2:1
   

3. If you are behind firewall, you need to open port 5901 for the client to get through.
4. If firewall is not in your control, you can always use ssh to port forward port 5901 to 5901 in your localhost, by: 

$ ssh -L 5901:localhost:5901 vncserver.ip.address

and in other terminal, run

$ vncviewer localhost:1

Once you are done, you can kill the server by running:

$ vncserver -kill :1

ssh through socks proxy

This technique is very useful if you have a firewall between you and your destination, and somehow the only way you could get in to the destination is by ssh'ing into a jumpbox and ssh again to the destination. In this scenario example, I'll call the machine we initiate this technique as A.local, the jumpbox as B.local and the destination server as C.local, and we will use a user called aladdin.

A.local -> B.local (jumpbox) -> C.local

To do this, please follow below steps:

Add below settings to your ssh config in A.local, the file is usually ~/.ssh/config

Host B.local 

DynamicForward localhost:1080 

Host C.local 

ProxyCommand /usr/bin/nc -x localhost:1080 %h %p

Initiate a socks proxy connection, and leave it open (-D is for dunamic application-level port forwarding and 1080 can be any port of your choice, 1080 is socks proxy default port for nc):

[A.local]$ ssh -D 1080 aladdin@B.local

Open another terminal, and run ssh as if you have direct connection to C.local

[A.local]$ ssh aladdin@C.local

Voila, your ssh session will go through as if you have direct connection to C.local.


If you just doesn't want to put it into your config, you can use it on the fly by using below command after you have initiate the socks proxy:

[A.local]$ ssh -o "ProxyCommand /usr/bin/nc -x localhost:1080 %h %p" aladdin@C.local

Or you can also put it as alias for easy usage:

[A.local]$ alias 

alias proxyssh='ssh -o "ProxyCommand /usr/bin/nc -x localhost:1080 %h %p"'

ssh forward tunnel

To make this happen, the command is like below:

$ ssh -L 10022:target.local:22 middle.local

where:
-L is for forward tunnel, 10022 is the port at localhost that we want to use, target.local is our target, 22 is the target's port that we want to forward and middle.local is our middleman server.

What the above command do is forwarding port 22 of target.local to port 10022 of localhost by using middle.local as a middleman. Once done, you can access port 22 of target.local just by SSHing into port 10022 in your localhost like below:

$ ssh localhost -p10022

and voila, you will be directed to target.local instead. This technique is useful when you have firewall blocking some ports, and you have server behind the firewall than can access those ports witth openssh installed.