Learning to use SSH tunneling for secure surfing. Tunneling protocols - what are they? Accessibility Mapping

Mar 28, 2012 By Jayson Broughton
in HOW-TOs SysAdmin

“If you see a light at the end of a tunnel, it is the light of an approaching train,” Robert Lowell. Another good quote. This article is about building tunnels with using SSH, or as I call this topic, "VPN tunnels for the poor." Despite the basic beliefs of system administrators, SSH tunnels can actually be quite useful thing for both techies and home use. I say "despite the beliefs of sysadmins" because reverse tunnels or web traffic wrapped in SSH can get through firewalls and content filters. The article, however, is not about how you can subvert corporate security policies, but about how SSH tunneling can make our lives a little less complicated.

Why SSH tunnels instead of VPN? Ok, I use this and that at home. If you've been following me on jaysonbroughton.com, you know that I have OpenVPN three-factor authentication (username, certificate, and one-time password) in the works. But if I want to check one of the servers under my control via Android, or look into a computer on which I do not have administrative rights (and the portable OpenVPN client needs them), or even want to fix some errors using vnc access over SSH tunnel, then SSH is my choice of way to secure traffic.

We'll discuss the basics: how to build a tunnel, what each command syntax means, examples of reverse tunnels, and situations in which you should use one or another approach. I also briefly went over the structure of the configuration file.

So oh system requirements. I use Debian in virtual environment, so your results may differ from mine. Therefore, I provide information about the tools: the OpenSSH_5.3p1 server and OpenSSH 5.X clients of various versions are in use. Before diving into the depths of ssh tunneling, I must say: before poking a hole in a company’s security using a reverse tunnel or wrapping http traffic, make sure that you do not violate any stack of internal regulations such as the Internet Acceptable Use Policy. It is clear that in this case the System Administrators will immediately hunt you down and fry you, especially if you are using a tunnel to get to the server at work from home. As a System Administrator myself, I get great pleasure from discovering such characters. Believe me, with a little checking it turns out that system administrators not at all idiots.

Well, the disclaimer has been announced, you can get started.

Building SSH tunnels is a fairly simple thing. Understanding what's going on and learning approaches can be a little more difficult. So I'll give a few typical cases to adjust the consciousness before we move on to the details of the commands. Before I had children, I traveled quite a bit. In my travels I have found myself in very strange hotels, the rooms of which had very strange Wi-Fi points access. Do you really want to connect to a hotel access point whose SSID is typed in untranslatable gobbledygook? Or at the airport, where several open networks? When I'm somewhere in the outside world, I prefer to tunnel web traffic to my rooted android via home server. When I have my laptop in my hands, I open an ssh tunnel and redirect web traffic through socks5 so that all traffic coming to me is encrypted. I trust open WAPs only insofar as I can navigate through them. What else about plain text? I am tunneling SMTP traffic on my computer through my home server when in some places I see that outgoing SMTP is blocked. The situation is similar with POP3. Another example: you can manage X applications through a tunnel. You can wrap VNC sessions in a tunnel. One of the techniques that I started using earlier than others was reverse tunnels. In this case, you create a tunnel from a server that is located behind firewall. When you log into that SSH server, you can reestablish the connection.

Examples

Before looking at the client side, you need to do some things on the server side using editing configuration file sshd.config where I recommend making the following changes. Before making changes, copy the original config for safety in case something goes wrong.

If you made changes, you must restart the sshd server to apply them.

Let's move on to the command line switches.

A typical ssh tunnel (without X protocol tunneling) looks something like this:

