SSH forwarding mechanism

The first part outlines

When you enjoy free Wi-Fi in a café, do you think someone might be stealing your password and private information? When you find that the firewall in your lab has blocked your network application port, is there a pain? Let's take a look at the port forwarding feature of SSH to give us some benefits!

Port Forwarding Overview

Let's first look at the concept of port forwarding. We know that SSH automatically encrypts and decrypts all network data between the SSH client and the server. However, SSH also provides a very useful feature, which is port forwarding. It can forward the network data of other TCP ports via SSH link, and provides the corresponding encryption and decryption service automatically. This process is sometimes referred to as a "tunnel" (tunneling), because SSH provides a secure channel for other TCP links to transmit and get its name. For example, TELNET,SMTP,LDAP can benefit from these TCP applications, avoiding the plaintext transmission of usernames, passwords, and private information. At the same time, if the firewall in your working environment restricts the use of some network ports, but allows SSH connections, it is also possible to communicate using SSH by forwarding the TCP port. In general, SSH Port forwarding can provide two main functions:

1. Encrypts the communication data between the SSH client side and the SSH Server side.
2. Break the firewall limit to complete some TCP connections that were not previously established.

Figure 1. SSH Port Forwarding

As shown, after using port forwarding, TCP port A and B are not communicating directly, but instead are forwarded to the SSH client and the server to communicate, thereby automatically implementing data encryption and bypassing the firewall restrictions.

Back to top of page

Part two local forwarding and remote forwarding local forwarding instance analysis

Let's take a look at the first example, there is an LDAP server (ldapserverhost) in the lab, but it restricts the applications deployed on this computer to connect directly to this LDAP server. If we want to temporarily connect to the LDAP server from the remote machine (ldapclienthost) because of debugging or testing, what are the methods to implement it?

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

Ssh-l <local port>:<remote host>:<remote port> <ssh hostname>

You can set up a local port forwarding for SSH by executing the following command on Ldapclienthost, for example:

$ ssh-l 7001:localhost:389 Ldapserverhost

Figure 2. Local Port forwarding

It is important to note that in this case we have selected 7001 port as the local listening port, when selecting the port number to note that the non-administrator account is not authorized to bind 1-1023 port, so generally choose a 1024-65535 and unused port number.

Then we can configure the application on the remote machine (ldapclienthost) directly to Port 7001 on this machine (not on port 389 of the LDAP server). The following data flow will look like this:

• Our app on Ldapclienthost sends data to the 7001 port on this machine,
• The native SSH Client encrypts the data received on port 7001 and forwards it to the ldapserverthost ssh Server.
• SSH Server decrypts the received data and forwards it to the listening LDAP 389 port.
• The data returned from the LDAP is returned to the original path to complete the process.

We can see that the entire process application is not directly connected to the LDAP server, but rather connected to a local listening port, but SSH port forwarding done all the rest, encryption, forwarding, decryption, communication.

Here are a few places to note:

1. SSH port forwarding is established via SSH connection, we must maintain this SSH connection so that port forwarding remains in effect. Once this connection is closed, the corresponding port forwarding is also turned off.
2. Instead of adding port forwarding to an existing SSH connection, we can only create port forwarding while establishing an SSH connection.
3. You may wonder why the <remote host> in the above command is using localhost, what machine does it point to? In this example, it points to ldapserverthost. Why do we use localhost instead of an IP address or a host name? In fact, this depends on how we previously restricted LDAP to only native access. If only allow Lookback interface access, then naturally only localhost or IP for 127.0.0.1 to access, and not with the real IP or host name.
4. Does the <remote host> and <ssh hostname> in the command have to be the same machine? In fact, they can be two different machines. We will elaborate on this in a later example.
5. Well, we've already set up port forwarding in ldapclienthost, so can this port forwarding be used by other machines? For example, can you add a new LdapClientHost2 to connect directly to the Ldapclienthost 7001 port? The answer is no, in the mainstream SSH implementation, the local port forwarding binding is the Lookback interface, which means only localhost or 127.0.0.1 to use the local port forwarding, other machine-initiated connections will only get "connection refused. ”。 Fortunately, SSH also provides the Gatewayports keyword, and 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 assuming that because of the network or firewall we cannot connect directly from Ldapclienthost to the LDAP server (ldapserverthost) with SSH, but the reverse connection is allowed. At this time our choice is naturally the 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) side:

