Shulou(Shulou.com)06/02 Report--

Part I Overview of SSH port forwarding

Did it ever occur to you that someone might be stealing your password and private information when you were enjoying free WiFi in a cafe? Is it hard to say when you find that the firewall in the lab is blocking your network application port? Let's see what benefits SSH's port forwarding function can bring to us.

Overview of SSH port forwarding

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 through SSH links, and automatically provides 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,LDAP can benefit from it, avoiding the transmission of user names, passwords and private information in clear text. 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 to communicate by forwarding TCP ports.

Generally speaking, SSH port forwarding can provide two major functions:

Encrypt the communication data between SSH Client and SSH Server.

Break through the restrictions of the firewall to 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 An and B now do not communicate directly, but are forwarded to SSH clients and servers for communication, thus automatically implementing data encryption and bypassing the restrictions of the firewall.

Part II SSH local port forwarding and remote port forwarding

Analysis of SSH Local Port forwarding example

Let's take a look at the first example. There is a LDAP server (LdapServerHost) in the lab, but it restricts that only applications deployed on the local machine 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, is there any way to do that?

There is no doubt that the answer is forwarded on the local port, and its command format is:

Ssh-L::

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

$ssh-L 7001:localhost:389 LdapServerHost

Figure 2. Local port forwarding

It should be noted that in this example, we select port 7001 as the local listening port. When selecting the port number, we should note that the non-administrator account does not have the right to bind port 1-1023. Therefore, it is generally possible to choose a port number between 1024 and 65535 that has not yet been used.

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

Our application on LdapClientHost sends data to port 7001 on this machine.

The local SSH Client encrypts the data received at port 7001 and forwards it to the SSH Server of LdapServertHost.

SSH Server decrypts the received data and forwards it to the listening LDAP port 389

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

We can see that the whole process application is not directly connected to the LDAP server, but to a local listening port, but the SSH port forwarding is completed.

Everything else, encryption, forwarding, decryption, communications.

Here are a few things to pay attention to:

SSH port forwarding is established through a SSH connection, and we must maintain this SSH connection for port forwarding to remain in effect. Once this connection is closed, the corresponding port forwarding is also closed.

We can only create port forwarding while establishing a SSH connection, not adding port forwarding to an existing SSH connection.

You may wonder why localhost is used in the above command, and which machine does it point to? In this case, it points to LdapServertHost. Why do we use localhost instead of IP address or hostname?

It really depends on how we previously restricted LDAP to native access.

If only the lookback interface is allowed, then naturally only localhost or IP of 127.0.0.1 can be accessed, instead of the real IP or hostname.

Must the and in the command be the same machine? In fact, it is not necessarily, they can be two different machines. We will elaborate on this point in later examples.

OK, we have established port forwarding in LdapClientHost, so can this port forwarding be used by other machines? For example, can I add a new LdapClientHost2 to connect directly 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 native port forwarding.

Connections initiated by other machines will only get "connection refused."

Fortunately, SSH also provides the GatewayPorts keyword, which we can forward by specifying it to share this local port with other machines.

Ssh-g-L::

Analysis of SSH remote Port forwarding example

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

Its command format is:

Ssh-R::

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 locations of SSH Server and SSH Client are switched this time, but the data flow is still the same.

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

SSH Client decrypts the received data and forwards it to the listening LDAP port 389. finally, it returns the data returned from LDAP to complete the whole process.

Don't you get a little confused when you see this? Why is it called local forwarding and sometimes remote forwarding? What's the difference between the two?

Comparison and Analysis of Local SSH Port forwarding and SSH remote Port forwarding

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

It's really confusing to have so many nouns.

Let's analyze the structure.

First of all, SSH port forwarding naturally requires SSH connections, while SSH connections are directional, from SSH Client to SSH Server.

Our application also has a direction. For example, when we need to connect to LDAP Server, LDAP Server is naturally the Server end, and the direction of our application connection is to connect from the Client side of the application to the Server side of the application.

If the two connections are in the same direction, then we say it is forwarded locally. If the two directions are not the same, we say it is remote port forwarding.

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