As you might guess, the -X option tunnels X. Remember, however, that the command will tunnel your application from your remote machine to yours. client machine with Linux. If you are on Windows, just install Cygwin/X (http://x.cygwin.com/) on your guest car. I haven't tried this myself, but as I understand it should help launch remote X application in Windows.

When you go about establishing VNC sessions, you need to be careful. If a remote VNC server is running on port 5900, make sure you are not connecting to itself afterwards. The session itself is tunneled as in other cases using a transparent command:

And now you have it, a reverse tunnel.

For clarity, daddoo and nerdboy4200 from #linuxjournal joined forces and created Mscgen, a program that parses a sequence of messages and builds a visual diagram of message exchange for different protocols. It is, of course, open source and quite terrible to look at (http://www.mcternan.me.uk/mscgen/). For the case of a reversible tunnel, with the help of their product, they built a diagram (then the author inserted a diagram into his text, on which nothing is visible - approx. trans.).

Conclusion

So, what you can do with tunneling is limited only by your imagination, we've only given a few examples here. Perhaps in subsequent posts I will tell you how to properly configure SSH on the client side.

Posted by: admin October 17th, 2017

How SSH tunneling works

An SSH tunnel, or SSH Port Forwarding as man(1) ssh calls it, is an optional protocol functionality that runs on top of the familiar regular SSH session. An SSH tunnel allows you to send a TCP packet from one side of an SSH connection to the other side and broadcast the IP header according to a predetermined rule during the transmission process.

It is very simple to understand how an SSH tunnel works: if you imagine it as a point-to-point connection. Just like in PPP, any packet that hits one end of the connection will be sent and received at the other end of the tunnel. Further, depending on the recipient address specified in the IP header, the packet will either be processed by the receiving side of the tunnel (if the packet is intended directly for it), or routed further into the network (if the recipient is another network node).

The main difference between an SSH tunnel and a PPP connection is that only TCP traffic can be wrapped in an SSH tunnel. (Note: There are a few hacks to pass UDP over a TCP socket inside an SSH tunnel, but that solution is beyond the scope of this article.)

The second difference is that in a point-to-point connection incoming traffic can be initiated from any side, whereas for an SSH tunnel it is necessary to explicitly set the “entry point” for the traffic. “Entry point” is a parameter of the form<адрес>:<порт>, indicating which socket to open to enter the tunnel (from the local or remote side of the SSH session).

In addition to the entry point, you must additionally specify a rule of the form<адрес>:<порт>, according to which the header (more precisely, the address and destination port) of the TCP packet must be rewritten during transmission. The entry point can be set from either end of the tunnel. The keys –L (local) and –R (remote) are responsible for this parameter. By local and remote we mean the sides of the tunnel from the point of view of the originating side, that is, the host that establishes the SSH session.

It looks a little confusing so far, so let's look at it with a specific example.

Direct SSH tunnel - providing access to the server behind NAT

Alex works as a system administrator for a small apple pie company called Qwerty Cakes. The entire company’s network is located in one broadcast domain 192.168.0.0/24. Used to access the Internet software router based on Linux, the address of which is 192.168.0.1 on the company network side and 1.1.1.1 on the Internet side. The OpenSSD daemon is up and running on the router, which is accessible via socket 1.1.1.1:22. Inside the network, an internal corporate portal, on which Alex needs to make changes through tomorrow morning Web interface. However, Alex does not want to stay at work late, he wants to access the portal from home from his home computer with address 2.2.2.2.

Alex comes home and after dinner establishes the following connection to the company router:

What happened? Alex established an SSH session between addresses 2.2.2.2 and 1.1.1.1, while opening a local “entry point” to the tunnel 127.0.0.1:8080 on his home computer:

alex@Alex-PC:~$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LISTEN)

Any TCP packet that gets into socket 127.0.0.1:8080 from Alex’s computer will be sent over a point-to-point connection inside SSH sessions, in this case the destination address in the TCP header will be rewritten from 127.0.0.1 to 192.168.0.2, and the port from 8080 to 80.

Now, to get to his company’s portal, Alex only needs to type in the browser:

How do they go network packets inside an SSH tunnel

Let's take a closer look at what happened to the TCP packet as it passed through the SSH tunnel:

1. A TCP packet with source address 127.0.0.1 and destination address and port 127.0.0.1:8080 entered socket 127.0.0.1:8080, open by process ssh;

2. The ssh process received the packet, in accordance with the translation rule, rewrote the destination address and port to 192.168.0.2:80 and sent it within the SSH session to the remote party 1.1.1.1;

3. The sshd process on router 1.1.1.1 received the packet and, having looked at the destination address, sent it to host 192.168.0.2, while rewriting the source address from 127.0.0.1 to the address of its own interface 192.168.0.1, so that the recipient, who knows nothing about the existence of an SSH tunnel, returned the packet to the router, and did not send it to its own localhost 127.0.0.1.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [email protected]

IN in this example, if the portal or any other resource that Alex needs to access was located on the router itself (for example, at 192.168.0.1:80), then the command would look like this:

If the service is available at localhost (for example, a local SQL server), then you can access it:

alex@Alex-PC:~$ ssh -L

127.0.0.1:13306:127.0.0.1:3306 [email protected]

Constructions like -L 127.0.0.1:80:127.0.0.1:80 may look quite strange at first glance. But there is nothing complicated about them if you remember that the decision about packet routing is made on the remote side of the tunnel. You need to remember the basic rule: second pair<адрес>:<порт>processed by the remote side of the tunnel.

Therefore, a packet with a destination address of 127.0.0.1 in the translation rule will be processed by the second side of the SSH session, and nothing else.

As you probably already guessed, the tunnel entry point can be created not only on the loopback interface. If the tunnel needs to be made accessible not only to the local host, but also to other network participants, then you can specify real address interface.

alex@Alex-PC:~$ ssh -L

10.0.0.5:8080:192.0.0.2:80 [email protected]

Alex's computer Alex-PC has two network interface with addresses 2.2.2.2 and 10.0.0.5. During the session establishment process, ssh will open socket 10.0.0.5:8080 on the Alex-PC computer. Alex can now access portal 192.168.0.2:80 from his laptop with address 10.0.0.4 and all his home network 10.0.0.0/24.

Reverse SSH tunnel - expose your resources to the Internet

As I already said, the tunnel entry point can be opened not only from the side of the ssh session originator, but also from the remote side, that is, from the one to which we are establishing an ssh session. To do this, use the -R option instead of the -L option. What is it for?

For example, in order to be able to publish a local service for remote access.

Web is running on Alex's laptop apache server available at 127.0.0.1 with a test copy of the company portal. Alex needs to be given access to Web server to your colleagues to test the interface. In general, for such purposes, it would be nice for Alex to implement a more reliable testing sandbox. But since our Alex is nothing more than a virtual character in this article, to demonstrate the operation of the SSH tunnel, he establishes a session between his laptop and the Linux router. And using the -R parameter, opens port 8080 on the internal interface of the router with the address 192.168.0.1, which refers to socket 127.0.0.1:80 of its test Web server.

As you can see, on the router the sshd process opened local socket 8080

alex@Router:~$

sudo lsof -nPi | grep 8080

sshd

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (LISTEN)

Let's see what happens with a TCP packet sent from computer 192.168.0.200 towards a test portal published on 192.168.0.1:8080:

1. A TCP packet with a source address of 192.168.0.200 and a destination address and port of 192.168.0.1:8080 will end up on socket 192.168.0.1:8080, opened by the sshd process;

2. The sshd process, having received the packet, in accordance with the translation rule, will rewrite the destination address and port from 192.168.0.1:8080 to 127.0.0.1:80 and send it within the SSH session to the originating party 2.2.2.2;

3. The ssh process on Alex’s laptop, having received the packet and viewed its destination address, will rewrite the sender address from 192.168.0.200 to its loopback address, and send it to the local socket 127.0.0.1:80, opened by the apache process.

One important note, which I left for the end of the article.

If, when opening a tunnel entry point, localhost is used instead of the address of the real interface, then it can be omitted, thus shortening the command with

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protected]