$ ssh-r 7001:localhost:389 Ldapclienthost

Figure 3. Remote port forwarding

Compared to local port forwarding, the location of the SSH Server and ssh Client is reversed in this diagram, but the data flow is still the same. Our app on Ldapclienthost sends data to the 7001 port on this machine, and the native SSH Server encrypts the data received on port 7001 and forwards it to the ldapserverthost ssh Client. The SSH Client decrypts the received data and forwards it to the listening LDAP 389 port, and then returns the data source returned from the LDAP to complete the process.

See here, are you a little confused? Why is it called local forwarding, and sometimes it's called remote forwarding? What is the difference between the two?

Comparison and analysis of local forwarding and remote forwarding

Yes, SSH server,ssh client,ldapserverthost,ldapclienthost, local forwarding, remote forwarding, so many nouns are really easy to confuse. Let's analyze the structure of it. First, SSH port forwarding naturally requires an SSH connection, and the SSH connection is directed, from the SSH Client to the SSH Server. And our application is also in the direction, such as the need to connect to LDAP server, LDAP server is naturally the server side, we apply the connection direction is from the client side of the application to connect to the server side of the application. If the two connections are in the same direction, then we'll say it's local forwarding. And if the two directions are inconsistent, we say it is remote forwarding.

We can recall the above two examples to make a comparison.

When forwarding locally:

Ldapclienthost is also the client of the application, and SSH client, both of which point to the Ldapserverthost (both the LDAP server and SSH servers).

When forwarding remotely:

Ldapclienthost is the client of the application, but it is SSH Server, and Ldapserverthost is the server of LDAP, but it is the SSH client. So the two connections are in the opposite direction.

Another convenient way to remember is that the Server port is a predefined fixed port (port 389 of the SSH server Port 22,ldap), and the client port is dynamically available for our choice of ports (as in the above example, the 7001 port chosen). If the server side of the two ports are on the same machine, the client side of the two ports on another machine, then this is the local connection, if the four ports cross-distributed on two machines, each machine has a Server-side port, a client-side port, that is, remote connection.

After figuring out the difference between the two, take a look at the similarities. If you are in an environment that allows Ldapclienthost to initiate SSH connections to Ldapserverhost, it also allows Ldapserverhost to initiate an SSH connection to ldapclienthost. Then we choose to either local forwarding or remote forwarding is possible, can complete the same function.

Then let's take a look at the advanced version of Port forwarding. The various connections/forwards we've covered before have only involved two machines, remember the one we mentioned in the local forwarding? Can the <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 a case involving four machines (A,B,C,D).

Figure 4. Multi-Host forwarding applications

In SSH Client (C) Execute the following command to establish an SSH connection and port forwarding:

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

Then configure the 7001 port on the Connection Machine (C) on our application client (A). Note that we specify the "-G" parameter in the command to ensure that the machine (A) is able to use the local port forwarding established by machine (C). Another notable point is that, in the above connection, the connection between (A) <-> (C) and (B) <-> (D) is not a secure connection, and there is no SSH encryption or decryption between them. If the network between them is not a trustworthy network connection, we need to be cautious about using this connection method.

Back to top of page

Part III analysis of other types of forwarding dynamic forwarding instances

Well, dynamic forwarding, sounds cool. When you see this, have you ever thought that we have discussed local forwarding, remote forwarding, but the premise is to have a fixed application server port number, such as the previous example of the LDAP server port 389. What if I don't have this port number? Wait, what kind of application will not have this port number? Well, for example, Web browsing with a browser, such as MSN and so on.

When we surf the internet in an insecure WiFi environment, it is absolutely necessary to use SSH dynamic forwarding to protect our web browsing and MSN information. Let's take a look at the dynamic forwarding command format:

$ ssh-d <local port> <ssh server>

For example:

$ ssh-d 7001 <ssh server>

Figure 5. Dynamic port Forwarding

Seems very simple, we still choose 7001 as the local port number, in fact, here SSH is to create a SOCKS proxy service. Take a look at the description of the-d parameter in the Help documentation:

-D Port This  works by allocating a sockets to listen to port on  the local side, and whenever a connection are made T  o This port, the con-  nection are forwarded over the secure channel, and the applica-  tion protocol are then used to Determine where to connect to from the  remote machine.  Currently the SOCKS4 and SOCKS5 protocols  are supported, and SSH would act as a SOCKS server.  Only root  can forward privileged ports.  Dynamic Port forwardings can also is specified in the  configuration file.

After the use of the simple, we can use localhost:7001 directly as a normal SOCKS agent to use, directly in the browser or MSN settings. Sites that are inaccessible on the SSH client side can now be browsed as usual. What needs to be noted here is that the scope of the SSH cover only includes connections from the browser side (SSH Client) to the SSH server side, and does not include connections from the SSH server to the destination Web site. This approach is still not the right solution if the security of the rear-half connection is not adequately guaranteed.

X Protocol Forwarding Example analysis

OK, let's take a look at the last example-X protocol forwarding.

In our daily work, we may often telnet to linux/unix/solaris/hp and other machines to do some development or maintenance, and often need to run some programs in GUI mode, such as the requirement of graphical interface to install Db2/websphere and so on. There are usually two options to implement: VNC or X window, let's look at the latter.

Using the X window usually requires a separate installation: X Client and X Server. In this case our X Client is the remote LINUX/UNIX/SOLARIS/HP that we are accessing, and our X Server is the local machine that originated the visit (for example, the notebook or desktop you are using). The X client side X window will be displayed on the X server side need to first specify the X server location on the x client side, the command format is as follows:

Export display=<x Server ip>:<display #>.<virtual #>

For example:

Export display=mydesktop:1.0

Then run the X app directly, and the X window will automatically open on our local side.

Everything worked fine, but it suddenly added a firewall in front of the remote LINUX/UNIX/SOLARIS/HP. Unfortunately, the X protocol is not within the allowed list. What to do? Can you only use VNC? No, in fact, as long as the use of SSH port forwarding can pass, but also the X communication data encryption, really double benefit. (Of course, it is a good idea to consult the relevant IT Department for compliance with the appropriate security regulations before using this method to avoid offending operations.) ）

It is also very simple to create a command, directly from the local machine (X Server side) to initiate a following SSH connection:

$ ssh-x <ssh server>

Figure 5. X-Forwards

Once the connection is established, the remote X application can be run directly. Note that the DISPLAY environment variable is set automatically after the X-forwarding is established, and is usually set localhost:10.0 so that we do not need to and should not modify the environment variable after the connection.

A more common scenario is that our local machine is the Windows operating system, we can choose Open Source XMing as our xserver, and SSH Client can be arbitrarily selected, for example, Putty,cygwin can be configured to access SSH while creating X Forward.

Back to top of page

Part IV Summary

At this point, we have completed the introduction of local port forwarding, remote port forwarding, dynamic port forwarding, and X-forwarding. In retrospect, the general idea was to address the limitations of data encryption and firewall breaches by forwarding TCP connections to the SSH channel. For 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, it is no doubt that X-forwarding is the most suitable. Although each part of us is just a brief introduction, but if you can apply these skills flexibly, we believe that our daily life/work will also be helpful.

Ext.: http://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/

SSH forwarding mechanism