(Source: Andranik Hakobyan/shutterstock.com)
The command-line tool secure shell (SSH) provides a secure communications channel between a client and a server. Engineers and operators often use SSH to remotely administer their devices and hosts. For example, it's common to use SSH to log into a Linux server to apply updates, install a new software package, or perform other administrative actions. A lesser-known feature of SSH is the ability to forward additional, but different network traffic over this same communications channel. For example, you can use SSH tunneling to encrypt and forward web requests to a remote host without exposing that host's web service on the network. You could also use SSH tunneling to create jump boxes and gateways that allow remote connections into your network without exposing additional network endpoints or ports.
The SSH local port forwarding feature allows you to create a tunnel between the client and server that encrypts all communications on a specified port between that client and server. Firewalls and other network tools generally will not be able to see inside these tunnels—they will only see the encrypted SSH (TCP port 22) traffic between the client and server (or gateway). As a security operator, you will want to detect and manage SSH usage in a manner consistent with your security policy. For example, some users might use SSH port forwarding to bypass your firewall if its rules block or filter HTTP and HTTPS but not block SSH.
Tunneling protocols over SSH is very quick and easy to set up and use. SSH implementations like OpenSSH can be centrally managed to provide authentication and encryption capabilities. For example, your organization might install a hardened SSH server on the internet that only listens on a single port running SSH. Users connect to this port, authenticate using a certificate, password, or other approved authentication method. Then they can either connect to resources on that server using SSH tunneling or get directed to their destination on the private network. But as useful as SSH tunneling can be, it does have limitations and it will not provide nearly the number of features of a dedicated virtual private network (VPN) device. SSH tunneling is useful in specific situations, like where a dedicated VPN solution might be overkill. For example, SSH tunneling can be useful for remotely connecting to your home devices.
You can configure SSH tunneling for local or remote port forwarding. Local port forwarding allows you to make a connection with a remote server and then forward specified network traffic from your client to that server or beyond.
Figure 1 shows a simple example of local port forwarding. In this example, a client connects to a firewall that forwards SSH connections to an SSH gateway that proxies communications with other internal servers and devices through SSH tunneling. You must configure the firewall to forward SSH network traffic to the device running SSH server software, also called an SSH daemon. In many cases, no other firewall rules are needed and there is no additional port forwarding required. Generally, the OpenSSH server software does not need any special configuration, either.
Figure 1: Simple configuration of SSH local port forwarding.
To connect to a remote server, the command looks like:
ssh -L 8080:remoteserver:80 username@FirewallExternalInterfaceIP
When you run this command on an internet-connected client, it will connect to the external IP address of the firewall (noted in the option above as FirewallExternalInterfaceIP) on SSH (by default TCP port 22), which forwards the SSH traffic to the SSH gateway. The SSH gateway authenticates the user (in our example, username) and establishes a secure, encrypted channel between the client and SSH gateway.
Behind the scenes. the SSH client is now silently listening for new connections on port 8080. To connect to the remote server, the client opens their web browser and connects to https://localhost:8080. This instructs the browser to connect to the client machine on port 8080, which is the endpoint that the SSH client application is listening for new connections. The SSH client software intercepts this call and sends it down the encrypted tunnel to the SSH gateway. The SSH gateway decrypts the communication and forwards it to the remote server on TCP port 80 (per the option remoteserver:80). The remote server thinks it is receiving a request from the SSH Gateway and responds to it. The gateway encrypts this response and sends it back to the client encapsulated in the SSH protocol (TCP 22).
Local port forwarding is not limited to web requests and browsers. As another example, here is the command to remotely connect to a windows server over the remote desktop protocol (RDP, TCP 3389).
ssh -L 1234:remoteserver:3389 username@FirewallExternalInterfaceIP
To make the connection, launch your RDP client and make a new RDP connection to localhost:1234. The ssh local port forwarding will activate and will result in a new RDP connection to the server specified as remoteserver.
Notice in this second example that the client only needs to run a separate ssh command to connect to a different server on a different application and there is no additional firewall or SSH gateway server configuration necessary.
Remote port forwarding is similar but in reverse. With remote port forwarding, your ssh client connects to a remote server and then connections by others to that remote server will be forwarded over the SSH tunnel back to your client. You might use remote port forwarding to make a website on your laptop visible to others on the internet without network reconfiguration.
These very simple examples describe how easy it is to use SSH tunneling but there are also nuances and caveats for more complex or specific implementations that you will want to understand for your specific implementation. Look to resource sites like https://ssh.com and others for more information.
SSH port forwarding is powerful, flexible, easy to set up, and perfect for certain situations that you need secure, remote access to a server or network.
Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop.
Privacy Centre |
Terms and Conditions
Copyright ©2022 Mouser Electronics, Inc.
Mouser® and Mouser Electronics® are trademarks of Mouser Electronics, Inc. in the U.S. and/or other countries.
All other trademarks are the property of their respective owners.
Corporate headquarters and logistics centre in Mansfield, Texas USA.