before

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [email protected]

This important feature syntax will be useful to us in the following example.

Double tunneling

Let's look at a little more complex example. A SQL-Tester user located behind NAT needs to access the database on SQL server, which is also behind NAT. SQL-Tester cannot establish a connection directly to the server, since there are no corresponding translations in the NAT server network. However, from both hosts you can establish an SSH session with the intermediate server 3.3.3.3.

Install from SQL server SSH connection with server 3.3.3.3 and open port 13306 on the loopback interface of server 3.3.3.3, which refers to the local SQL service running on the local socket 127.0.0.1:3306 of the SQL server:

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306

[email protected]

Now, from the SQL-Tester client host, we establish a connection with 3.3.3.3 and open port 3306 on the client loopback interface, which, in turn, refers to 127.0.0.1:13306 on server 3.3.3.3, which... refers to 127.0.0.1:3306 on the SQL server. It's simple.

tester@SQL-Tester:~$ ssh -L

3306:127.0.0.1:13306 [email protected]

Dynamic tunnel - SSH as Socks proxy

Unlike tunnels with explicit indication of translation rules, a dynamic tunnel works on a completely different principle. Instead of specifying a one-to-one address:port mapping for each destination address and port, you open a socket on the local side of the SSH session, which turns your host into a SOCKS4/SOCKS5 proxy server. Let's take a look

Example:

Create a dynamic tunnel socket 127.0.0.1:5555 on the client host inside an SSH session to server 2.2.2.2

user@client:~$ ssh -D 5555 [email protected]

Checking that the port is open

user@client:~$ sudo lsof -nPi | grep 5555

7284 user 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LISTEN)

And we register the proxy in the settings of the browser or any other software that supports SOCKS proxy.

Now all browser traffic will go through the SOCKS proxy inside an encrypted SSH connection between hosts 1.1.1.1 and 2.2.2.2.

How to use SSH on Microsoft Windows?

After reading the article, you may decide that all the benefits of SSH tunnels are available only to users of Unix-like systems. However, it is not. Almost all terminal clients for Windows running over the SSH protocol have tunneling support.

For some time now, it has been possible to use Windows not only as SSH client. It is possible to install an SSH server on Windows.

When to use SSH tunnels?

Of course, to create permanent tunnels on combat servers you need to use a special software. But for quick solution tasks of port forwarding, troubleshooting, obtaining fast remote access and solutions in general specific task“here and now” the use of SSH tunnels is often a good help.

With their help, you can build entire networks, tunnels within tunnels, and combine types of tunnels. This can allow you to quickly gain access to places that would seem impossible to get to.

In addition to its main function, the SSH protocol provides the administrator with a lot of useful tools, in this article we will talk about creating VPN tunnel using SSH.
SSH tunneling- the simplest and quick way get a tunnel to the Linux server, because The OpenSSH package is most likely already installed on it, and the resulting tunnel will not have problems with NAT.

Such a tunnel is simple, but not reliable, because uses a TCP connection and does not contain built-in mechanisms for restoring a connection after a break.
SSH tunnel best used for testing(for example, if you need to transmit UDP packets to a remote server, port forwarding via SSH will not help in this case), and for permanent tunnels use protocols specially designed for this, such as OpenVPN, PPTP, L2TP, IPSec, GRE, etc. .d. (All command examples in the article are correct for CentOS 6)

Installation and configuration

Install the OpenSSH package from the repositories if it is not already installed:

yum install openssh openssh-server openssh-clients

In order for the server to allow the use of tunnels, you need to enable the PermitTunnel option in the OpenSSH server settings file (usually /etc/ssh/sshd_config) and restart the OpenSSH server (service sshd restart).

PermitTunnel yes

At the end of the server settings file there may be settings sections for specific hosts, users, user groups, etc.
Similar sections will begin with the lines

Host...
or
Match...

The PermitTunnel option must be added before the sections described.

