SSH port forwarding, local port forwarding, remote port forwarding, dynamic port forwarding details

Part 1 Overview of SSH Port Forwarding

When you are enjoying free WiFi in a cafe, have you ever thought that someone might be stealing your passwords and private information? When you find that the laboratory firewall blocks your network application port, do you feel miserable? Let's see what benefits SSH's port forwarding function can bring us!

SSH Port Forwarding Overview

Let us first understand the concept of port forwarding. We know that SSH will automatically encrypt and decrypt all network data between the SSH client and the server. However, SSH also provides a very useful function, which is port forwarding.

It can forward network data from other TCP ports through SSH links and automatically provide corresponding encryption and decryption services. This process is sometimes called "tunneling" because SSH provides a secure channel for other TCP links to transmit.

For example, TCP applications such as Telnet, SMTP, and LDAP can all benefit from it by avoiding the plain text transmission of usernames, passwords, and private information. At the same time, if the firewall in your work environment restricts the use of some network ports but allows SSH connections, you can also use SSH for communication by forwarding the TCP port.

In general, SSH port forwarding can provide two major functions:

Encrypt the communication data between SSH Client and SSH Server.

Break through the firewall restrictions and complete some TCP connections that could not be established before.

Figure 1. SSH port forwarding

As shown in the figure above, after using port forwarding, TCP ports A and B no longer communicate directly, but are forwarded to the SSH client and server for communication, thereby automatically achieving data encryption and bypassing firewall restrictions.

Part 2 SSH local port forwarding and remote port forwarding

SSH local port forwarding example analysis

Let's look at the first example. There is an LDAP server (LdapServerHost) in the laboratory, but it is restricted to applications deployed on the local computer that can directly connect to this LDAP server.

If we want to temporarily connect directly to this LDAP server from a remote machine (LdapClientHost) for debugging or testing purposes, is there any way to achieve this?

The answer is undoubtedly local port forwarding, its command format is:

ssh -L <local port>:<remote host>:<remote port> <SSH hostname>

Execute the following command on LdapClientHost to establish a local SSH port forwarding, for example:

$ ssh -L 7001:localhost:389 LdapServerHost


Figure 2. Local port forwarding

It should be noted that in this example we have selected port 7001 as the local listening port. When selecting the port number, please note that non-administrator accounts do not have the right to bind ports 1-1023, so generally choose a port number between 1024-65535 that has not been used.

Then we can configure the application on the remote machine (LdapClientHost) directly to port 7001 of the local machine (instead of port 389 of the LDAP server). The data flow will then look like this:

Our application on LdapClientHost sends data to port 7001 of the local machine.

The local SSH Client will encrypt the data received on port 7001 and forward it to the SSH Server of LdapServertHost.

SSH Server will decrypt the received data and forward it to the listening LDAP port 389.

Finally, the data returned from LDAP is returned back to complete the entire process.

We can see that the entire process application does not directly connect to the LDAP server, but connects to a local listening port, but SSH port forwarding is completed

All the rest is done: encryption, forwarding, decryption, and communication.

There are a few things to note here:

SSH port forwarding is established through an SSH connection, and we must maintain this SSH connection for port forwarding to take effect. Once this connection is closed, the corresponding port forwarding will also be closed.

We can only create port forwarding while establishing an SSH connection, but we cannot add port forwarding to an existing SSH connection.

You may wonder why <remote host> in the above command uses localhost. Which machine does it point to? In this case, it points to LdapServertHost. Why do we use localhost instead of an IP address or host name?

In fact, this depends on how we previously restricted LDAP to only be accessible by the local machine.

If only the lookback interface is allowed to access, then naturally only localhost or IP 127.0.0.1 can access it, and the real IP or host name cannot be used.

Do <remote host> and <SSH hostname> in the command have to be the same machine? In fact, it is not necessarily the case, they can be two different machines. We will explain this in more detail in the examples that follow.

OK, we have established port forwarding in LdapClientHost, but can this port forwarding be used by other machines? For example, can we add a new LdapClientHost2 to directly connect to port 7001 of LdapClientHost?

The answer is no. In mainstream SSH implementations, local port forwarding is bound to the lookback interface, which means that only localhost or 127.0.0.1 can use the local port forwarding.

Connections initiated from other machines will simply get "connection refused."