When forwarding the local port:

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

When forwarding a remote port:

LdapClientHost is the client of the application, but it is SSH Server, while LdapServertHost is the server of LDAP, but it is SSH Client. So the two connections are in the opposite direction.

Another convenient way to remember is

The ports on the Server side are predefined fixed ports (SSH Server port 22 is LDAP port 389), while the ports on the Client side are dynamically available ports for us to choose from (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 the other machine, then this is the local port connection

If these four ports are distributed across two machines, each machine has one Server end port and one Client end port, that is the remote port connection.

After figuring out the difference between the two, let's look at the similarities between the two.

If you are in an environment that allows both LdapClientHost to initiate SSH to connect to LdapServerHost and LdapServerHost to initiate SSH to connect to LdapClientHost.

At this time, we can choose either local forwarding or remote forwarding, and we can complete the same function.

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

The various connections / retweets we've covered before involve only two machines. Do you remember a problem we mentioned in local forwarding?

Can the and in the local port forwarding command be different machines?

Ssh-L::

The answer is yes! Let's take a look at an example that involves four machines (An and B, C, D).

Figure 4. Multi-host forwarding application

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

$ssh-g-L 7001RV 389

Then configure port 7001 to connect to the machine (C) on our application client (A).

Notice that we specify the "- g" parameter in the command to ensure that machine (A) can forward using the local port established by machine (C).

It is also worth noting that in the above connection, the connection between (A) (C) and (B) (D) is not a secure connection, and they are not encrypted and decrypted by SSH.

If the network between them is not a reliable network connection, we need to use this connection carefully.

Part III other types of port forwarding

Analysis of SSH dynamic Port forwarding example

Yeah, dynamic retweet, it sounds cool.

When you see this, have you ever thought that we have talked about local forwarding and remote forwarding, but only if a fixed port number of the application server is required?

For example, port 389 on the LDAP server in the previous example. What if I don't have this port number? Wait,

What kind of application doesn't have this port number? Well, for example, use a browser for Web browsing, such as MSN and so on.

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

$ssh-D

For example:

$ssh-D 7001

Figure 5. Dynamic port forwarding

It seems simple that we still choose 7001 as the local port number, but here SSH creates 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 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.

After that, it is easy to use localhost:7001 as a normal SOCKS proxy, and you can set it directly on the browser or MSN.

Websites that cannot be accessed on the SSH Client side can now be browsed normally. It should be noted that at this time, SSH covers only the connection from the browser side (SSH Client side) to the SSH Server side, not the connection from the SSH Server side to the target website.

If the security of the second half of the connection is not fully guaranteed, this approach is still not an appropriate solution.

Analysis of Port forwarding example of X Protocol

All right, let's look at the last example-X protocol forwarding.

In our daily work, we may often log in remotely to machines such as Linux/Unix/Solaris/HP to do some development or maintenance, and we often need to run some programs in the way of GUI, such as requiring a graphical interface to install DB2/WebSphere and so on.

At this point, there are usually two options: VNC or X window, let's take a look at the latter.

Using X window usually requires installation of X Client and X Server respectively.

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

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

Export DISPLAY=:.

For example:

Export DISPLAY=myDesktop:1.0

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

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

Unfortunately, the X protocol is not on the allowed list. What shall I do? Can only use VNC? No, in fact, as long as you use the SSH port to forward, you can also encrypt the X communication data, which is really killing two birds with one stone.

(of course, before using this method, it is best to consult the relevant IT departments to see if they comply with the relevant safety regulations to avoid illegal operations. )

The establishment command is also very simple. You can initiate the following SSH connection directly from the local machine (X Server side):

$ssh-X

Figure 5. X forwarding

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

A common scenario is that our local machine is Windows operating system, and we can choose open source XMing as our XServer, while SSH Client can choose at will. For example, PuTTY,Cygwin can be configured to access SSH and establish X forwarding at the same time.

Part IV: 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 address data encryption and break through firewall restrictions by forwarding TCP connections to SSH channels.

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.

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

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

However, if we can apply these skills flexibly, I believe it will also be helpful to our daily life / work.

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

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.