Using SSH tunnels

For all examples, the OpenSSH server available at 192.168.1.100 will be used.

Simple SSH tunnel

To create the simplest SSH tunnel, you can run the command

sudo ssh -w 7:7 -l root 192.168.1.100

The option is responsible for creating a tunnel

W<номер_локального_интерфейса>:<номер_удалённого_интерфейса>

Instead of the local and/or remote interface number, you can use the value “any”, then the next unoccupied TUN interface will be created.

After passing sudo and SSH authentication on the local and remote hosts, a disabled tun7 interface should appear.

To use the tunnel, you need to enable the interfaces and configure them with IP addresses from the same subnet, for example, like this:

# on localhost
# on the remote host

Now the local host will have access to the remote host at 10.255.255.1 via an encrypted tunnel (provided that the firewalls of the local and remote hosts allow these connections).

The big disadvantage of this scheme is the need to access to a remote server via SSH with superuser rights (since superuser rights are required to create a TUN interface), while many system administrators prefer to deny root access via SSH for greater security. Elimination of this drawback is described in the next paragraph.

SSH tunnel with unprivileged user rights

In order to create an SSH tunnel with the rights of an unprivileged user, you must first create a TUN interface belonging to this user (to create a TUN interface, in any case, you will need superuser rights on the remote host).
To create a TUN interface in older Linux distributions The tunctl tool is used (must be available from the distribution repositories), in newer distributions this functionality is included in the iproute2 package. To determine how to create a TUN interface on your host, run the command

If the command gives an error

Object "tuntap" is unknown, try "ip help".

This means you need to use the tunctl tool, having previously installed it (yum install tunctl), otherwise the command should return a list of TUN/TAP interfaces on the host.

Let's move on to setup.

Create an unprivileged user on the remote host:

useradd ssh_tunnel

Create a TUN interface belonging to this user

Using tunctl:

tunctl -n -t tun7 -u ssh_tunnel -g ssh_tunnel

Using iproute2:

ip tuntap add dev tun7 mode tun user ssh_tunnel group ssh_tunnel

Connecting an SSH tunnel is similar to the previous example:

# on localhost
sudo ssh -w 7:7 -l ssh_tunnel 192.168.1.100
ifconfig tun7 up 10.255.255.2 pointopoint 10.255.255.1
# on the remote host
ifconfig tun7 up 10.255.255.1 pointopoint 10.255.255.2

Creating a user for SSH tunneling only

IN at this point Consideration will be given to preventing an unprivileged user from using the console while allowing SSH tunneling for that user. It will not work to set the shell “/bin/false” or “/sbin/nologin” for the user, because in this case, the user will not be able to establish an SSH connection at all.

To enter the described restrictions, you need to add the following lines to the end of the OpenSSH server settings file (/etc/ssh/sshd_config) and restart the OpenSSH server (service sshd restart)

Match User ssh_tunnel
X11Forwarding no
AllowTcpForwarding yes
AllowAgentForwarding no
GatewayPorts no
ForceCommand echo "This account can only be used for tunneling"; cat

The restriction in this example is imposed on the previously created user ssh_tunnel. The ForceCommand parameter causes the user to automatically execute the command “echo “This account can only be used for tunneling”; cat" immediately after connecting. This will prevent the user from using the console normally, because if the cat process is killed by pressing Ctrl+C, the SSH connection will be closed.

SSH-tunneling can help not only in matters where it is necessary to transmit unencrypted traffic over an encrypted connection, but also when you have no access to a resource on the network, but access is necessary.

Let's look at creating and setting up several options.

And so, we have a server, let's call it host-1. To him we have full access only by SSH- but we need to open Tomcat, operating on port 8082 - to which they cannot let us through.

We will consider the option with setting Windows And Putty.

Opening SSH-connection to to the desired server, let's log in.

We specify the following parameters:

Source port: any unused port on your system;
Destination port: 127.0.0.1:8082