Fortunately, SSH also provides the GatewayPorts keyword, which we can specify to share this local port forwarding with other machines.

ssh -g -L <local port>:<remote host>:<remote port> <SSH hostname>


SSH remote port forwarding example analysis

Let's look at a second example, this time assuming that due to network or firewall reasons we cannot use SSH to connect directly from LdapClientHost to the LDAP server (LdapServertHost), but the reverse connection is allowed. Then our choice at this time is naturally remote port forwarding.

Its command format is:

ssh -R <local port>:<remote host>:<remote port> <SSH hostname>


For example, execute the following command on the LDAP server (LdapServertHost):

$ ssh -R 7001:localhost:389 LdapClientHost


Figure 3. Remote port forwarding

Compared with local port forwarding, in this diagram, the positions of SSH Server and SSH Client are swapped, but the data flow remains the same.

Our application on LdapClientHost sends data to port 7001 of the local machine, and the local SSH Server encrypts the data received on port 7001 and forwards it to the SSH Client of LdapServertHost.

SSH Client will decrypt the received data and forward it to the listening LDAP port 389, and finally return the data returned from LDAP to complete the whole process.

After reading this, are you a little confused? Why is it called local forwarding and sometimes called remote forwarding? What is the difference between the two?

Comparison and analysis of local SSH port forwarding and remote SSH port forwarding

Yes, SSH Server, SSH Client, LdapServertHost, LdapClientHost, local port forwarding, remote port forwarding,

So many nouns can indeed confuse people.

Let's analyze the structure.

First of all, SSH port forwarding naturally requires an SSH connection, and an SSH connection is directional, from the SSH Client to the SSH Server.

Our applications also have directions. For example, when we need to connect to an LDAP Server, the LDAP Server is naturally the server side, and the direction of our application connection is also from the client side of the application to the server side of the application.

If the directions of the two connections are the same, then we say it is a local forwarding. And if the two directions are inconsistent, we say it is remote port forwarding.

We can recall the two examples above for comparison.

When forwarding local ports:

LdapClientHost is both the client of the application and the SSH Client. Both connections point from it to LdapServertHost (both the LDAP server and the SSH Server).

When forwarding a remote port:

LdapClientHost is the client of the application, but it is an SSH Server; while LdapServertHost is the server of LDAP, but it is an SSH Client. This way the directions of the two connections are exactly opposite.

Another easy way to remember is

The ports on the server side are all predefined fixed ports (port 22 for SSH Server, port 389 for LDAP), while the ports on the client side are all dynamic ports that we can choose (such as port 7001 selected in the above example).

If both ports on the server side are on the same machine, and both ports on the client side are on another machine, then this is a local port connection;

If these four ports are cross-distributed on two machines, each machine has a server port and a client port, it is a remote port connection.

Now that we have figured out the difference between the two, let’s look at their similarities.

If your environment allows both LdapClientHost to initiate SSH connections to LdapServerHost and LdapServerHost to initiate SSH connections to LdapClientHost.

At this time, we can choose local forwarding or remote forwarding, which can achieve the same function.

Next, let's take a look at an advanced version of port forwarding.

The various connections/forwarding we have covered before only involved two machines. Remember the problem we mentioned in local forwarding?

Can <remote host> and <SSH hostname> in the local port forwarding command be different machines?

ssh -L <local port>:<remote host>:<remote port> <SSH hostname>

The answer is yes! Let's look at an example involving four machines (A,B,C,D).

Figure 4. Multi-host forwarding application

Execute the following commands in SSH Client(C) to establish SSH connection and port forwarding:

$ ssh -g -L 7001:<B>:389 <D>


Then configure the 7001 port of the connection machine (C) on our application client (A).

Note that we specified the "-g" parameter in the command to enable machine (A) to use the local port forwarding established by machine (C).

Another point worth noting is that in the above connections, the connections between (A) <-> (C) and (B) <-> (D) are not secure connections, and they are not encrypted or decrypted by SSH.

If the network between them is not a trustworthy one, we need to be cautious in using this connection method.

Part 3. Other Types of Port Forwarding

SSH dynamic port forwarding example analysis

Well, dynamic forwarding, sounds cool.

When you see this, have you ever thought that we have already discussed local forwarding and remote forwarding, but the premise is that there must be a fixed application server port number.

