What is reverse ssh tunneling (and how to use it)

As I understand this, firewalls (assuming default settings) deny all incoming traffic that has no prior corresponding outgoing traffic.

Based on Reversing an ssh connection and SSH Tunneling Made Easy, reverse SSH tunneling can be used to get around pesky firewall restrictions.

I would like to execute shell commands on a remote machine. The remote machine has its own firewall and is behind an additional firewall (router). It has an IP address like 192.168.1.126 (or something similar). I am not behind a firewall and I know the remote machine’s IP address as seen from the Internet (not the 192.168.1.126 address). Additionally, I can ask someone to execute ssh (something) as root on the remote machine first.

Could anyone explain me, step by step, how reverse SSH tunneling works to get around the firewalls (local and remote machines’ firewalls and the additional firewall between them)?

What is the role of the switches ( -R , -f , -L , -N )?

What is reverse ssh tunneling (and how to use it)

5 Answers 5

I love explaining this kind of thing through visualization. 🙂

Think of your SSH connections as tubes. Big tubes. Normally, you’ll reach through these tubes to run a shell on a remote computer. The shell runs in a virtual terminal (tty). But you know this part already.

Think of your tunnel as a tube within a tube. You still have the big SSH connection, but the -L or -R option lets you set up a smaller tube inside it.

Every tube has a beginning and an end. The big tube, your SSH connection, started with your SSH client and ends up at the SSH server you connected to. All the smaller tubes have the same endpoints, except that the role of “start” or “end” is determined by whether you used -L or -R (respectively) to create them.

(You haven’t said, but I’m going to assume that the “remote” machine you’ve mentioned, the one behind the firewall, can access the Internet using Network Address Translation (NAT). This is kind of important, so please correct this assumption if it is false.)

When you create a tunnel, you specify an address and port on which it will answer, and an address and port to which it will be delivered. The -L option tells the tunnel to answer on the local side of the tunnel (the host running your client). The -R option tells the tunnel to answer on the remote side (the SSH server).

What is reverse ssh tunneling (and how to use it)

So. To be able to SSH from the Internet into a machine behind a firewall, you need the machine in question to open an SSH connection to the outside world and include a -R tunnel whose “entry” point is the “remote” side of his connection.

Of the two models shown above, you want the one on the right.

From the firewalled host:

This tells your client to establish a tunnel with a -R emote entry point. Anything that attaches to port 22222 on the far end of the tunnel will actually reach “localhost port 22”, where “localhost” is from the perspective of the exit point of the tunnel (i.e. your ssh client).

The other options are:

  • -f tells ssh to background itself after it authenticates, so you don’t have to sit around running something on the remote server for the tunnel to remain alive.
  • -N says that you want an SSH connection, but you don’t actually want to run any remote commands. If all you’re creating is a tunnel, then including this option saves resources.
  • -T disables pseudo-tty allocation, which is appropriate because you’re not trying to create an interactive shell.

There will be a password challenge unless you have set up DSA or RSA keys for a passwordless login.

Note that it is STRONGLY recommended that you use a throw-away account (not your own login) that you set up for just this tunnel/customer/server.

Now, from your shell on yourpublichost, establish a connection to the firewalled host through the tunnel:

You’ll get a host key challenge, as you’ve probably never hit this host before. Then you’ll get a password challenge for the username account (unless you’ve set up keys for passwordless login).

If you’re going to be accessing this host on a regular basis, you can also simplify access by adding a few lines to your

Adjust remotehostname and remoteusername to suit. The remoteusername field must match your username on the remote server, but remotehostname can be any hostname that suits you, it doesn’t have to match anything resolvable.

SSH port forwarding is a mechanism in SSH for tunneling application ports from the client machine to the server machine, or vice versa. It can be used for adding encryption to legacy applications, going through firewalls, and some system administrators and IT professionals use it for opening backdoors into the internal network from their home machines. It can also be abused by hackers and malware to open access from the Internet to the internal network. See the SSH tunneling page for a broader overview.

Local Forwarding

Local forwarding is used to forward a port from the client machine to the server machine. Basically, the SSH client listens for connections on a configured port, and when it receives a connection, it tunnels the connection to an SSH server . The server connects to a configurated destination port, possibly on a different machine than the SSH server.

Typical uses for local port forwarding include:

Tunneling sessions and file transfers through jump servers

Connecting to a service on an internal network from the outside

Connecting to a remote file share over the Internet

Quite a few organizations for all incoming SSH access through a single jump server . The server may be a standard Linux/Unix box, usually with some extra hardening, intrusion detection, and/or logging, or it may be a commercial jump server solution.

Many jump servers allow incoming port forwarding, once the connection has been authenticated. Such port forwarding is convenient, because it allows tech-savvy users to use internal resources quite transparently. For example, they may forward a port on their local machine to the corporate intranet web server, to an internal mail server’s IMAP port, to a local file server’s 445 and 139 ports, to a printer, to a version control repository, or to almost any other system on the internal network. Frequently, the port is tunneled to an SSH port on an internal machine.

In OpenSSH , local port forwarding is configured using the -L option:

This example opens a connection to the gw.example.com jump server, and forwards any connection to port 80 on the local machine to port 80 on intra.example.com .

By default, anyone (even on different machines) can connect to the specified port on the SSH client machine. However, this can be restricted to programs on the same host by supplying a bind address:

The LocalForward option in the OpenSSH client configuration file can be used to configure forwarding without having to specify it on command line.

Remote Forwarding

In OpenSSH, remote SSH port forwardings are specified using the -R option. For example:

This allows anyone on the remote server to connect to TCP port 8080 on the remote server. The connection will then be tunneled back to the client host, and the client then makes a TCP connection to port 80 on localhost . Any other host name or IP address could be used instead of localhost to specify the host to connect to.

This particular example would be useful for giving someone on the outside access to an internal web server. Or exposing an internal web application to the public Internet. This could be done by an employee working from home, or by an attacker.

By default, OpenSSH only allows connecting to remote forwarded ports from the server host. However, the GatewayPorts option in the server configuration file sshd_config can be used to control this. The following alternatives are possible:

This prevents connecting to forwarded ports from outside the server computer.

This allows anyone to connect to the forwarded ports. If the server is on the public Internet, anyone on the Internet can connect to the port.

This means that the client can specify an IP address from which connections to the port are allowed. The syntax for this is:

In this example, only connections from the IP address 52.194.1.73 to port 8080 are allowed.

OpenSSH also allows the forwarded remote port to specified as 0. In this case, the server will dynamically allocate a port and report it to the client. When used with the -O forward option, the client will print the allocated port number to standard output.

Opening Backdoors into the Enterprise

Remote SSH port forwarding is commonly used by employees to open backdoors into the enterprise. For example, the employee may set get a free-tier server from Amazon AWS , and log in from the office to that server, specifying remote forwarding from a port on the server to some server or application on the internal enterprise network. Multiple remote forwards may be specified to open access to more than one application.

The employee would also set GatewayPorts yes on the server (most employees do not have fixed IP addresses at home, so they cannot restrict the IP address).

For example, the following command opens access to an internal Postgres database at port 5432 and an internal SSH port at port 2222.

Server-Side Configuration

The AllowTcpForwarding option in the OpenSSH server configuration file must be enabled on the server to allow port forwarding. By default, forwarding is allowed. Possible values for this option are yes or all to allow all TCP forwarding, no to prevent all TCP forwarding, local to allow local forwardings, and remote to allow remote forwardings.

Another option of interest is AllowStreamLocalForwarding , which can be used to forward Unix domain sockets. It allows the same values as AllowTcpForwarding . The default is yes .

The GatewayPorts configuration option as described above also affects remote port forwardings. Possible values were no (only local connections from server host allowed; default), yes (anyone on the Internet can connect to remote forwarded ports), and clientspecified (client can specify an IP address that can connect, anyone can if not specified).

How to Prevent SSH Port Forwarding from Circumventing Firewalls

We recommend that port forwarding be expressly disabled when not needed. Leaving port forwarding enabled can expose the organization to security risks and backdoors. For example, if a server intended to only provide SFTP file transfers allows port forwardings, those forwardings might be used to gain unintended access into the internal network from the Intranet.

The problem is that port forwarding can in practice only be prevented by a server or firewall. An enterprise cannot control all servers on the Internet. Firewall-based control can also be tricky, as most organizations have servers in Amazon AWS and other cloud services, and those servers are usually accessed using SSH.

Reverse SSH is a technique that can be used to access systems (that are behind a firewall) from the outside world.

As you already know SSH is a network protocol that supports cryptographic communication between network nodes. Using this protocol, you can do a secure remote login, secure copy from/to a remote machine etc.