Click Add, Then Apply.

Go to the browser settings and set the proxy parameters:

Now all that remains is to open the page http://localhost:3002 in the browser - and we get to the page Tomcat on server host-1.

If the tunnel is not working, check on the server whether packet forwarding is enabled. In the /etc/ssh/sshd_config file, find and uncomment the line:

AllowTcpForwarding yes

And restarting SSHd:

# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]

Another example - we have the same external server from which we have normal access to any resources on the Internet. But from the workplace we have access to and is closed.

We carry out similar actions, but with minor differences. Settings in Putty:

Source port - leave the same, but instead Local- choose Dynamic. Click Add, Apply.

Let's go to the browser settings:

Please note that the proxy type here is not HTTP, but SOCKS.

Enjoy access to your favorite sites.

And a more interesting case.

We have the same host-1. In addition to it, there is a second server, let’s call it host-2. In addition, we have a machine with Windows, which needs to be granted access to the resource TeamCity on server host-1 on port 8111. In this case, access from Windows-we only have machines for the server host-2, and only on port 22.

To begin with, we raise the tunnel between host-1 And host-2. We carry out on host-1:

$ ssh -f -N -R host-2:8082:localhost:8111 username@host-2

So we open a tunnel, which locally (on host-1) looks at port 8111, and on the other side is the machine host-2, on which port 8082 opens and waits for incoming connections. When receiving packets on port 8082 (and only via the lo0 interface! this is important) - it will redirect them to the machine host-1 port 8111.

Regarding the lo0 interface. When installed SSH-tunnel, even when specifying the external IP of the machine - the connection is raised only from localhost, i.e. 127.0.0.1 .

Let's look at host-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* LISTEN -

To change this, you need to edit the sshd daemon configuration file - /etc/ssh/sshd_config and change the parameter:

#GatewayPorts no

But we won't do that now, this is just a note.

Let's continue. Let's move on to setup Putty On our Windows-car. Everything is simple here - we use example 1 from this article, just change the port to the desired one (in the screenshot, by the way, it is there). Let's connect Putty to the host host-2, set up tunnel. Change settings in the browser proxy— and we get what we need, specify the address http://localhost:3002:

SSH is quite sensitive to packet loss, so tunnels can be dropped frequently.

To avoid this, you can either play with the parameters in the sshd settings file - /etc/ssh/sshd_config:

#TCPKeepAlive yes #ServerAliveInterval #ServerAliveCountMax

Or use the autossh utility.

From the editor of AnswIT:

In this example, if the portal or any other resource that Alex needed to access was located on the router itself (for example, at 192.168.0.1:80), then the command would look like this:

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protected]

If the service is available at localhost (for example, a local SQL server), then access to it
can be accessed:

alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [email protected]

Constructions like -L 127.0.0.1:80:127.0.0.1:80 may look quite strange at first glance. But there is nothing complicated about them if you remember that the decision
routing the packet is received on the remote side of the tunnel. You need to remember the basic rule: second pair
<адрес>:<порт>processed by the remote side of the tunnel.
Therefore, a packet with a destination address of 127.0.0.1 in the translation rule will be processed by the second side of the SSH session, and nothing else.

alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [email protected]

Alex's computer Alex-PC has two network interfaces with addresses 2.2.2.2 and 10.0.0.5. During the session establishment process, ssh will open socket 10.0.0.5:8080 on the Alex-PC computer. Now Alex can access the portal 192.168.0.2:80 from his laptop with the address 10.0.0.4 and from all
your home network 10.0.0.0/24.

Reverse SSH tunnel - expose your resources to the Internet

Apache Web server is running on Alex's laptop and is available
at 127.0.0.1 with a test copy of the company portal. Alex needs to give access to the Web server to his
colleagues to test the interface. In general, for such purposes, it would be nice for Alex to implement a more reliable testing sandbox. But since our Alex is nothing more than a virtual character in this article, he
demonstration of how the SSH tunnel works
session between your laptop and Linux router. And using the -R parameter opens port 8080 on
the internal interface of the router with the address 192.168.0.1, which refers to socket 127.0.0.1:80 of its test Web server.