For example, the LDAP server port 389 in the previous example. What if there is no port number? etc,

What kind of application would not have this port number? Well, for example, using a browser to browse the Web, such as MSN and so on.

When we are surfing the Internet in an unsafe WiFi environment, it is undoubtedly necessary to use SSH dynamic forwarding to protect our web browsing and MSN information. Let's first look at the command format for dynamic forwarding:

$ ssh -D <local port> <SSH Server>


For example:

$ ssh -D 7001 <SSH Server>


Figure 5. Dynamic port forwarding

It seems simple. We still choose 7001 as the local port number. In fact, SSH creates a SOCKS proxy service here. Let's take a look at the description of the -D parameter in the help documentation:

-D port
This works by allocating a socket to listen to port on the local
side, and whenever a connection is made to this port, the con-
The connection is forwarded over the secure channel, and the applica-
tion protocol is then used to determine where to connect to from
the remote machine. Currently the SOCKS4 and SOCKS5 protocols
are supported, and ssh will act as a SOCKS server. Only root
can forward privileged ports. Dynamic port forwardings can also
be specified in the configuration file.

The subsequent use is simple. We can directly use localhost:7001 as a normal SOCKS proxy and set it directly on the browser or MSN.

Websites that were inaccessible on the SSH Client can now be browsed normally. It is worth noting that the scope of SSH protection at this time only includes the connection from the browser (SSH Client) to the SSH Server, and does not include the connection from the SSH Server to the target website.

If the security of the second half of the connection cannot be fully guaranteed, this approach is still not a suitable solution.

X protocol port forwarding example analysis

Ok, let's look at one last example - X protocol forwarding.

In our daily work, we may often remotely log in to Linux/Unix/Solaris/HP machines to do some development or maintenance. We also often need to run some programs in GUI mode, such as requiring a graphical interface to install DB2/WebSphere, etc.

There are usually two options for this: VNC or X windows, let's take a look at the latter.

Using X Window usually requires installing separately: X Client and X Server.

In this example, our X Client is the remote Linux/Unix/Solaris/HP being accessed, and our X Server is the local machine that initiates the access (such as the laptop or desktop you are using in front of you).

To display the X window of the X Client on the X Server, you need to specify the location of the X Server on the X Client first. The command format is as follows:

export DISPLAY=<X Server IP>:<display #>.<virtual #>


For example:

export DISPLAY=myDesktop:1.0


Then just run the X application, and the X window will automatically open on our local end.

Everything was running fine, but then the IT department suddenly added a firewall in front of the remote Linux/Unix/Solaris/HP.

Unfortunately, protocol X is not in the list of allowed protocols. what to do? Is VNC the only option? No, in fact, it can be done by using SSH port forwarding, and the X communication data is also encrypted at the same time, which is really killing two birds with one stone.

(Of course, before using this method, it is best to consult the relevant IT department to see if it complies with the corresponding security regulations to avoid illegal operations.)

It is also very simple to establish the command. Simply initiate an SSH connection from the local machine (X Server side) as follows:

$ ssh -X <SSH Server>


Figure 5. X forwarding

After the connection is established, you can run the remote X application directly. Note that after establishing X forwarding, the DISPLAY environment variable will be automatically set, usually to localhost:10.0. We do not need to and should not modify this environment variable after connecting.

A common scenario is that our local machine is a Windows operating system. In this case, we can choose the open source XMing as our XServer, and we can choose any SSH Client. For example, PuTTY and Cygwin can be configured to establish X forwarding while accessing SSH.

Part 4 Summary of SSH Port Forwarding

So far, we have completed the introduction of local port forwarding, remote port forwarding, dynamic port forwarding and X forwarding.

In retrospect, the general idea is to solve the data encryption and break through the various restrictions of the firewall by forwarding the TCP connection to the SSH channel.

For some applications with known port numbers, such as Telnet/LDAP/SMTP, we can use local port forwarding or remote port forwarding to achieve the purpose.

Dynamic port forwarding can implement SOCKS proxy to encrypt and break through firewall restrictions on web browsing.

For X applications, X forwarding is undoubtedly the most suitable. Although we have only briefly introduced each part,

But if we can apply these techniques flexibly, I believe it will be helpful in our daily life/work.

For more articles about SSH port forwarding, please click on the following related articles