You’ll typically do the following to connect to a remote server securely using ssh command.

What is Reverse SSH?

SSH is very good tool to access remote machine or server securely. But, the problem arises when you try to connect to a remote server which is behind a firewall and this firewall denies any incoming connection or data transfer request that has no prior outgoing request. This means that only those connections would be allowed which are initiated by the remote server machine. This is a real problem for those who want to access this server machine remotely.

Reverse SSH provides a technique through which you can simulate a normal SSH to this remote server machine.

The main problem is that firewall is rejecting ssh connection that your machine is trying to establish with remote server machine. But you know that the same firewall will not have any problem with the connections originating from server machine. So, why not ask some one who is sitting behind the firewall to do something with which you can achieve your goal of remotely accessing the server. To do this we have to use ssh -R option.

This is the description of the ssh -R option from the man page:

Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.

So you can use ssh command, with -R option, (from server in our case) to connect to your machine, allocate a port there and make sure that any connection request on that port is forwarded to ssh port of the remote server.

Instead of your machine doing an ssh, the server machine does an ssh and through port forwarding makes sure that you can ssh back to server machine.

How to Create a Reverse SSH Tunnel?

Here is the command your friend sitting on remote server side should run on the server :

So this ssh connection request originating from remote server to your machine will make sure that any ssh connection request for port 7000 on your machine is forwarded to port 22 of remote server.

Now do an ssh connection request from your machine to your own machine at port 7000:

Here, though it may seem like you are doing ssh on localhost but your request would be forwarded to remote host. So, you should use your account ‘username’ on remote server and when prompted for password, enter the corresponding password.

This should clear most of the aspects related to reverse ssh technique. But, there is one catch. The catch is that you have to ask a friend of yours — who is sitting behind the firewall — to create an ssh connection first. This is not feasible every time.

To overcome this problem, what you can do is that you can set up a machine which is out of firewall (just like yours) in a way that it is always on. Lets call this machine as machine_z.

The benefit of machine_z is that you can once do this reverse ssh set up on it and leave it like this. At any point of time, when you need to login to remote machine, you can ssh into machine_z on a specified port (as shown earlier) and your connection request will be forwarded to remote server machine and Voila, you will be running commands on remote server.

On a related note, you can also setup no password SSH to connect to another server without entering the password.

SSH is a secure connection between a client and server over which commands can be executed on the server. As long as the two devices can see each other on the internet the SSH connection can also be made from the server to the client. This is however often blocked by firewalls and NATs.

SSH also has the ability of forwarding ports over this secure connection, creating in essense a simple VPN. This can be used to dial another SSH connection from the server to the client via an existing SSH connection from the client to the server. This is called reverse SSH.

Setup your SSH server #

You will need a server or other computer running Linux or any other operating system which can be accessed via SSH. This server needs to be accesible via a public IP address on the internet. You should create a hostname to point to this server and use the hostname to ssh to the server. This will allow you to connect to the server even when the IP address changes.

For the next step you will need to know the hostname of this server. As an example let’s say the hostname is sshgateway.example.com . We will also need to know the username you use to log into this server. We’ll use serveruser as example.

Setup the gateway to dial SSH on startup #

Log into your gateway using either SSH or the Wirgrid.

Run the following commands:

After the last command you will see an output like this:

Copy the entire line starting with ssh-rsa and ending with [email protected]_080E0xxx . This is called the public key. Save this to a file as a backup. We will need this later. You might also want to make a backup of the

/.ssh/id_rsa file. You can use SCP to copy the file from the gateway: scp [email protected]:/root/.ssh/id_rsa .

On the gateway create a file called startSshTunnel.sh by running:

Press i and then paste the following code.

In two instances replace sshgateway.example.com by your hostname and replace in one instance serveruser by your server’s username.

Press the escape key on your keyboard, then type :w , press enter, then type :q and enter again. The file should be saved now.

Run the following command to allow this file to execute as a program.

]# chmod +x startSshTunnel.sh

Now add this file to the end of /etc/rcd/rc.local by doing the following.

Press i to start typing. Go down to the end and paste /root/startReverseSshTunnel.sh & . Press escape, then :w , enter, :q , enter.

/etc/rc.d/rc.local should look like this:

Disable the Kerlink firewall #

By default the firewall on the Kerlink blocks outgoing SSH connections. You can either add a rule to allow this, or you can disable the firewall. Edit /etc/sysconfig/network by using vi like before. Change FIREWALL=yes to FIREWALL=no .

Restart the network to apply the firewall change:

Copy your public key to the server #

Copy-paste the public key you saved earlier and add it to the

/.ssh/authorized_keys on the server.

Execute the following on the gateway

If you do not get a password prompt or an error, and you are logged into the server, your key exchange has been done correctly.

Reverse SSH into the gateway from your server #

Restart the gateway and wait two minutes. Log into your server and try to SSH into the gateway via the reverse SSH tunnel:

ssh [email protected] -p 20022

If everything has been done correctly you should be asked for the password and then logged into the gateway.

Hevo can connect to your database via a Reverse SSH Tunnel. Reverse SSH tunneling or remote port forwarding helps you connect to a remote (and private) network without needing a public gateway.

Contrary to how SSH works, where you establish a secure connection with a remote system and can receive and send data, in reverse SSH, the remote system connects with your local system. Then, using the established connection, you can set up a connection to the remote system and fetch the data from that system. As the original connection was formed from the remote system to your local system, it is called a reverse SSH.

Requesting a Reverse SSH Tunnel

To request a reverse SSH tunnel, contact Hevo either through the in-app support or by mailing us at [email protected] with the SSH public key you wish to connect with.

Once Hevo gets your request it creates an SSH user for your team and allocates a set of ports that you can use to tunnel the traffic. Hevo provides you the following details that you can use to set up the reverse SSH tunnel and configure your Source:

ssh_host: The hostname of the SSH instance.

ssh_user: The username you would be using to connect to the SSH instance. This applies to your entire team.

a set of remote_forward_ports: A list of ports that Hevo allocates to you for tunneling the traffic. You can use one port for each DB host you want to fetch the data from.

Connecting to the SSH Instance

To connect the reverse SSH host, do one of the following:

Run the following command:

Refer to the following table for the values of the variables.

If you prefer to connect using the SSH config, use the following option.

Provide the settings using the SSH configuration file:

Edit your SSH config file, normally found at the path,

Add the following reverse SSH settings to the file:

Run the following command with the values of the variables as defined in the SSH config file. Specify the port number to be assigned to the database from the list provided by Hevo.

If you are using an SSH process manager, such as autossh, use the command:

This sets up the reverse SSH tunnel.

Connecting the Database to Hevo

While connecting the database to Hevo, for the Database Host specify the , and for the Database Port, specify the .

What is reverse ssh tunneling (and how to use it)

Example

Let us suppose that you are configuring a MySQL Source and have:

A MySQL server (can also be a private subnet), and

An internet gateway with an ssh client installed with the following configuration:

Port: 3306

Username: mysql_server_user

Password: [email protected]@5w0rd

Private_key_path: /Users/my_user/.ssh/id_rsa

When you request for a reverse SSH tunnel, Hevo provides you the following details:

Host: us-tunnel.hevodata.com

Username: my_org_hevo_user

Ports: 1500, 1501, 1502, 1503, 1504, 1505, 1506, 1507, 1508, 1509

Based on these details:

You connect to the reverse SSH tunnel by entering the following command on your terminal:

As part of configuring MySQL as the Source in your Hevo Pipeline using reverse SSH tunnel, you specify the settings as follows:

What is reverse ssh tunneling (and how to use it)

Database Host: us-tunnel.hevodata.com

Database Port: 1504

Database User: mysql_server_user

Database Password: [email protected]@5w0rd

Revision History

Refer to the following table for the list of key updates made to this page:

What is reverse ssh tunneling (and how to use it)

  • Instructions
    1. Click on Ubuntu 12.04
    2. Click on Edit virtual machine settings
  • What is reverse ssh tunneling (and how to use it)
  • Instructions
    1. Click on Network Adapter
    2. Click on the Bridged Radio Button
    3. Click on the Close Button
  • What is reverse ssh tunneling (and how to use it)
  • Instructions
    1. Click on Ubuntu 12.04
    2. Click on Play virtual machine
  • What is reverse ssh tunneling (and how to use it)
  1. Change to Gnome Classic
    • Instructions:
      1. Click on the Circle
      • Instructions:
        1. Double Click on GNOME Classic
      • What is reverse ssh tunneling (and how to use it)
      • Instructions
        1. User: Student
        2. Password: Please supply the student password.
      • What is reverse ssh tunneling (and how to use it)
      1. Start up a Terminal
        • Instructions
          1. Click on the Terminal
          • Instructions
            1. sudo su –
            2. Supply the student password.
          • What is reverse ssh tunneling (and how to use it)
          • Instructions
            1. ifconfig -a
              • eth0 is the name of my interface.
              • 192.168.1.111 is my network IP address.
              • If you do not have an DHCP IP Address try the following:
                • dhclient
                  • OR
                  1. Start Ubuntu 12.04
                    • Instructions
                      1. For Windows 7
                        • Start –> All Programs –> VMware Player
                      2. For Windows XP
                        • Starts –> Programs –> VMware Player
                      • Instructions:
                        1. Highlight BackTrack5R1
                        2. Click Edit virtual machine settings
                      • What is reverse ssh tunneling (and how to use it)
                      • Instructions:
                        1. Highlight Network Adapter
                        2. Select Bridged
                        3. Do not Click on the OK Button.
                      • What is reverse ssh tunneling (and how to use it)
                      1. Start BackTrack VM Instance
                        • Instructions:
                          1. Start Up VMWare Player
                          2. Select BackTrack5R1
                          3. Play virtual machine
                          • Instructions:
                            1. Login: root
                            2. Password: toor or .
                          • What is reverse ssh tunneling (and how to use it)
                          • Instructions:
                            1. Type startx
                          • What is reverse ssh tunneling (and how to use it)
                          1. Open a console terminal
                            • Instructions:
                              1. Click on the console terminal
                              • What is reverse ssh tunneling (and how to use it)
                              • Instructions:
                                1. ifconfig -a
                              • Notes(FYI):
                                1. As indicated below, my IP address is 192.168.1.112 .
                                2. Please record your IP address.
                              • What is reverse ssh tunneling (and how to use it)
                              • Instructions:
                                1. service ssh start
                                2. ps -eaf | grep -v grep | grep sshd
                              • Notes(FYI):
                                1. Starting SSH server might not be necessary for other versions of BackTrack. By default BK5R1, the SSH Server does not start by default.
                                2. ps -eaf, Show all processes on the syste
                                3. grep -v grep, do not display the actual process grep.
                                4. grep ssh, display only the sshd process
                              • What is reverse ssh tunneling (and how to use it)
                              1. Clear known_hosts
                                • Instructions: (On BackTrack)
                                  1. cat /dev/null > /root/.ssh/known_hosts
                                  1. This step is not necessary.
                                  2. This step is done to prevent any known_hosts warnings for the purposes of the lesson.
                                  • What is reverse ssh tunneling (and how to use it)
                                  • Instructions:
                                    1. ssh -R 14433:localhost:22 [email protected] 192.168.1.111
                                    2. yes
                                    3. Supply the student password to the Ubuntu VM.
                                  • Notes(FYI):
                                    1. Replace 192.168.1.111 with your Ubuntu IP address obtain from (Section 3, Step 3).
                                    2. “-R” – This option provides the REVERSE tunnel. It specifies that the given port on the remote server is to be forwarded to the given host and port on the local side.
                                    3. “14433” – Is the port that we will use on TargetUbuntu02 (Outside Internet server) to connect back to TargetUbuntu01 (Internal server).
                                    4. “22” – Is the ssh port that we changed to port 14433.
                                    5. [email protected] 192.168.1.111”
                                      • “student” – This is the username you are connecting to Ubuntu as.
                                      • “192.168.1.111” – This is the IP address of Ubuntu. Remember in a real world scenario, Ubuntu would be a server on the Internet OR maybe port forwarded on a home router.
                                      1. See Established Reverse SSH Tunnel
                                        • Instructions: (On Ubuntu)
                                          1. netstat -naop | grep ” 192.168.1.112 “
                                          2. ps -eaf | grep -v grep | grep 3413
                                          1. Replace 192.168.1.112 with your BackTrack IP obtain from (Section 6, Step 2).
                                          2. Replace the Process ID ( 3413 ) obtain from your netstat output.
                                          1. Clear known_hosts
                                            • Instructions: (On Ubuntu)
                                              1. cat /dev/null > /root/.ssh/known_hosts
                                              1. This step is not necessary.
                                              2. This step is done to prevent any known_hosts warnings for the purposes of the lesson.
                                              • Instructions:
                                                1. ssh -p 14433 [email protected]
                                                2. yes
                                                3. Supply student password to the BackTrack VM.
                                              • Notes(FYI):
                                                1. “-p” – This option says use port 14433
                                                2. [email protected]
                                                  • “student” – You are connecting back to BackTrack as username student.
                                                  • “localhost” – You connect to the localhost, since you have a session already established on port 14433.
                                                  • Instructions:
                                                    1. hostname
                                                  • Notes(FYI):
                                                    1. hostname – show or set the system’s host name
                                                    2. You are now logged on the BackTrack VM.
                                                  • What is reverse ssh tunneling (and how to use it)

                                                  I did not find a clear modern description of this set-up so have written this post to help others.

                                                  Say you have a Linux machine to which you want to ssh to but that machine is behind corporate or other firewalls etc which you have no control over, and thus you can not forward an external port for ssh etc. Let’s call that the restricted machine and we assume you can make changes to it, e.g. locally at that machine. This post describes how you can set up a reverse ssh tunnel initiated and maintained from that restricted machine to a port on a Linux server elsewhere on the internet that you control. With the reverse tunnel in place, you can simply ssh to that port on your server to get a tunnelled ssh session back to the restricted machine through the restricted firewalls. Of course you should always check you have permission to do this with whoever controls the restricted network.

                                                  Note that autossh was previously often used for this (and nearly all existing online tutorials about reverse ssh tunnels use autossh) but autossh is redundant nowadays since modern openssh versions can monitor link health and exit if the link fails, and systemd can then be used to restart the ssh tunnel. So autossh is not required, we can implement an automatically maintained ssh tunnel using standard ssh and systemd alone.

                                                  In summary the steps are:

                                                  1. Set up the restricted machine.
                                                  2. Set up the server.
                                                  3. Final set-up and test.

                                                  Set up the restricted machine

                                                  On the restricted machine, create an ssh key pair in /etc/sshtunnel/ with an empty/no pass-phrase:

                                                  Exit fullscreen mode

                                                  Create/paste the following systemd service file in /etc/systemd/system/sshtunnel.service and then edit it as needed for your specific server and ports:

                                                  Exit fullscreen mode

                                                  You may likely want to change some of the unlabelled ssh parameters above so they are described below:

                                                  Parameter Description
                                                  9001 Port on your server to which ssh clients will connect to.
                                                  22 Port you are running the ssh server on the restricted machine. Nearly always the default ssh port 22.
                                                  server.net Internet hostname of your server. I actually use a dynamic DNS alias here (e.g. a hostname at duckdns.org) so I can easily re-select a different target server.
                                                  443 Port on your server where the ssh server is running. Often the default 22 but 443 is recommended as outgoing connections are less likely to be blocked by the restricted firewalls. However, using 443 requires that your server does not have a https server running on that port. Of course, if you use 443 then you must change your sshd configuration to listen on that port.

                                                  Set up the server

                                                  On the server, create an account for the sshtunnel user but restrict it so that shell logins and remote commands are not allowed. The server will only allow the remote sshtunnel user to set up port forwarding:

                                                  Exit fullscreen mode

                                                  Copy the public ssh key you created above on the restricted machine ( /etc/sshtunnel/id_rsa.pub ) to the sshtunnel user’s authorized keys file on the server (

                                                  Ensure the owner/permissions are strictly set as ssh requires them.

                                                  Exit fullscreen mode

                                                  Final set-up and test

                                                  On the restricted machine, enable and start the service:

                                                  Exit fullscreen mode

                                                  Check the status and logs with:

                                                  Exit fullscreen mode

                                                  Then on your server test the tunnel to the restricted machine with the following:

                                                  Exit fullscreen mode

                                                  To diagnose problems, check the sshd logs on both the server and the restricted machine:

                                                  Exit fullscreen mode

                                                  External public access via server (optional)

                                                  For most users, the above configuration is completely sufficient. The tunnel is available by making an ssh connection to the port on the server localhost interface. Either you connect to this locally from within that server, or if you are connecting from another machine then you use the ssh ProxyJump configuration keyword to automatically redirect to the restricted machine via the server proxy, again via the localhost interface.

                                                  Some users may want to make the tunnel port also externally accessible on the server public network interfaces, e.g. for use by users who don’t have ssh access to the server itself. Be aware you are opening a public port directly connecting to the restricted machine if you do this so this approach should be avoided, or at least disable password authentication and only allow ssh key authentication on the restricted machine.

                                                  There are 2 extra steps to add this:

                                                  On the server, enable GateWayPorts yes in /etc/ssh/sshd_config . Then sudo systemctl reload sshd if you changed this.

                                                  You can utilize that established connection to create a new connection via reverse SSH tunneling from your local computer to the remote computer.

                                                  Because the connection was established from the distant computer to you, using it in the other manner is referred to as “in reverse”.

                                                  You’re also establishing a secure connection inside an existing secure connection because SSH is secure. It means that your remote computer connection functions as a private tunnel within the original connection.

                                                  Working Mechanism of Reverse SSH Tunneling

                                                  The remote computer uses the established connection to listen for additional connection requests from the local machine in reverse SSH tunneling.

                                                  On the local computer, the remote machine listens on a network port. It sends the connection request down the http connection back to itself if it detects an SSH request for that port.

                                                  It establishes a new connection between the local and remote computers.

                                                  Reverse Tunneling With SSH

                                                  You need to install the OpenSSH server before using it, but you haven’t done so yet. Install the OpenSSH server to resolve the issue.

                                                  If the local machine has never previously accepted SSH connections, you may need to activate the SSH daemon sshd .

                                                  Construct an SSH Tunnel in the Reverse

                                                  We can use the ssh command to connect to a remote server.

                                                  Once you’ve formed the connection, a person on the remote server-side, such as a system administrator, should run the following command.

                                                  SSH connection requests for port 8080 on your system will be sent to port 92 on the remote server with this connection request. Request for an SSH connection from your machine to your machine.

                                                  You’ll establish a connection to port 8000 in this phase.

                                                  Your request will then be forwarded to the remote server. As a result, when requested for these details, use your remote server account login and password .

                                                  You can also use SSH keys to make connecting from a remote computer to a local computer more secure. Type the following command on the remote computer.

                                                  To construct a secure password , use four words separated by symbols and ensure that only those who know the phrase can access your computer over SSH without asking for a password .

                                                  You must also use the ssh-copy-id [email protected] command to copy the created key to your local computer.

                                                  Today we are going to talk about Plixer’s new Flow Analytics algorithm, Reverse SSH Shell, which has been included in the latest Plixer Scrutinizer update. The Reverse SSH Shell algorithm identifies possible reverse SSH tunnels to external destinations.

                                                  A reverse SSH tunnel allows an external entity access to internal, protected resources via use of an established outbound SSH connection. Reverse SSH tunneling listens on a network port on a local computer. If it detects an SSH request to that port, it relays that connection request back to itself, down the established connection. This provides a new connection from the local computer to the remote computer.

                                                  If you have a hard time setting up our instance in your lab or production environment, it may be better to try it within a simple configured network before you go hardcore and verify it in more complex networks that include network address translation or IPsec site-to-site VPN. This will help you to understand a mechanism of Reverse SSH Shell “connection”.

                                                  How to test the Reverse SSH Shell algorithm

                                                  In my example, I have two different hypothetical networks connected to each other through an IPsec VPN Tunnel.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  We’ll establish a reverse SSH shell between ClientHost and Devil. They are located under different networks and may ping each other because of the VPN tunnel, which will be taken off after the initial connection is established.

                                                  Before we go ahead, navigate to Scrutinizer > Admin > Settings > Reverse SSH Shell, then verify both L3 devices have been added to the exporters list.

                                                  1. SSH from the destination to the source by using a public IP address using the command below:

                                                  Note: Port 19999 can be any unused port.

                                                  2. Now you can SSH from source to destination through SSH tunneling:

                                                  Note: The connection between destination and source must be alive at all time.

                                                  Now how can we see it and how Scrutinizer can help us with a way to define this violation?

                                                  In the screenshot above “10.30.1.118” did appear under the violators list, so let’s take a closer look by clicking on Reverse SSH Shell policy, which will bring up its alarm policy:

                                                  What is reverse ssh tunneling (and how to use it)

                                                  The image above shows when each of those violations happened, and each violation has its own severity level. Further down, we can get a report regarding the connection between the violator and a victim:

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Here we can see the conversation that has happened between the two IP addresses. With the help of Plixer Scrutinizer, we have been able to identify a threat attempt by watching the traffic happened between the two hosts. If you have questions on identifying reverse SSH tunnels in your network, please let us know.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Khalil Ismayilov

                                                  Khalil is a Technical Support Engineer at Plixer. He is dedicated to becoming an expert in networking and spends his free time by discovering a new things in the field. Besides his professional passion, Khalil has fun fishing and playing video games. He prefers an active lifestyle and enjoys spending time with family.

                                                  Related

                                                  What is reverse ssh tunneling (and how to use it)

                                                  XDR: A better mousetrap or just more hype?

                                                  XDR stands for eXtended Detection and Response. What it is depends on who is explaining it. XDR evolved very quickly…

                                                  68 Main St Ste 4
                                                  Kennebunk, ME 04043

                                                  Phone: 1 (207) 324-8805

                                                  • Follow us on Twitter
                                                  • Follow us on Facebook
                                                  • Follow us on Linkedin
                                                  • Follow us on YouTube

                                                  How We Help

                                                  Learn About Us

                                                  Support

                                                  Sometimes that we need to connect via SSH into another computer, we come across the issue that the computer’s IP is not known, or it is behind a NAT (Network Address Translation) and therefore it doesn’t have a public IP address that we could use to connect to it, or it may be behind a firewall that won’t allow access from the outside.

                                                  If the computer that we want to access can successfully establish a SSH connection to another computer that is accessible from both end points, we can utilize this computer as a bridge towards “destiny” to establish a SSH connection, this is known as a “Reverse SSH tunnel”.

                                                  A reverse SSH tunnel works by connecting “destiny” to “bridge” and then utilizing this connection to SSH into “destiny” from any computer that can connect to “bridge”. This reverse SSH tunnel should work in most Linux systems without any problem.

                                                  So, lets assume that we have this two computers:

                                                  “Bridge” IP: aaa.bbb.ccc.ddd

                                                  “Destiny” IP: unknown or unavailable

                                                  First of all, we establish the SSH connection from “destiny” to “bridge”, enabling the reverse SSH functionality with the parameter -R:

                                                  The first number (61999) indicates which port are we going to use in “bridge” to log into “destiny”, localhost is the domain name that we will be using for this as well, and the last number (22) indicates which port is “destiny” listening for SSH.

                                                  Once this connection is live, we connect to “bridge” (it doesn’t matter if we are logged in locally or remotely), and then we can establish the connection to “destiny” using:

                                                  Effectively, we can use a computer with permanent SSH access as a bridge between computers that are not otherwise accessible via SSH. Any computer that is connected to “bridge” can then log into other computers with reverse SSH tunneling enabled.

                                                  SSH (secure shell) tunneling is the process of forwarding selected ports through an authenticated and encrypted tunnel. In many cases, SSH tunneling is used to connect to a remote database that is secured behind a restrictive firewall or other network restrictions.This article walks you through the process of creating an SSH tunnel on Windows using PuTTy.

                                                  Add a public key in your user settings. The public key will be propogated to all Xplenty servers in up to 30 minutes.

                                                  Create a Tunnel Connection in Xplenty. Name your connection. Select Tunnel Connection from the Access Type dropdown menu. Enter the Database name, User name, and Password. Click Create connection. It will fail because we haven’t created the tunnel yet, but the light blue box will appear and you will be able to retrieve Xplenty’s tunnel server (Xplenty server endpoint that includes everything before the colon ) and connection port(the number after the colon) .

                                                  Start a new PuTTy session and set the Hostname to Xplenty server with port 50683. For example:

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connection->Data, enter the tunnel username: sshtunnel
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connection->SSH, check “Don’t start a shell or command at all”
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connection->SSH->Auth, browse for your PPK private key that matches the public key you added in Xplenty.
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connection->SSH->Auth->TTY, check “Don’t allocate a pseudo terminal”.
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connection->SSH->Tunnel: Specify the source port (the connection port assigned to your connection, 53359 in this example), Specify the destination database’s host and port in the destination as “hostname:port”, select the “Remote” option and click “Add”.
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Save the connection – Go back to Session section in sidebar, enter a description for your stored session (xplenty here) then click the save button.
                                                  What is reverse ssh tunneling (and how to use it)

                                                  Connect – double click the Xplenty session to initiate the connection.

                                                  Return to the Xplenty dashboard. After entering the database name, username, and password, click Test Connection.

                                                  You can set up a reverse tunnel to allow ThoughtSpot Support to get access to your ThoughtSpot instance, to perform support-related activities.

                                                  Set up a reverse tunnel for support

                                                  You can set up a reverse tunnel to allow ThoughtSpot Support to get access to your ThoughtSpot instance, to perform support-related activities. This setup is scalable, more secure, and a much simpler alternative to using a virtual meeting room.

                                                  Granting remote support access can streamline troubleshooting activities, because it enables your support agent to work directly on your computer form a secure setting. The remote tunnel enables SSH and HTTP access to your ThoughtSpot instance by ThoughtSpot Support. You can grant and revoke this access easily, so you can enable it for a troubleshooting session, and then disable it again. Before doing this procedure, make sure your company’s security policies allow reverse tunneling.

                                                  Before you set up a reverse tunnel, open port 22 in your firewall outgoing rules to add tunnelrelay.thoughtspot.com to your list of allowed domains.

                                                  Configure reverse SSH tunnel

                                                  To configure a reverse SSH tunnel, navigate to the Admin Console by clicking on the Admin tab from the top navigation bar. Select Security from the side navigation bar that appears.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Select Edit to enable or disable the tunnel.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  The system asks you to tunnelrelay.thoughtspot.com to your list of allowed domains, if you have not already.

                                                  If you have added tunnelrelay.thoughtspot.com to your list of allowed domains, by opening port 22 , the system allows you to enable or disable the reverse SSH tunnel.

                                                  Toggle Enable or Disable and select Save.

                                                  ThoughtSpot is the Search & AI-driven Analytics platform for the enterprise. Anyone can use search to analyze company data in seconds and get automated insights when you need them.

                                                  You are running a Linux server at home, which is behind a NAT router or restrictive firewall. Now you want to SSH to the home server while you are away from home. How would you set that up? SSH port forwarding will certainly be an option. However, port forwarding can become tricky if you are dealing with multiple nested NAT environment. Besides, it can be interfered with under various ISP-specific conditions, such as restrictive ISP firewalls which block forwarded ports, or carrier-grade NAT which shares IPv4 addresses among users.

                                                  What is Reverse SSH Tunneling?

                                                  One alternative to SSH port forwarding is reverse SSH tunneling. The concept of reverse SSH tunneling is simple. For this, you will need another host (so-called relay host) outside your restrictive home network, which you can connect to via SSH from where you are. You could set up a relay host using a VPS instance with a public IP address. What you do then is to set up a persistent SSH tunnel from the server in your home network to the public relay host. With that, you can connect “back” to the home server from the relay host (which is why it’s called a reverse tunnel). As long as the relay host is reachable to you, you can connect to your home server wherever you are, or however restrictive your NAT or firewall is in your home network.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Set up a Reverse SSH Tunnel on Linux

                                                  Let’s see how we can create and use a reverse SSH tunnel. We assume the following. We will be setting up a reverse SSH tunnel from homeserver to relayserver , so that we can SSH to homeserver via relayserver from another computer called clientcomputer . The public IP address of relayserver is 1.1.1.1.

                                                  On homeserver , open an SSH connection to relayserver as follows.

                                                  Here the port 10022 is any arbitrary port number you can choose. Just make sure that this port is not used by other programs on relayserver .

                                                  The -R 10022:localhost:22 option defines a reverse tunnel. It forwards traffic on port 10022 of relayserver to port 22 of homeserver .

                                                  With -fN option, SSH will go right into the background once you successfully authenticate with an SSH server. This option is useful when you do not want to execute any command on a remote SSH server, and just want to forward ports, like in our case.

                                                  After running the above command, you will be right back to the command prompt of homeserver .

                                                  Log in to relayserver , and verify that 127.0.0.1:10022 is bound to sshd . If so, that means a reverse tunnel is set up correctly.

                                                  Now from any other computer (e.g., clientcomputer ), log in to relayserver . Then access homeserver as follows.

                                                  One thing to take note is that the SSH login/password you type for localhost should be for homeserver , not for relayserver , since you are logging in to homeserver via the tunnel’s local endpoint. So do not type login/password for relayserver . After successful login, you will be on homeserver .

                                                  Connect Directly to a NATed Server via a Reverse SSH Tunnel

                                                  While the above method allows you to reach homeserver behind NAT, you need to log in twice: first to relayserver , and then to homeserver . This is because the end point of an SSH tunnel on relayserver is binding to loopback address (127.0.0.1).

                                                  But in fact, there is a way to reach NATed homeserver directly with a single login to relayserver . For this, you will need to let sshd on relayserver forward a port not only from loopback address, but also from an external host. This is achieved by specifying GatewayPorts option in sshd running on relayserver .

                                                  Open /etc/ssh/sshd_conf at relayserver and add the following line.

                                                  Debian-based system without systemd :

                                                  Debian-based system with systemd :

                                                  Red Hat-based system:

                                                  Now let’s initiate a reverse SSH tunnel from homeserver as follows.

                                                  Log in to relayserver and confirm with netstat command that a reverse SSH tunnel is established successfully.

                                                  Unlike a previous case, the end point of a tunnel is now at 1.1.1.1:10022 ( relayserver ‘s public IP address), not 127.0.0.1:10022. This means that the end point of the tunnel is reachable from an external host.

                                                  Now from any other computer (e.g., clientcomputer ), type the following command to gain access to NATed homeserver .

                                                  In the above command, while 1.1.1.1 is the public IP address of relayserver , homeserver_user must be the user account associated with homeserver . This is because the real host you are logging in to is homeserver , not relayserver . The latter simply relays your SSH traffic to homeserver .

                                                  Set up a Persistent Reverse SSH Tunnel on Linux

                                                  Now that you understand how to create a reverse SSH tunnel, let’s make the tunnel persistent, so that the tunnel is up and running all the time (regardless of temporary network congestion, SSH timeout, relay host rebooting, etc.). After all, if the tunnel is not always up, you won’t be able to connect to your home server reliably.

                                                  For a persistent tunnel, I am going to use a tool called autossh . As the name implies, this program allows you to automatically restart an SSH session should it breaks for any reason. So it is useful to keep a reverse SSH tunnel active.

                                                  As the first step, let’s set up passwordless SSH login from homeserver to relayserver . That way, autossh can restart a broken reverse SSH tunnel without user’s involvement.

                                                  Next, install autossh on homeserver where a tunnel is initiated.

                                                  From homeserver , run autossh with the following arguments to create a persistent SSH tunnel destined to relayserver .

                                                  The -M 10900 option specifies a monitoring port on relayserver which will be used to exchange test data to monitor an SSH session. This port should not be used by any program on relayserver .

                                                  The -fN option is passed to ssh command, which will let the SSH tunnel run in the background.

                                                  The “-o XXXX” options tell ssh to:

                                                  • Use key authentication, not password authentication.
                                                  • Automatically accept (unknown) SSH host keys.
                                                  • Exchange keep-alive messages every 60 seconds.
                                                  • Send up to 3 keep-alive messages without receiving any response back.

                                                  The rest of reverse SSH tunneling related options remain the same as before.

                                                  If you want an SSH tunnel to be automatically up upon boot, you can add the above autossh command in /etc/rc.local .

                                                  Conclusion

                                                  In this post, I talked about how you can use a reverse SSH tunnel to access a Linux server behind a restrictive firewall or NAT gateway from outside world. While I demonstrated its use case for a home network via a public VPS, you must be careful when applying it for corporate networks. Such a tunnel can be considered as a breach of a corporate policy, as it circumvents corporate firewalls and can expose corporate networks to outside attacks. There is a great chance it can be misused or abused. So always remember its implication before setting it up.

                                                  Support Xmodulo

                                                  This website is made possible by minimal ads and your gracious donation via PayPal (Credit Card) or Bitcoin ( 1M161JGAkz3oaHNvTiPFjNYkeABox8rb4g ).

                                                  Establish connectivity from the destination database to the source database through a secure reverse SSH tunnel. This method requires a bastion host VM in the Google Cloud project as well as a machine (for example, a laptop on the network) that has connectivity to the source database.

                                                  The Database Migration Service for MySQL collects the required information at migration creation time, and auto-generates the script for setting it all up.

                                                  See the following diagram:

                                                  The following steps are performed in the Database Migration Service Create migration flow, to set up a reverse SSH tunnel between the source database and Cloud SQL instance. After you provide some parameters, you execute a set of gcloud commands on a machine which has connectivity to both the source database and to Google Cloud.

                                                  Select the VM instance used to establish connectivity between the source database and the Cloud SQL instance. Typically this is a VM running in the VPC where the application accessing the new Cloud SQL database runs. The VM instance serves as the SSH tunnel bastion server.

                                                  You can use an existing Compute Engine VM instance for this purpose.

                                                  Choose the Compute Engine VM instance from the list.

                                                  Provide a free port that the SSH tunnel can use.

                                                  Alternatively, you can create a new VM at this step. Select CREATE A COMPUTE ENGINE VM INSTANCE and the generated script includes instructions to create it.

                                                  Provide a name for the VM instance.

                                                  Select a machine type for the VM.

                                                  Specify a subnet for the VM

                                                  Click VIEW SCRIPT to view the generated script.

                                                  By default, the script will generate a public IP address for the Compute Engine VM server. If you want the IP address to be private, then do the following:

                                                  • Alter the gcloud compute instances create command by adding the –no-address flag.
                                                  • Alter the gcloud compute ssh command by adding the –internal-ip flag.

                                                  Also, if you want to create a bastion host VM on a subnet which is on a shared VPC, then alter the export SUBNET_NAME command from the generated script to point to /projects/ project_name /regions/ region_name /subnetworks/ subnetwork_name .

                                                  project_name is the name of the project where the shared VPC is placed. A project has regions and subnetworks. region_name and subnetwork_name are the names of the region and subnetwork that are associated with the VPC project.

                                                  Run the script on a machine that has access to both the source database and the Compute Engine VM. The script performs the following operations:

                                                  Configures the Compute Engine VM as an SSH tunnel bastion server.

                                                  Establishes a secure SSH connection between the source database and the VPC.

                                                  If you’re creating a new Compute Engine VM, then after successfully running the script, copy the VM server IP from the script output and enter it in the provided text field. The Cloud SQL instance will be updated as needed when you later test or start the migration job.

                                                  Click CONFIGURE & CONTINUE.

                                                  Verify your migration job to confirm that it correctly migrated data from your source database instance to the destination Cloud SQL database instance.

                                                  If your source is within a VPN (in AWS, for example, or your own on-premises VPN), proceed to the section on connecting VPCs through VPNs for more information on configuring the source VPN and Google Cloud VPN to work with each other.

                                                  After your migration job is configured, connectivity is verified, and VPNs are configured successfully if necessary, then you can run the job.

                                                  Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  If you’re lucky enough that your Internet Service Provider (ISP) gives you a dedicated IP address, you can set up a home server and make it available to the Internet by adding a few port forwarding rules to your router. But if your ISP makes you share that IP with your neighbors, then port forwarding won’t help. Other providers simply block incoming connections through firewall rules.

                                                  You can bypass all of these restrictions with the help of a virtual private server. Anything will work, even if it has less than 512MB of RAM, as all it has to do is redirect network traffic. This is very light on CPU and RAM. The server will receive incoming connections and redirect them to your computer through what is called a “reverse SSH tunnel.” This way you can set up any kind of home server, with very small monthly costs.

                                                  Also read: 7 of the Best Dynamic DNS Providers You Can Use for Free

                                                  Imagine you create a NextCloud server to upload/synchronize your files. You get the privacy of having those files on your home server, and then you can buy a 6TB hard drive to get all the space you need. You only have to pay a monthly electricity bill and less than $5/month for a virtual private server. That’s way cheaper than the monthly bill for a server with 6TB of space.

                                                  Note: This only works for redirecting TCP network traffic. TCP is used by things such as web servers (port 80/tcp). UDP is used by some (not all) game servers, for example Counter Strike (port 27015/UDP). UDP tunneling is possible, but with some “hacks,” which may be the topic of a future tutorial.

                                                  Windows 10 Now Has a Built-in SSH Client

                                                  There’s no need to use PuTTY anymore to initiate SSH connections. In fact, for this tutorial you will actually use this built-in client to set up the tunnel. Read the tutorial about Windows 10’s OpenSSH client if you’re not already familiar with it.

                                                  Prepare Virtual Private Server to Tunnel Connections

                                                  Create a Virtual Private Server with your favorite provider, like DigitalOcean, Linode, Vultr, or whatever else you prefer. The most important thing is to choose a server location that is as close to you as possible to minimize network latency. Try to set up the server in such a way that you get to log in to the root account directly, preferably with an SSH key, as it’s more secure. This is required if you want to make the server listen to connections coming on ports below 1024, so-called privileged ports.

                                                  Open command prompt (or a terminal if you’re on Linux), and log in to the server through SSH.

                                                  Edit OpenSSH server settings:

                                                  If you didn’t log in as root but as a regular user, you will need to use this command, otherwise you won’t be able to save the file:

                                                  Scroll down until you find a variable called “GatewayPorts.” The line may look like this: #GatewayPorts no . Delete the preceding “#” (to uncomment) and change the line to GatewayPorts yes .

                                                  What is reverse ssh tunneling (and how to use it)

                                                  If you can’t find the line, just scroll down to the end and add the line yourself:

                                                  Press Ctrl + X , then press y , and finally Enter to save the file.

                                                  Reload the SSH daemon so it picks up on the new setting.

                                                  Exit from the SSH session.

                                                  How to Set Up a Reverse SSH Tunnel

                                                  The command parameters are the same on Linux, Windows, and even BSD operating systems. The general syntax is:

                                                  • remote_port tells the server to redirect connections that come to it on that port.
                                                  • host tells the server at what IP address the connection should be redirected to. 127.0.0.1 will be used here to redirect to your own computer.
                                                  • localport instructs what port data packets should be redirected to. Here, you should put the port number that your application, installed on your local computer, listens on.

                                                  For example, to forward all connections that come on port 80 (to the server) and send them to port 8080 on your local computer, the command would be:

                                                  This assumes that you have a web server, like Apache or Nginx, that listens on port 8080 on your local machine. But if Apache/Nginx is listening on the default port 80, then there is no problem using the same port twice in the previous command (since they are referring to port 80 in a different server).

                                                  At this point, if someone enters the IP address of your virtual private server in the address bar of a browser, their connection would be redirected and served by your local computer.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  In the picture above, a simple web server for Chrome was used that listens on port 8887 by default. You can try this setup yourself by installing the app and then using the command, as in the picture.

                                                  It’s worth mentioning that to keep the tunnel active, your SSH session must remain active. To close the tunnel, type exit in the terminal/command prompt window.

                                                  Conclusion

                                                  As you can see, it’s not hard to create a reverse SSH tunnel, but securing a website is. So if you choose to implement an idea like a local NextCloud server, isolate it in a virtual machine at least. This way, if your website gets compromised, at least the rest of your operating system will be unharmed.

                                                  And, you know … always back up what you don’t want to risk losing!

                                                  Hello how can i create a working Reverse ssh tunnel like this commend should do:

                                                  This create the process on the intermediary computer.

                                                  This code in in test state so this is the reson why i use private ip for home user. I would like to test before i try it on public server.

                                                  So the working part is: I can locate the success LISSENING port in intermediar computer named sshd.exe and with localport 1234;remote port:22.
                                                  It looks good.

                                                  But instead of adding rule for eneble 12345 port tcp on the firewall with inbould direction. The port scan from 3th Computer on the network show port is refuses conenctions.

                                                  So here i got stuck. From 3th computer say in time ssh connection attempt to connect to destination computer throught intermediary computer: Connection refused.

                                                  As far as i know it would work but not work. Naturaly the public authentication work seemless and with normal ssh completely work the login.
                                                  Althought I may locate an error when i run that command. The command not completed just run. ‘ _ ‘ blicking infinity till not close the cmd window

                                                  Apologies for the delay in response. Thank you for reaching out & hope you are doing well.

                                                  Just wanted to confirm if this setup is in Azure? And when you say NAT, where is this located?
                                                  I found this blog which might give you some reference on reverse SSH setup.

                                                  In the meantime, I will check with the Azure VM team to see if they have any further insights to provide here.

                                                  I’m following up on this post to check for any updates from your end.

                                                  1 Answer

                                                  NAT located on the computer that i want to manage. So NAT rules only say i block and drop all inbound package but outbound still goes out. Therefore remote computer throught relay server (public ip and allowed incomming rule for manage ssh tunnel) able to connect to remote host.

                                                  So it is a Windows computer so please not send me linux commands. And it is a Home computer but the relay server is an EC2 Amazon linux server. Problame with this only that this plan allow limited network resources and what is more important the bandwith limit is so little. Only command base management without GUI has worth.

                                                  And the above command can be modify to do that:

                                                  ssh -fN -R 100.100.100.1:12345:localhost:22 [email protected] -P 4567

                                                  So if we interpret this it say: forward from 100.100.100.1:12345 to localhost:22 (that is the relay server internal or Nat network’s address) by authentication data of relay server on 4567 ssh port (conenctions started from HOST not from client where we want to conenct back to tunnel other End-point. ).

                                                  And when we initialize the ssh connection from remote client we will call the 18.45.23.XX where gatway will forward to internal 100.100.100.1 that is return back to Host ssh tunel original end.
                                                  If we want to wrap some protocol inside the SSH tunel we also need an Loopback adapter on HOST. Tested with SMB. Connection encrypted all the way of route. The protection only depends from private key complexity, so from the key managment. Even if the network is attacked the enscripted data stay enscripted if you not cashed that sensitive information or laked wherewith able the attacker to descript anything.

                                                  From your above description, I understand that your setup involves your home computer (on-premises) and EC2 Amazon linux server. This question was tagged as Azure, so I would like to know if there is any Azure component involved in your setup? If not, then we have to re-tag the question to Windows server to get better assistance on this issue.

                                                  I’m following up on my previous comment to check if there are any Azure components involved in your setup. Looking forward to your response.

                                                  Some deployments may encounter a situation where Local Managers are placed in a network where the LM is able to initiate a connection to the Control Center (for heartbeat), but connections to the LM are not possible. This could be caused by NATs, firewalls, or simply being on a private network.

                                                  To overcome this limitation, a Reverse SSH Tunnel can be initiated from the Local Manager to the Control Center. If a user’s connection is proxied through the Control Center, the connection can then piggyback on the tunnel to reach the Local Manager.

                                                  The Control Center handles the configuration and synchronization of the Reverse SSH service, so most options are not available for editing. If you need to change the Reverse SSH or Proxy Port, you can edit /etc/sysconfig/embassy.overrides and add the following lines:

                                                  The default SOCKS 5 Username is uplogix. The password is automatically generated during install. If you change these settings, the new information will be synchronized automatically throughout the deployment.

                                                  Enabled

                                                  Turns on the Reverse SSH service for the Local Manager (or group of Local Managers).

                                                  Limit SSH login to RSSH only

                                                  For added security, you can disable the default port 22 SSH service on a Local Manager and limit connections to those initiated through the Reverse SSH tunnel.

                                                  Reverse SSH Server Port

                                                  If you changed the Server Port on the Control Center’s Reverse SSH server, enter it here (this is not common).

                                                  SSH Keep-Alive Seconds

                                                  Specify how often the Local Manager should send a keep-alive packet to ensure the connection stays up. You should not need to change this value.

                                                  SSH Keep-Alive Bytes

                                                  Specify the size of the keep-alive packet. You should not need to change this value.

                                                  SSH Client Fingerprint

                                                  For reference, the SSH client fingerprint is displayed after this feature is enabled.

                                                  Enabling this feature automatically synchronizes all necessary information between the Control Center and the Local Manager.

                                                  This feature is separate from the SS5 SOCKS proxy and does not require it to be present or configured.

                                                  Click on the SSH button on the Local Manager Summary page to initiate a connection. The Applet will automatically connect to the Reverse SSH proxy on the Control Center, which will then connect the Applet to the Local Manager via the Reverse SSH tunnel.

                                                  To view the status of the Reverse SSH tunnel, log into the Local Manager and run the show system reverse-ssh command.

                                                  By default, the Control Center will listen for Reverse SSH connections on port 2222. If you will not be using Reverse SSH and would like to close port 2222, you can do so by becoming root and issuing the following commands:

                                                  The service command turns off the Reverse SSH service. The chkconfig command prevents the Reverse SSH service from starting after a reboot.

                                                  Need to have remote shell access to a Mac from anywhere in the world?

                                                  Reverse SSH tunnels to the rescue!

                                                  What is reverse ssh tunneling (and how to use it)

                                                  A reverse SSH tunnel is exactly what it sounds like; an SSH tunnel in reverse. Your computer connects to a remote server and then opens up a tunnel back to itself. You can then connect to that server and have access to your machine. This is a very clean way to get around the problem of dealing with NAT traversal and firewalls. No port forwarding necessary.

                                                  OSX supports launch daemons. These are processes that start up when you boot up your Mac. It’s simple to use a launch daemon to keep the SSH tunnel alive for remotely accessing the machine anytime. The daemon will reconnect to the server immediately after the event of a connection drop or if your IP address changes.

                                                  The Process

                                                  1. Enable SSH on your Mac.

                                                  Go to System Preferences -> Sharing. Enable the “Remote Login” checkbox and add your username to the whitelist.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  2. Configure the server.

                                                  Note: If you need a server, I can’t speak more highly of DigitalOcean. I host this website there and their basic VPS packages start at $5/month.

                                                  Setup the server to maintain the connection with a keepalive packet:

                                                  3. Setup SSH Keys.

                                                  SSH keys allow you to quickly, securely, and automatically login to a server without a password. If you haven’t already, generate SSH keys on the client and server.

                                                  First, we’ll test out the reverse SSH tunnel to the server. We’ll then use this tunnel to copy the server’s key to the client to enable easy access.

                                                  Open up a terminal, and run this command.

                                                  Open a new terminal window, and run these commands to copy the server’s key into your client’s authorized_keys file:

                                                  (Where “localUser” is the username on your Mac)

                                                  You should then be able to log in to your Mac without being prompted for a password.

                                                  4. Create the launch daemon on your Mac.

                                                  This launch daemon will open the SSH tunnel at startup, keep it alive, and restart it if it dies. For more background on launch daemons, see Apple’s Documentation.

                                                  Create a file at /Library/LaunchDaemons/reverse.ssh.tunnel.plist. This file should contain the following:

                                                  Here’s an explanation of those option parameters:

                                                  -N: Don’t run a remote command. The remote command will fail anyway due to the restrictions imposed by the authorized_keys file. -T: Disable pty allocation, which is unnecessary when only port-forwarding is desired. -C: Request compression. This is optional, but can potentially speed up the connection slightly. -o ServerAliveInterval=60: The client will attempt to send keepalive pings to the server every 60 seconds. -o ExitOnForwardFailure=yes: If port forwarding fails to get setup due to something like another process (or old ssh process) being bound to the hardcoded port, fail and return. -R 12345:localhost:22: Remotely forward the localhost port 22 (sshd) to the server’s port 12345, as shown earlier. [email protected]: Self-explanatory. Connect to servername with user remoteuser. RunAtLoad: Run the daemon at system load time.

                                                  How would I use SSH Tunneling for an architecture in the example below?

                                                  Scenario: I am physically logged into Windows PC Local and wish to remote desktop into the Windows PC Remote using port 3389. There is a firewall between Windows PC Local and the Network A Linux Server that only allows me to SSH from PC local to the Linux Server on Network A. Is it possible to establish a reverse tunnel on the Network A Linux Server through to the Windows PC Remote? I am thinking that 3 or more tunnels would have to be established and linked together to accomplish this, but I don’t know how to do it or know if it is possible.

                                                  1 Answer 1

                                                  You can actually accomplish this with a single SSH tunnel between the two Linux servers, more specifically from the one on Network A to the one on Network B (the direction in which it can SSH.)

                                                  Assuming you want to remote desktop into the Remote Windows machine (the one on the side of Network B), then you need a direct SSH tunnel.

                                                  (A reverse SSH tunnel would be if you wanted to expose a service from a machine in network A to machines in network B through this SSH connection initiated on the Linux server in network A.)

                                                  To understand how to set this up, let’s assign some IP addresses and names to the machines and interfaces involved. Otherwise, it’s hard to understand which exact addresses and names go where.

                                                  Let’s use these addresses for the local network:

                                                  Then these addresses for the remote network:

                                                  Visualizing only the interconnect between the two Linux servers:

                                                  So, in order to create an SSH tunnel that will allow you to connect to the remote Windows machine, this is what you need:

                                                  One that SSH connection is established, from Windows machine workstation7 you can open an RDP connection to linrouter4 on the default port, and what you’ll get is a forwarded connection to Windows machine remote76.lan on the remote host.

                                                  The tunnel is configured using the -L flag to SSH, which takes up to 4 addresses or ports separated by colon.

                                                  The first pair indicates the address and port where to receive connections on the local host. The IP address needs to be an address configured on an interface on the local host, of course, otherwise the host wouldn’t be able to receive connections at that address. We’re using linrouter4 ‘s address in the local network, so that other machines in the local network will be able to access that tunnel.

                                                  The next item is the local port. We’re using the default port of 3389, so our RDP client can connect on the default port. If you’re configuring multiple SSH tunnels or running other services on that machine using that port, you might need to pick alternative ports, in which case you’ll have to reconfigure your RDP client to connect on the non-standard port. For this simple example we’re bypassing that by using the default port.

                                                  The last pair of address and port are the ones that our destination host ( gateway1.lan ) is supposed to connect to when a connection reaches the tunnel on the other end. Note that name resolution will happen on the destination host, so we’re able to use name remote76.lan even though the local linrouter4 machine isn’t able to resolve that name.

                                                  Finally, we have the remote port, which is again the default of 3389.

                                                  We then use the normal parameters to connect to the remote host, using its external address ( b.example.net ) and specifying an username ( myuser ) if necessary. Any other arguments needed for authentication or other settings can also be passed.

                                                  The -L flag can also take only 3 items rather than 4, in which case the local address is skipped. For example, -L 3389:remote76.lan:3389 . But that would only expose it on localhost (127.0.0.1), which means that linrouter4 itself can open connections through the tunnel, but not other hosts connected to that machine. (In other words, we need the full specification.)

                                                  Finally, note that we used a hostname for the remote host, but we could have used IPs too. Same for the local host, we could have used a name instead of the IP, assuming that machine will resolve the name to the internal IP.

                                                  Also would have worked:

                                                  • -L 192.168.10.4:3389:172.24.10.76:3389
                                                  • -L linrouter4:3389:remote76.lan:3389

                                                  Furthermore, you can use ‘*’ at the local end to have that host accept connections on any interfaces: -L ‘*:3389:remote76.lan:3389’ . (Note you’ll want to use quotes when using * since the shell can interpret it as a metacharacter.) Using * is not ideal, since that means accesses coming from Network A (the Internet?) might be able to use the SSH tunnel to reach protected host in the remote network. Using an explicit internal-only address is definitely a more secure configuration (even though you’re potentially exposing that tunnel to the whole internal network, unless you set up a firewall explicitly to only allow specific hosts.)

                                                  For my personal development environment I have setup a reverse tunnele via ssh between a raspberry pi as the server which hosts my applications and a 5$ DO droplet instance with nginx and certbot to act as the publicly available ip point of my application:

                                                  Like below:

                                                  Raspberry Pi (origin server containing my in development application code for my flask and nodejs projects) === ssh reverse tunneling ===> DO instance with certbot and nginx

                                                  For tunneling itself I am using a command like the one below:

                                                  ssh -R 5000:localhost:5000 [email protected]

                                                  Desired Next Step:

                                                  I was thinking of using the same technology for a real WP website like this, so in other word I have the WordPress website hosted on my Raspberry Pi and then my domain being linked to my DO instance and whenever someone comes to my domain, the traffice gets redirected to the local Raspberry Pi via the reverse tunneling:

                                                  Request comes to domain.com linked to digital ocean instance => nginx on the DO instance reverse proxies the traffic to the local port 5000 (the port which is being reverese tunneled to from my local pi) => the reverse tunnel sends the traffic to the local pi and the application to get the desired outcome and return it to the one who asked data from the domain

                                                  My Question:

                                                  What type of metrics should I pay attention to and what tips and tricks can I use to increase number of concurrent traffic to setup more or less similar to the desired setup above?

                                                  I frequently need to get access to a machine behind a firewall to do some web development, but I don’t have a VPN available. Not a problem – just use a reverse SSH tunnel. By the end of this tutorial, we’ll be able to SSH to the remote server, as well as view any web pages that server has access to.

                                                  We’re going to connect to the remote server using our local port 5000 – here’s how.

                                                  The 2 boxes we’ll use will be my.home.com (also referred to as localhost) and my.remote.com. We’re assuming you somehow have access to my.remote.com – maybe while at work or through some tool like Citrix. You might want to add monitoring to this to make it stable, but that’s outside the scope of this tutorial. Also, you’ll need direct outside access to your home machine – so you might need to configure your router to do port forwarding.

                                                  1. First, from the remote server, SSH back to yourself.

                                                  ssh -R 5000:localhost:22 [email protected]

                                                  You can now SSH to the remote box through the tunnel by typing

                                                  All local traffic that connects to port 5000 is being forwarded via SSH through your reverse tunnel, back to port 22 on the remote machine.

                                                  The other half of the problem is viewing web pages of dev boxes behind the firewall – it turns out this is pretty easy once you’ve got the reverse proxy going.

                                                  2. On your home machine type the following:

                                                  ssh -D 9999 [email protected] -p 5000

                                                  3. Next, you’ll need to set up a SOCKS proxy. Open your browsers settings and it to the server “localhost” on port 9999. This will forward your traffic back through the tunnel and to the remote server. I do this using FoxyProxy & Firefox, so I can limit the domains that actually route through the proxy.

                                                  That’s about it – you should now be able to visit any site that’s in the private network. You now have command line and full browser access.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Normally, an SSH client would connect to an SSH server for SSH access.

                                                  But if you want SSH access to the SSH client from the SSH server? That’s when you setup a SSH reverse proxy tunnel.

                                                  What is a reverse proxy tunnel

                                                  Sometimes, you may want to access a SSH Client behind a NAT router, from a public SSH server. For this you need to create an SSH tunnel from the SSH client to the SSH server, so that the client and its network can be accessed via the tunnel. This is called SSH reverse proxy tunneling.

                                                  How to create a Reverse SSH tunnel

                                                  Let’s take the following scenario: Source (Public IP: 202.10.135.4) -> Internet -> NAT -> Destination(Local IP: 192.168.1.1)

                                                  Step 1:

                                                  Reverse SSH into the Source ( 202.10.135.4) from the Destination(192.168.1.1).

                                                  Step 2:

                                                  Now you can SSH into the Destination behind NAT from the public Source via the Reverse SSH Tunnel endpoint ( port 20022) created in step 1.

                                                  How to create a Reverse SSH tunnel port forwarding ?

                                                  Let’s say you want to access a nodejs web application running in the Destination behind a NAT router. Let’s say the web application listens on TCP port 3000.

                                                  Note: You could use the same procecure discussed below to create a reverse SSH proxy tunnel to remote access any TCP service (SSH, SMTP, MQTT, VNC etc) running in your local network or local server.

                                                  Let’s use the following simple nodejs web application for the demo.

                                                  We can use the Reverse SSH Tunnel port forwarding feature to access the web application.

                                                  Here is how to do it.

                                                  Source (Public IP: 202.10.135.4, Port: 20022) ==> Internet ==> NAT ==> Destination(Local IP: 192.168.1.1, Port: 3000)

                                                  Step 1:

                                                  Reverse SSH into the Source ( 202.10.135.4) from the Destination(192.168.1.1).

                                                  Step 2:

                                                  From the Source, access the nodejs web application running in the Destination behind a NAT router, as follows:

                                                  Problem:

                                                  The only problem with this approach to access the Destination behind a NAT router is that the Source needs to have a public IP address. Otherwise, it is not possible to establish a Reverse SSH Tunnel from the Destination to the Source.

                                                  What if the Source is also behind a NAT and wants to access the Destination behind another NAT ?

                                                  Source (Local IP: 10.1.1.1) ==> NAT ==> Internet ==> NAT->Destination (Local IP: 192.168.1.1)

                                                  Solution:

                                                  A simple and easy way to solve this tricky problem is to use a simple and easy to use remote access solution like SocketXP. SocketXP creates a secure SSL based reverse proxy tunnel. Interestingly, SocketXP offers a free tier of service for beginners and developers.

                                                  Follow the below steps to make the nodejs web application behind a NAT router accessible from the internet, using the SocketXP Remote Access solution.

                                                  Step #1:

                                                  Download and install the SocketXP Client from the download page.

                                                  Step #2:

                                                  Next authenticate and register the SocketXP Client with the SocketXP Cloud Gateway, using the auth-token from the Portal Page

                                                  What is reverse ssh tunneling (and how to use it)

                                                  Click the copy button to copy the command string and paste it in the terminal window in your laptop or server.

                                                  Step #3:

                                                  After registering the SocketXP Client with the SocketXP Cloud Service, you could create HTTP proxy tunnel between the application running in your laptop and the SocketXP Cloud Service, via the SocketXP Client.

                                                  As our nodejs app is a web application(HTTP server), let’s create a HTTP proxy tunnel.

                                                  Use the following command to create a HTTP proxy tunnel between the nodejs web application and the SocketXP Cloud Service.

                                                  Step #4:

                                                  Let’s access the nodejs web application from the internet using the SocketXP Public URL provided in the above output.

                                                  What is reverse ssh tunneling (and how to use it)

                                                  You could now share the above link to your customers or remote employees, so that they could access your web application from anywhere in the world.

                                                  The above SocketXP public URL is a permanent link just assigned to you and it doesn’t change until you manually delete it from the tunnels section in the portal.

                                                  Conclusion:

                                                  Reverse SSH Tunnel port forwarding is a great way to selectively expose applications and network services running in your private network to your customer applications running in your customer’s private network.

                                                  Creating Reverse SSH Tunnels with port forwarding using SocketXP Cloud Service is a simple and secure way to selectively expose applications or services running in your private to your customers or vendors.

                                                  Note that the reverse SSH tunnel encrypts the data end-to-end between the source and the destination server using SSL/TLS. There is no way that anyone including SocketXP Cloud Service could decipher the information sent over this secure tunnel.