As you can see, on the router the sshd process opened local socket 8080

alex@Router:~$
sudo lsof -nPi | grep 8080

sshd
17233 alex 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (LISTEN)

Let's see what happens with a TCP packet sent from computer 192.168.0.200 towards a test portal published on 192.168.0.1:8080:
1. A TCP packet with a source address of 192.168.0.200 and a destination address and port of 192.168.0.1:8080 will end up on socket 192.168.0.1:8080, opened by the sshd process;

As you can see, the broadcast rules are very simple. The host that opens the socket for the tunnel translates the destination address and port according to the translation rule. The host on the opposite side of the tunnel changes the source address and port according to its routing table. The routing table is necessary, firstly, in order to send the packet in the right direction, and, secondly, in order to produce
replacing the source address with the address of the interface from which the packet will be sent.
One important note that I left at the end of the article.
If, when opening a tunnel entry point, localhost is used instead of the address of the real interface, then it can be omitted, thus shortening the command with

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protected]

alex@Alex-PC:~ssh -L
8080:192.0.0.1:80 [email protected]

This important syntax feature will come in handy in the following example.

Double tunneling

Let's look at a slightly more complex example. A SQL-Tester user located behind NAT needs to access the database on a SQL server, which is also located behind NAT. SQL Tester cannot install
connection directly to the server, since there are no corresponding translations in the NAT server network. However, you can establish an SSH session from both hosts with an intermediate
server 3.3.3.3.

From the SQL server we establish an SSH connection to server 3.3.3.3 and open it on the server’s loopback interface
3.3.3.3 port 13306, referring to the local SQL service running on the local socket 127.0.0.1:3306 of the SQL server:

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306
[email protected]

Now, from the SQL-Tester client host, we establish a connection to 3.3.3.3 and open port 3306 on the loopback interface of the client, which, in turn, refers to 127.0.0.1:13306 on the server
3.3.3.3, which... refers to 127.0.0.1:3306 on the SQL server. It's simple J

tester@SQL-Tester:~$ ssh -L
3306:127.0.0.1:13306 [email protected]

Dynamic tunnel - SSH as Socks proxy

Unlike tunnels with explicit indication of translation rules, a dynamic tunnel works on a completely different principle. Instead of specifying a one-to-one address:port mapping for each destination address and port, you
open a socket on the local side of the SSH session, which turns your host into a proxy server running using the SOCKS4/SOCKS5 protocol. Let's take a look
example:

Create a dynamic tunnel socket 127.0.0.1:5555 on the client host inside an SSH session to server 2.2.2.2

user@client:~$ ssh -D 5555 [email protected]

Checking that the port is open

user@client:~$ sudo lsof -nPi | grep 5555

ssh
7284 user 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LISTEN)

And we register a proxy in the settings of the browser or any
other software that supports SOCKS proxies.

Now all browser traffic will go through a SOCKS proxy inside an encrypted SSH connection
between hosts 1.1.1.1 and 2.2.2.2.

How to use SSH on Microsoft Windows?

After reading the article, you may decide that all the benefits of SSH tunnels are available only
users of Unix-like systems. However, it is not. Almost everything for Windows that uses the SSH protocol has tunneling support.

For some time now, it has been possible to use Windows as more than just an SSH client. I have an opportunity .

When to use SSH tunnels?

Of course, to create permanent tunnels on combat servers you need to use special software. But to quickly solve the problem of port forwarding, troubleshooting, getting quick remote access, and generally solving a specific problem “here and now,” the use of SSH tunnels is often a good help.

With their help, you can build entire networks, tunnels within tunnels, and combine types of tunnels. This can allow you to quickly gain access to places that would seem impossible to get to.