SSH port forwarding

SSH port forwarding

Through the introduction in this article, you can learn how to apply the SSH port forwarding mechanism to solve some problems in daily work/life. Learn to use port forwarding in a non-secure environment to encrypt network applications and protect personal privacy and important business information. At the same time, this technology can also be used to solve some common problems in the work, such as some restrictions imposed by firewalls and network applications.

Overview

When you enjoy free WiFi in a cafe, do you think someone may be stealing your password and privacy information? When you find that the lab firewall has blocked your network application port, is it difficult? Let's see what benefits the SSH port forwarding function can bring to us!

Port forwarding Overview

Let's take a look at the concept of port forwarding. We know that SSH automatically encrypts and decrypts network data between all SSH clients and the server. However, SSH also provides a very useful function, which is port forwarding. It can forward network data of other TCP ports through SSH connections and automatically provides the corresponding encryption and decryption services. This process is sometimes called tunneling because SSH provides a secure channel for other TCP links for transmission. For example, TCP applications such as Telnet, SMTP, and LDAP can benefit from this, avoiding plaintext transmission of user names, passwords, and private information. At the same time, if the firewall in your work environment limits the use of some network ports, but allows SSH connections, you can also use SSH for communication by forwarding TCP ports. In general, SSH port forwarding provides two functions:

1. Encrypt the communication data between the SSH Client and the SSH Server.
2. Break through the limits of the firewall to complete some TCP connections that cannot be established before.

Figure 1. SSH port forwarding

As shown in, after port forwarding is used, TCP port A and port B do not communicate directly, but are forwarded to the SSH client and server for communication, in this way, data encryption is automatically implemented and firewall restrictions are bypassed at the same time.

Part 2 Local forwarding and remote forwarding instance analysis

Let's take a look at the first example. There is an LDAP Server (LdapServerHost) in the lab, but it limits that only applications deployed on the local machine can directly connect to this LDAP server. If we want to temporarily connect to the LDAP server from a remote machine (LdapClientHost) for debugging or testing, what method can we achieve?

The answer is undoubtedly local port forwarding. Its command format is:

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

Run the following command on LdapClientHost to create an SSH local port forwarding. For example:

$ ssh -L 7001:localhost:389 LdapServerHost

Figure 2. Local port forwarding

In this example, port 7001 is selected as the local listening port. When selecting the port number, note that non-administrator accounts do not have the permission to bind Port 1-1023, therefore, you can use an unused port number between 1024-65535.

Then, we can directly configure the applications on the remote machine (LdapClientHost) to port 7001 on the local machine (instead of port 389 on the LDAP server ). The subsequent data streams will look like the following:

• Our applications on LdapClientHost send data to port 7001 of the local machine,
• The local SSH Client encrypts the data received by port 7001 and forwards it to the SSH Server of LdapServertHost.
• The SSH Server decrypts the received data and forwards it to the listening LDAP 389 port,
• Finally, the original data returned from LDAP is returned to complete the entire process.

As we can see, the whole process is not directly connected to the LDAP server, but is connected to a local listening port, but SSH port forwarding completes all the remaining tasks, encryption, forwarding, decryption and communication.

Note the following points:

1. SSH port forwarding is established through an SSH connection. We must maintain this SSH connection for port forwarding to take effect. Once the connection is closed, the corresponding port forwarding is also closed.
2. We can only create port forwarding when creating an SSH connection, but cannot add port forwarding to an existing SSH connection.
3. You may wonder why the <remote host> localhost in the above command points to which machine? In this example, it points to LdapServertHost. Why do we use localhost instead of IP address or host name? In fact, this depends on how we used to restrict access to LDAP only from the local machine. If only the lookback interface is allowed, only localhost or IP address 127.0.0.1 can be accessed, rather than the real IP address or host name.
4. Must <remote host> and <SSH hostname> in the command be the same machine? Actually, they are not necessarily. They can be two different machines. We will elaborate on this in the following example.
5. Okay. We have already set up port forwarding on LdapClientHost. Can this port forwarding be used by other machines? For example, can I add 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 local port forwarding, the connection initiated by other machines will only get "connection refused. ". Fortunately, SSH also provides the GatewayPorts keyword. We can share this local port forwarding with other machines by specifying it.
   ssh -g -L <local port>:<remote host>:<remote port> <SSH hostname>

Remote forwarding instance analysis

Let's look at the second example. This time, we assume that we cannot use SSH to directly connect to the LDAP server (LdapServertHost) from LdapClientHost due to network or firewall reasons, but reverse connections are allowed. At this time, we naturally choose remote port forwarding.

Its command format is:

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

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

$ ssh -R 7001:localhost:389 LdapClientHost

Figure 3. Remote port forwarding

Compared with the local port forwarding, this time the hosts, SSH Server, and SSH Client locations are reversed, but the data streams are still the same. Our applications on LdapClientHost send data to port 7001 on the local machine, while the local SSH Server encrypts the data received by port 7001 and forwards it to the SSH Client of LdapServertHost. The SSH Client decrypts the received data and forwards it to the listening LDAP 389 port. Then, it returns the data returned from LDAP to complete the entire process.

Are you confused? Why is it local forwarding and sometimes remote forwarding? What is the difference between the two?

Comparison and Analysis of local and remote forwarding

Good. SSH Server, SSH Client, LdapServertHost, LdapClientHost, local forwarding, and remote forwarding are confusing. Let's analyze the structure. First, SSH port forwarding naturally requires SSH connections, while SSH connections are directed from the SSH Client to the SSH Server. Our applications are also oriented. For example, when we need to connect to the LDAP Server, the LDAP Server is the Server, and the application connection direction is also from the application Client to the application Server. If the two connections have the same direction, we will say that they are local forwarding. If the two directions are inconsistent, we will say that it is remote forwarding.

We can recall the two examples above for comparison.

Local forwarding:

LdapClientHost is both the application Client and the SSH Client. Both connections direct to LdapServertHost (both LDAP Server and SSH Server ).

Remote forwarding:

LdapClientHost is the application Client, but it is an SSH Server. LdapServertHost is the LDAP Server, but it is an SSH Client. In this way, the two connections are in the opposite direction.

Another easy-to-remember method is that the ports on the Server are predefined fixed ports (SSH Server port 22 and LDAP port 389 ), the Client ports are all dynamic ports available for us (for example, port 7001 selected in the preceding example ). If the two ports on the Server are on the same machine and the two ports on the Client are on the other machine, this is the local connection. If the four ports are distributed across the two machines, each machine has a Server port and a Client port, that is, remote connection.

After clarifying the differences between the two, let's take a look at the similarities between the two. In your environment, you can allow LdapClientHost to initiate an SSH connection to LdapServerHost or initiate an SSH connection to LdapClientHost. In this case, we can select local or remote forwarding to achieve the same function.

Next let's take a look at port forwarding in the advanced version. All the connections and forwards we have previously involved involve only two machines. Do you still remember the problem we mentioned in local forwarding? Can <remote host> and <SSH hostname> in the local 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

Run the following commands on the SSH Client (C) to establish an SSH connection and port forwarding:

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

Then Configure port 7001 of the Connection Machine (C) on our application client (. Note that the "-g" parameter is specified in the command to ensure that machine (A) can use the local port forwarding established by machine (C. In the preceding connection, the connections between (A) <-> (C) and (B) <-> (D) are not secure connections, they are not encrypted and decrypted through SSH. If the network between them is not a trusted network connection, we need to use this connection method with caution.

Part 3 Analysis of other types of forwarding dynamic instances

Well, dynamic forwarding sounds cool. When you see this, have you ever thought about local forwarding and remote forwarding, but the premise is that there is a fixed application server port number, for example, port 389 of the LDAP server in the preceding example. What should I do without this port number? Wait, what kind of application will not have this port number? Well, for example, using a browser for Web browsing, such as MSN.

When we access the Internet in an insecure WiFi environment, it is undoubtedly necessary to use SSH dynamic forwarding to protect our Webpage Browsing and MSN information. Let's take a look at the Command Format of dynamic forwarding:

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

For example:

$ ssh -D 7001 <SSH Server>

Figure 5. Dynamic port forwarding

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

-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-  nection 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 directly set it on the browser or MSN. Websites that cannot be accessed on the SSH Client can be browsed normally now. However, it is worth noting that the scope of SSH protection only covers connections from the browser (SSH Client) to the SSH Server, does not include connections from the SSH Server to the target website. If the security of the last half of the connection cannot be fully guaranteed, this method is still not a suitable solution.

Analysis of X protocol forwarding instances

Let's take a look at the last example-X protocol forwarding.

In our daily work, we may often remotely log on to Linux, Unix, Solaris, HP, and other machines for development or maintenance, and often need to run some programs in GUI mode, for example, a graphical interface is required to install DB2/WebSphere. At this time, there are usually two options for implementation: VNC or X Window. Let's take a look at the latter.

To use the X Window, you must install X Client and X Server respectively. In this example, X Client is the accessed remote Linux/Unix/Solaris/HP, our X Server is the local machine that initiates access (such as the laptop or desktop computer in front of you ). To display the X Window of X Client on X Server, you must first specify the position of X Server on X Client. The command format is as follows:

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

For example:

export DISPLAY=myDesktop:1.0

Then run the X application directly, and the X Window will automatically open on our local end.

Everything works normally, but the IT department suddenly adds a firewall in front of remote Linux/Unix/Solaris/HP. Unfortunately, the X protocol is not in the allowed list. What should I do? Can I only use VNC? No, in fact, you only need to use SSH port forwarding and encrypt the X communication data. (Of course, before using this method, IT is best to consult the relevant IT department to check whether IT complies with the relevant security regulations to avoid illegal operations .)

It is also easy to create a command. You can directly initiate an SSH connection from the Local Machine (X Server) as follows:

$ ssh -X <SSH Server>

Figure 5. X forwarding

After the connection is established, you can directly run the remote X application. Note that the DISPLAY environment variable will be automatically set after the X-forward is created, which is usually setlocalhost:10.0, We do not need or should not modify this environment variable after the connection.

A common scenario is that our local machine is a Windows operating system. In this case, we can select open-source XMing as our XServer, while the SSH Client can choose any one, such as PuTTY, cygwin can both configure access to SSH and create X forwarding.

Summary

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 forward TCP connections to the SSH channel to solve data encryption and break through firewall restrictions. For some applications with known port numbers, such as Telnet/LDAP/SMTP, we can use local port forwarding or remote port forwarding to achieve this goal. Dynamic port forwarding can implement SOCKS proxy to encrypt and break the firewall's restrictions on Web browsing. For X applications, X Forwarding is undoubtedly the most suitable. Although each part is just a brief introduction, if we can use these skills flexibly, we believe it will be helpful for our daily life/work.

References

• The "SSH authority Guide" (o'reilly book) provides a detailed introduction to SSH-related technical details and related skills.

You may also like the following SSH-related articles. For details, refer:

Complete SSH service configuration and troubleshooting in Ubuntu

How to install Samba and SSH server in Ubuntu 14.04

SSH service remote access to Linux Server login is slow

How to Improve the SSH login authentication speed of Ubuntu

Enable the SSH service to allow Android phones to remotely access Ubuntu 14.04

How to add dual authentication for SSH in Linux

Configure the SFTP environment for non-SSH users in Linux

Configure and manage the SSH service on Linux

This article permanently updates the link address: