ssh tunnel safari

How to Setup SSH Tunneling in Mac OS (or Ubuntu)

If you want to set up an SSH tunnel with your remote server using your Macbook, you can easily do so using the default Terminal application available in the Mac OS. Yes, we do not have to install any other application to do so, as we do in Windows.

You can easily setup SSH on Mac without doing any extra work. If you are a Windows user, I would recommend using the Mobaxterm application for doing this. So let's get started!

What is SSH Tunneling in Mac?

An SSH tunnel or SSH port forwarding is a mechanism to establish a secure connection between a client machine and a server.

Let's take a simple example to understand this. If we have a database server, let's say MySQL is running on a remote server with some IP address XXX.XXX.XXX.XXX and for which the port number 3306 which is the default port for MySQL is only available on the local network of the remote server.

In this case, if you want to access the DB server from your local machine(connected to the internet), you won't be able to do it. In such a scenario, we set up an SSH tunnel with the remote server, to securely connect to the local network of the remote server to access the 3306 port on the remote server.

Let's take another example If we are using AWS service and we have two servers one is a DB server and another is the SSH server on which the Web Server is running. On the SSH server, because we are running the Web server, port 80 would be open to all, because then only the website or the web application hosted on that server will be available to its users. But, for security, the DB server is never exposed to the internet and is kept on the local network, which will be accessible via the SSH server, as the SSH server is on the same local network.

Now, if you want to check something or do something on the DB server. or want to connect your local SQL client with the remote database, you won't be able to do it directly. But because the DB server is accessible via the SSH server, we can set up an SSH tunnel with the SSH server to reach the DB server.

I hope the two examples are clear, and now you know, why SSH tunneling is needed. So let's see how we can do this.

Using MacOS/Ubuntu Terminal

We can use the ssh command to set up an SSH tunnel with a remote server, considering the SSH port which is port number 22 is open for the remote server.

• If our remote server name is my-remote-server.host and the SSH user is st-user , and on the same server a DB service let's say MySQL is installed which is accessible via localhost:3306 on the remote server.

• Then to connect to the DB server, we can run the following command to setup an SSH tunnel:
• Here, 8888 : This is the local port that we will open for the SSH tunnel on the local machine. Here you can give any port number after 1024 , because until 1024 port number, all ports are privileged ports.
• 127.0.0.1 : This is the IP for the localhost running on the remote server, this is also the destination we aim to reach via the SSH server.
• 3306 : This is the destination port, assigned to the MySQL server on the remote SSH server.
• and then [email protected] is the username and the IP address/URI for the SSH server.

Once you do this, you will be prompted to enter the password for the user st-user , so enter the password and hit Enter, and the SSH tunnel will be created. Now, you will be able to access the MySQL server using 127.0.0.1:8888 address from your local machine.

Using a .pem file

If your remote server is an EC2 instance on AWS and you have a .pem file as the SSH key, run the following command for the above scenario:

In this case, you will not be asked for the password, as authentication will be done using your SSH key.

This was the scenario where the DB server was running on the localhost of the remote server. Next, let's see how to connect to a separate DB server via a remote server.

Connect to Destination server via Remote Server:

If our DB server is my-db-server.host on which port 3306 is available for connection on the private network access to the remote SSH server my-remote-server.host , as shown in the picture below.

Then we can run the following command:

Note: If SSH connection is enabled on a different port other than port number 22, then we can specify the port number in the above command using -p [PORT_NUMBER] argument. So, for example, we have 2200 port for SSH enabled on our remote server, then the command would be:

Conclusion:

I hope this article helped you in understanding what SSH tunneling is and how we can set up an SSH tunnel using the Terminal in MacOS and in Ubuntu or other Linux-based operating systems. If you were not able to do this or faced any issues running the above command, do share in the comments below and we will help you out.

Frequently Asked Questions(FAQs)

1. what exactly is ssh tunneling, and why would you want to use it.

SSH Tunneling is a network security method that creates an encrypted conduit between two devices over an insecure network, such as the Internet. It can be used to protect distant connections, gain access to limited resources, and circumvent firewalls and other security measures.

2. How does SSH Tunneling work in Mac OS (or Ubuntu)?

In Mac OS (or Ubuntu), use the "ssh" command with the "-L" option to select the local port and destination, and the "-N" mark to execute the SSH connection in the background. For example, the command "ssh -L 8080:localhost:80 [email protected] -N" would establish an SSH tunnel from port 8080 on your local computer to port 8080 on the distant machine.

3. What are some of the benefits of using SSH Tunneling?

By encrypting network data, SSH Tunneling adds an extra layer of security, making it more difficult for intruders to eavesdrop or take private information. It also enables you to gain access to resources that are limited or inaccessible via your local networks, such as distant servers or databases.

4. What are some SSH Tunneling recommended practices?

It is critical to correctly protect your SSH keys and passwords when using SSH Tunneling and limit access to your local and distant computers. You should also watch your network data and SSH logs for any suspicious behavior on a frequent basis, and keep your software and security measures up to current to avoid vulnerabilities.

You may also like:

• Ubuntu vs Debian: Comparison Between Ubuntu and Debian
• How To Monitor CPU and GPU temperatures in Ubuntu Linux
• How to check your Ubuntu Version?
• Ubuntu vs Linux Mint Operating System

IF YOU LIKE IT, THEN SHARE IT

Related posts.

New to EOAS Help Desk? Register for an account

How to ssh tunnel a connection using macos - knowledgebase / mac osx - eoas help desk.

• Download PDF

Copy to Clipboard

How to ssh tunnel a connection using macos.

• Last updated: Dec 18, 2017 by Burner EOAS

Tunneling over SSH provides a means where a local computer can open one or more connections over a secure encrypted channel to a remote computer system located somewhere else and from the remote computer a connection can be opened to another location. This process can be used to secure network traffic, bypass restrictions placed on a local network firewall, or establish a secure path into a private network that sits behind a firewall.

These instructions are specific to MacOS. In this knowledge base article, the remote server is a Linux system running Ubuntu Linux, however the same steps should work for a variety of *nix based systems.

An SSH tunnel must be specified at the localhost based on a particular protocol. In general, the best solution is to identify the application you want to tunnel, and use corresponding ports that exist above the priviledged ports range (https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html).

The example below is specific to the Chrome and Safari web browser. Additional settings and clients can be requested by submitting a new ticket or positing comments to this article.

• SSH tunnelling is not a soluton that provides a fast connection. Network congestion and the process of encrypting and decrypting the connection (usually in software), will slow down the access speed.
• Some instructions, such as those specific to Safari, will remain in effect until disabled, i.e., the SSH tunnel will remain in effect until you undo the settings for the SSH tunnel.

Launch an SSH tunnel

To begin, you must initiate an SSH tunnel. Open the MacOS Terminal and connect to your remote server via SSH with the following flags:

ssh -D 8080 -N [email protected]

This will open port 8080 on your local system so any traffic to 8080 will be securely tunneled through to server remote computer at remotecomputer.eoas.ubc.ca .

Configure the Chrome web browser

The Chrome web browser from Google can leverage the local proxy as a socks5 proxy. To open a secure web browser, use the following command:

chrome --proxy-server="socks5://127.0.0.1:8080" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost"

The new Chrome browser will direct browsing traffice through the encrypted tunnel to the remote computer system where it will access the Internet.

Configure the Safari web browser

Go to System Preferences » Network » Advanced » Proxies , and update your settings to reflect the settings in the screenshot below.

46 of 92 people found this page helpful

How-To Geek

How to use ssh tunneling to access restricted servers and browse securely.

An SSH client connects to a Secure Shell server, which allows you to run terminal commands as if you were sitting in front of another computer.

Quick Links

Local port forwarding: make remote resources accessible on your local system, remote port forwarding: make local resources accessible on a remote system, dynamic port forwarding: use your ssh server as a proxy.

An SSH client connects to a Secure Shell server , which allows you to run terminal commands as if you were sitting in front of another computer. But an SSH client also allows you to "tunnel" a port between your local system and a remote SSH server.

There are three different types of SSH tunneling, and they're all used for different purposes. Each involves using an SSH server to redirect traffic from one network port to another. The traffic is sent over the encrypted SSH connection, so it can't be monitored or modified in transit.

You can do this with the ssh command included on Linux, macOS, and other UNIX-like operating systems, and you can create an ssh config file to save your settings . On Windows, which doesn't include a built-in ssh command, we recommend the free tool  PuTTY  to connect to SSH servers. It supports SSH tunneling, too.

"Local port forwarding" allows you to access local network resources that aren't exposed to the Internet. For example, let's say you want to access a database server at your office from your home. For security reasons, that database server is only configured to accept connections from the local office network. But if you have access to an SSH server at the office, and that SSH server allows connections from outside the office network, then you can connect to that SSH server from home and access the database server as if you were in the office. This is often the case, as it's easier to secure a single SSH server against attacks than to secure a variety of different network resources.

To do this, you establish an SSH connection with the SSH server and tell the client to forward traffic from a specific port from your local PC---for example, port 1234---to the address of the database's server and its port on the office network. So, when you attempt to access the database server at port 1234 your current PC, "localhost", that traffic is automatically "tunneled" over the SSH connection and sent to the database server. The SSH server sits in the middle, forwarding traffic back and forth. You can use any command line or graphical tool to access the database server as if it was running on your local PC.

To use local forwarding, connect to the SSH server normally, but also supply the

argument. The syntax is:

ssh -L local_port:remote_address:remote_port [email protected]

For example, let's say the database server at your office is located at 192.168.1.111 on the office network. You have access to the office's SSH server at ssh.youroffice.com , and your user account on the SSH server is bob . In that case, your command would look like this:

ssh -L 8888:192.168.1.111:1234 [email protected]

After running that command, you'd be able to access the database server at port 8888 at localhost. So, if the database server offered web access, you could plug http://localhost:8888 into your web browser to access it. If you had a command line tool that needs the network address of a database, you'd point it at localhost:8888. All traffic sent to port 8888 on your PC will be tunneled to 192.168.1.111:1234 on your office network.

It's a little more confusing if you want to connect to a server application running on the same system as the SSH server itself. For example, let's say you have an SSH server running at port 22 on your office computer, but you also have a database server running at port 1234 on the same system at the same address. You want to access the database server from home, but the system is only accepting SSH connections on port 22 and its firewall doesn't allow any other external connections.

In this case, you could run a command like the following one:

ssh -L 8888:localhost:1234 [email protected]

When you attempt to access the database server at port 8888 on your current PC, the traffic will be sent over the SSH connection. When it arrives on the system running the SSH server, the SSH server will send it to port 1234 on "localhost", which is the same PC running the SSH server itself. So the "localhost" in the command above means "localhost" from the perspective of the remote server.

To do this in the PuTTY application on Windows, select Connection > SSH > Tunnels. Select the "Local" option. For "Source Port", enter the local port. For "Destination", enter the destination address and port in the form remote_address:remote_port.

For example, if you wanted to set up the same SSH tunnel as above, you'd enter 8888 as the source port and localhost:1234 as the destination. Click "Add" afterwards and then click "Open" to open the SSH connection. You will also need to enter the address and port of the SSH server itself on the main "Session" screen before connecting, of course.

"Remote port forwarding" is the opposite of local forwarding, and isn't used as frequently. It allows you to make a resource on your local PC available on the SSH server. For example, let's say you're running a web server on the local PC you're sitting in front of. But your PC is behind a firewall that doesn't allow incoming traffic to the server software.

Assuming you can access a remote SSH server, you can connect to that SSH server and use remote port forwarding. Your SSH client will tell the server to forward a specific port---say, port 1234---on the SSH server to a specific address and port on your current PC or local network. When someone accesses the port 1234 on the SSH server, that traffic will automatically be "tunneled" over the SSH connection. Anyone with access to the SSH server will be able to access the web server running on your PC. This is effectively a way to tunnel through firewalls.

To use remote forwarding, use the ssh command with the -R argument. The syntax is largely the same as with local forwarding:

ssh -R remote_port:local_address:local_port [email protected]

Let's say you want to make a server application listening at port 1234 on your local PC available at port 8888 on the remote SSH server. The SSH server's address is ssh.youroffice.com and your username on the SSH server is bob. You'd run the following command:

ssh -R 8888:localhost:1234 [email protected]

Someone could then connect to the SSH server at port 8888 and that connection would be tunneled to the server application running at port 1234 on the local PC you established the connection from.

To do this in PuTTY on Windows, select Connection > SSH > Tunnels. Select the "Remote" option. For "Source Port", enter the remote port. For "Destination", enter the destination address and port in the form local_address:local_port.

For example, if you wanted to set up the example above, you'd enter 8888 as the source port and localhost:1234 as the destination. Click "Add" afterwards and then click "Open" to open the SSH connection. You will also need to enter the address and port of the SSH server itself on the main "Session" screen before connecting, of course.

People could then connect to port 8888 on the SSH server and their traffic would be tunneled to port 1234 on your local system.

By default, the remote SSH server will only listen to connections from the same host. In other words, only people on the same system as the SSH server itself will be able to connect. This is for security reasons. You'll need to enable the "GatewayPorts" option in sshd_config on the remote SSH server if you want to override this behavior.

Related: What's the Difference Between a VPN and a Proxy?

There's also "dynamic port forwarding", which works similarly to a proxy or VPN. The SSH client will create a SOCKS proxy you can configure applications to use. All the traffic sent through the proxy would be sent through the SSH server. This is similar to local forwarding---it takes local traffic sent to a specific port on your PC and sends it over the SSH connection to a remote location.

Related: Why Using a Public Wi-Fi Network Can Be Dangerous, Even When Accessing Encrypted Websites

For example, let's say you're using a public Wi-Fi network. You want to browse securely without being snooped on . If you have access to an SSH server at home, you could connect to it and use dynamic port forwarding. The SSH client will create a SOCKS proxy on your PC. All traffic sent to that proxy will be sent over the SSH server connection. No one monitoring the public Wi-Fi network will be able to monitor your browsing or censor the websites you can access. From the perspective of any websites you visit, it will be as if you were sitting in front of your PC at home. This also means you could use this trick to access US-only websites while outside of the USA---assuming you have access to an SSH server in the USA, of course.

As an another example, you may want to access a media server application you have on your home network. For security reasons, you may only have an SSH server exposed to the Internet. You don't allow incoming connections from the Internet to your media server application. You could set up dynamic port forwarding, configure a web browser to use the SOCKS proxy, and then access servers running on your home network through the web browser as if you were sitting in front of your SSH system at home. For example, if your media server is located at port 192.168.1.123 on your home network, you could plug the address 192.168.1.123 into any application using the SOCKS proxy and you'd access the media server as if you were on your home network.

To use dynamic forwarding, run the ssh command with the -D argument, like so:

ssh -D local_port [email protected]

For example, let's say you have access to an SSH server at ssh.yourhome.com and your username on the SSH server is bob . You want to use dynamic forwarding to open a SOCKS proxy at port 8888 on the current PC. You'd run the following command:

ssh -D 8888 [email protected]

You could then configure a web browser or another application to use your local IP address (127.0.01) and port 8888. All traffic from that application would be redirected through the tunnel.

To do this in PuTTY on Windows, select Connection > SSH > Tunnels. Select the "Dynamic" option. For "Source Port", enter the local port.

For example, if you wanted to create a SOCKS proxy on port 8888, you'd enter 8888 as the source port. Click "Add" afterwards and then click "Open" to open the SSH connection. You will also need to enter the address and port of the SSH server itself on the main "Session" screen before connecting, of course.

You could then configure an application to access the SOCKS proxy on your local PC (that is, IP address 127.0.0.1, which points to your local PC) and specify the correct port.

Related: How to Configure a Proxy Server in Firefox

For example, you can configure Firefox to use the SOCKS proxy . This is particularly useful because Firefox can have its own proxy settings and doesn't have to use system-wide proxy settings. Firefox will send its traffic through the SSH tunnel, while other applications will use your Internet connection normally.

When doing this in Firefox, select "Manual proxy configuration", enter "127.0.0.1" into the SOCKS host box, and enter the dynamic port into the "Port" box. Leave the HTTP Proxy, SSL Proxy, and FTP Proxy boxes empty.

The tunnel will remain active and open for as long as you have the SSH session connection open. When you end your SSH session and disconnect from a server, the tunnel will also be closed. Just reconnect with the appropriate command (or the appropriate options in PuTTY) to reopen the tunnel.

RELATED:   Best Linux Laptops for Developers and Enthusiasts

This content cannot be displayed without JavaScript. Please enable JavaScript and reload the page.

• HostDime Knowledge Base

Browsing the Internet Through an SSH Tunnel on MacOS

VPNs  are powerful tools and can help keep your network traffic secure. If you have a VPS or dedicated server, you could even run a VPN service from your server. The issue is that setting up and configuring a VPN can be time consuming and complicated. For some uses, there may be an easier way to securely route your traffic through a remote server (like your VPS or dedicated server).

An  SSH tunnel  is another method of rerouting some or all traffic from one location (like your local computer) through another (your remote server). All of this rerouted traffic is securely encrypted as it travels between your local machine and the remote server thanks to SSH. With a tunnel active and traffic proxied through the tunnel, that traffic will appear to be coming from your remote server instead of your local machine. This can be useful to bypass remote network issues or restrictive firewalls.

This article will explain how you can set up an SSH tunnel from your local MacOS (née OS X) machine.

If you are looking for an article explaining how to set up an SSH tunnel on your Windows machine, see our article here .

Requirements

The Mac already ships with all of the tools needed to set up an SSH tunnel, but you'll also need a remote server to SSH your connection through. Here’s the full list of requirements:

• A remote server running SSH and the ability to make other outbound connections to the internet.
• A user account on the remote server that is able to log in via SSH.
• Access to the Terminal  application in  /Applications/Utilities/Terminal(.app)  on your Mac.
• Access to the Network  section in System Preferences  so you can set up the system-wide proxy.
• Alternately, access to Firefox or another browser that can accept locally configured proxy connections.

Setting up an SSH Tunnel

To set up the tunnel, you need to execute a command in the Mac's Terminal  application.

• Open the  Application s  folder on your Mac (if you don't know where this is. open your hard drive and the folder will be found there.
• Scroll down to the  Utilities  folder and open that as well.
• Locate the  Terminal  or  Terminal.app  file in the  Utilities  folder and double click on the icon for the terminal.
• This will open a new window where you will be able to type some text.

Type the following into the terminal window:

Replace USER  above with the username of the user on the remote server you are logging in as, this could be "root" but it is generally safer to use an unprivileged user instead. Replace server.domain.com  with the hostname or IP address of your remote server. Replace  22 at the end of the line above with whatever port your remote server accepts SSH connections on (22 is the default).

If you want to understand what this command is doing, read on, otherwise skip to  step 6 .

-f : This forks the process into the background so you don't have to keep the terminal window open to maintain the SSH tunnel. -N : This tells the SSH process to not execute any commands on the remote server (we are only forwarding traffic through the remote server). -M : Put the SSH client into master mode. We're doing this so we can easily enter a command later to gracefully end the SSH tunnel without having to kill the connection. -S : This is used in conjunction with the  -M command. This sets up a special kind of file (called a socket) that will allow us to enter a command later to gracefully end the SSH tunnel without having to kill the connection.  /tmp/sshtunnel is the full path to the socket file this command is creating. -D : This sets up a dynamic application level forwarding service and  1080 is the port it will listen on. This command creates the SOCKS proxy we'll use later. -p : Specify the port on which the remote server is listening for SSH connections.

You will be asked to log into your remote SSH server.

If you have to enter a password, the terminal will not show you bullets for your key strokes. You won't see anything at all. Just type your password and hit Return on your keyboard.

• Once you are connected to your remote server, you can quit the  Terminal application.

Configure the Proxy Service

Now you need to set up the SOCKS proxy so that your Mac routes traffic through your remote server instead.

Until you complete this step, your traffic is not secure.

The best way to use the SSH tunnel is to configure MacOS to send most/all traffic through it. Follow these steps to configure your system. While the screenshots may look different, these directions should work on any version of MacOS back to at least Snow Leopard 10.6 (which is as far back as we can test).

• Look for the network connection providing your internet/networking access. This is probably Ethernet or Wifi. Click on that connection in the sidebar.

• In the smaller field next to that (after the colon), enter the port number, which was  1080 If you used the directions above.

• You can close the  System Preferences window now if you want.
• Test to make sure your new connection is working by opening Safari or any browser that is configured to use your Mac's network proxy settings. Go to  https://hostdime.com/ip  to see if your IP address has changed. It should now show the IP address of your remote server.

You are now done until you want to turn off the SSH tunnel (skip to the final section below).

If you cannot make changes to your Mac's network settings, you can still use Firefox to secure your web browsing traffic. With this method, only traffic in Firefox is routed through the proxy service, all other traffic is routed normally.

• Select the radio button next to  Manual proxy configuration
• In the SOCKS Host  section, enter 127.0.0.1 .
• Enter  1080 as the  Port  (or whatever local port you selected when you set up the SOCKS proxy earlier),
• Click the radio button to select SOCKS v5 .

• Neither of the SSH tunnel options we set up require a password or authentication to use, so the first option,  Do not prompt for authentication if password is saved is not going to affect anything.
• The important item is  Proxy DNS when using SOCKS v5 . You should check the box next to this option, otherwise your DNS requests will be made locally and someone will be able to see what sites you visited even if they can't see what you did when you went there.
• Enable DNS over HTTPS  This will provide an additional layer of security at the risk of slowing down access to websites even more (at least on the first access).
• Click the  OK button to apply these changes.

Test the proxy by revisiting  https://hostdime.com/ip  and make sure your reported IP address has changed. If you don't see a change in the IP address, try forcing the page to refresh or quit and restart your browser and try again.

Disabling the SSH Tunnel and Proxy Service

To disconnect from the SSH tunnel, follow these steps:

• Disable SOCKS proxy use either by unchecking the SOCKS Proxy from the Advanced... section of the Network preference pane or by switching to  System Proxy  or  No Proxy  in the  Preferences  of Firefox, depending on which set of directions you followed.

Disconnect the SSH tunnel and close the connection to your remote server.

• Launch the  Terminal  application from your  Utilities  folder in the  Applications  folder.

In the terminal window, enter the following command (editing it as needed):

Replace  server.domain.com  with the IP address or server hostname of your remote server. Replace  22 with the port number that your remote server accepts SSH connections on. 22 is the default.

If you have problems for any reason disconnecting from your remote server this way, you can always restart your Mac and that will automatically kill the connection.

• Quit the the  Terminal  application.
• Test your connection to  https://hostdime.com/ip  and make sure the IP that gets reported is no longer the IP address of your remote server.

About This Guide

Terminology, client host, tunnel host, ingress, egress, using tunnels, local tunnels, remote tunnels, dynamic proxies, securing email.

• Poor Man’s VPN

Double Tunnel

Local http proxy, troubleshooting.

SSH tunnels can provide secure connections through insecure or untrusted networks and may also be used to securely route through firewalls.

This guide began as a personal document to help me learn and remember how SSH tunnels work and has been several years incubating. If you find errors or think of additional examples that you believe would be helpful, I’d be delighted to know about them.

Throughout this guide we use “SSH” to refer to the SSH protocol or the world of SSH things and use ssh to refer to the ssh(1) program itself. “We use ssh and sshd to make SSH connections.” The examples in this tutorial are based on OpenSSH 0.9.8 and later.

As a preview of what’s to come, here is an illustration of a local SSH tunnel that allows client-host to connect to www on port 80, tunneled through tunnel-host over SSH:

This tunnel is created with this shell command:

SSH tunnels always have at least two hosts involved 1 . The first host is the client host , or the host from which we run ssh to define the tunnel. The second host is the tunnel host where the tunnel connections are created . To build an SSH tunnel, the client host must be able to reach the tunnel host via SSH.

In the physical world of plumbing we have pipes, and one end of a pipe is usually as good as the other. With SSH tunnels, the ends of the tunnel are not interchangeable as connections may be initiated at only one end.

We will call the initiating side, entrance, or “listening” end of the tunnel ingress and the terminating or exit end of the tunnel egress .

In ssh syntax, the bind-address:port pair is always the ingress and the host:hostport pair is always the egress. The ingress bind-address is nearly always localhost 1 and since this is the default in ssh , it is often omitted and we have only the ingress port .

The tunnel egress can be a little confusing. The SSH portion of the tunnel ends at the host where the final SSH connection is made, though the tunnel host will forward the TCP connection to the specified host:hostport if host is not localhost . TCP traffic past the tunnel host is not secured by SSH 1 and any security would be determined by the protocol being tunneled (e.g., HTTPS, IMAPS, etc.), if any.

Any service using the tunnel must connect to the ingress port and the connection will come out at the egress host:hostport . To create an SSH tunnel, the tunnel host must be able to reach the egress host:hostport via TCP.

We may find that our way is sometimes blocked by firewall rules or network topologies 1 . Some complex tunneling involves multiple client hosts , tunnel hosts and ingress / egress pairs.

We’ll cover the basics of tunnel syntax here, copied more or less from the ssh(1) man page. We’ll also cover some general ssh options that are often used in SSH tunnels:

-N indicates that we will not be sending any commands over SSH and that ssh should not open stdin or execute any commands on the tunnel host.

-A enables agent forwarding. You should never enable forwarding on hosts you do not trust or otherwise do not wish to use agent forwarding on. See An Illustrated Guide to SSH Agent Fowarding and Using SSH Agent Forwarding for more information 1 .

A local tunnel is a tunnel whose ingress is located on the client host . Local tunnels are created with the -L option. The basic syntax of a local tunnel looks like this:

client-host : $ ssh -L port : host:hostport tunnel-host -N

If our client host were named you , we might make a connection to a web server through a bastion host:

you : $ ssh -L 8080 : www.example.com :80 bastion-host -N

And to use the tunnel we connect our web client to the tunnel’s ingress at localhost:8080 :

The HTTP request goes through the tunnel host bastion-host ; the tunnel egress is at www.example.com :80 .

Keep in mind that the SSH portion of the tunnel is between the client host and the tunnel host ; traffic between the tunnel host and www.example.com is not protected by SSH.

A remote tunnel is a tunnel whose ingress is located on the tunnel host . Remote tunnels are created with the -R option. The basic syntax of a remote tunnel is identical to local tunnel syntax except for the -R option:

client-host : $ ssh -R port : host:hostport tunnel-host -N

If we wanted to make www.example.com:80 available to a remote server via the remote server’s localhost:8080 , we might do something like this:

you : $ ssh -R 8080 : www.example.com :80 bastion-host -N

The tunnel’s ingress is on bastion-host ’s localhost:8080 and the egress points to www.example.com :80 :

This is a somewhat contrived remote tunnel example, since we might just as easily have made a local tunnel routed from 8080 to port 80 over localhost on the tunnel host itself. A more realistic use for remote tunnels will be given below in the examples.

The third kind of tunnel we’ll cover is a dynamic proxy. Dynamic SSH proxies forward application connections using the SOCKS4 or SOCKS5 protocol. This means that any application wishing to use a dynamic SSH tunnel must know how to communicate via one of these protocols and be specially configured to do so. Configuring applications to use SOCKS-based protocols is beyond the scope of this guide.

The basic syntax of a dynamic proxy looks like this:

client-host : $ ssh -D port tunnel-host -N

Dynamic proxies are different from local and remote tunnels in that they define only a tunnel ingress on the client host ; the tunnel egress is determined dynamically using the SOCKS protocol as the connection passes through the tunnel host .

If we wanted to route all of our web client’s traffic through a remote host via SSH, we might start a dynamic tunnel like this:

you : $ ssh -D 8080 remote-host -N

and then we can make HTTP requests that are now encrypted through to the tunnel host:

Our web client makes a SOCKS connection to the tunnel ingress on you at localhost:8080 ; ssh uses the SOCKS protocol to determine that the egress should be at www.example.com :80 . When the connection arrives at remote-host , ssh forwards the TCP connection to the egress. Any SOCKS compatible application may use this sort of proxy.

This is a powerful method to secure otherwise vulnerable application traffic.

Now that we’ve covered the basic syntax of local, remote, and dynamic tunnels, we’ll show a few illustrated examples of how these might be used. The following image may be used as a reference to understand the colors and symbols in the subsequent examples:

We’re connected to an untrusted network and we want to check our email via an unencrypted IMAP connection 1 .

If we were to check our email over this untrusted network, we would be sending our credentials in the clear and anyone else on the network could capture our credentials in transit:

If we first make an SSH tunnel to a trusted host, then our traffic passing over the untrusted network will be encrypted all the way through to the trusted host, out of harm’s way:

This command creates the SSH tunnel:

you : $ ssh -L 2143 : mail-server:143 trusted-host -N

We create a local tunnel ( -L ) whose ingress is on you at localhost:2143 and whose egress is at mail-server:143 . The tunnel is secured via SSH between the client host you and the tunnel host trusted-host .

To use this tunnel, we configure our mail client to use localhost:2143 , rather than mail-server:143 . The tunnel will forward all traffic it receives on port 2143 to mail-server port 143 via trusted-host .

Note that our network traffic leaving the tunnel egress at trusted-host for mail-server will not be protected by SSH.

Poor Man’s VPN

We have an internal company web server we need to access at web-server ports 80 and 443. We are outside of the corporate network but the network administrator has configured a bastion host for SSH connections.

We’ll use the bastion host as our tunnel host to forward our web traffic into the trusted network:

Here is the command to create this kind of tunnel:

you : $ ssh -L 8080 : web-server:80 -L 8443 : web-server:443 bastion-host -N

We create one local tunnel whose ingress is on localhost:8080 and whose egress is at web-server:80 . We create a second local tunnel whose ingress is at localhost:8443 and whose egress is at web-server:443 . Both tunnels pass through bastion-host .

We can make HTTP and HTTPS requests to localhost ports 8080 and 8443 which will be forwarded to web-server ports 80 and 443 respectively:

This example illustrates a double tunnel to get around two firewalls.

We are connected to VLAN 1 and want to check out a Git repository in VLAN 3 .

The bastion host spanning VLAN 1 and VLAN 2 cannot access to the Git server, but a test server that spans VLAN 2 and VLAN 3 can. The Git service listens on port 7999.

Here is a picture of our network:

We need to first tunnel into VLAN 2 , using bastion-host as the first tunnel host. We create a local tunnel to bastion-host with an ingress on you ’s localhost:7999 and an egress on bastion-host ’s localhost:2999 :

This command creates the tunnel:

you : $ ssh -L 7999 : localhost:2999 bastion-host

Notice how we did not use -N with this tunnel. The reason is that we can use this SSH connection to make our second tunnel, using test-server for the tunnel host:

This second tunnel is created from bastion-host :

bastion-host : $ ssh -L 2999 : git-server:7999 test-server -N

In this second tunnel, bastion-host is acting as the client host with ingress on bastion-host ’s localhost:2999 . The connection goes through the tunnel host test-server with egress at git-server:7999 .

This double tunnel is possible because bastion-host is hosting the first tunnel’s egress at localhost:2999 and the second tunnel’s ingress at localhost:2999 , thereby linking the two tunnels.

Chaining tunnels through multi-homed hosts can get you far inside of networks.

Now we can connect to git-server through the tunnels:

For existing repos, we can add a new remote:

Remote tunnels are less common than local tunnels, but are no less useful in the right situation. In this example we will use a remote tunnel to create a connection back to our client host which will be acting as an HTTP proxy.

We need to fetch a remote file via HTTP from our beta server, but the beta server connected to VLAN 2 does not have access to the public internet, nor can it connect to other hosts in VLAN 2 . The only access permitted to the beta server is through a bridge host that sits on VLAN 1 and VLAN 2 .

Our own host ( you ) may connect to the bridge host as well as the public internet.

Here is the network:

Our first step is to run an HTTP proxy on you . Selection and installation of an HTTP proxy is outside of the scope of this document, but for the sake of this illustration, we’ll use tinyproxy which is freely available and requires little to no configuration. We’ll assume our tinyproxy is configured to listen on all interfaces (including localhost ) at port 8888 and we’ll run it in the foreground so we don’t forget about it 1 :

Now we have a means for hosts connected to you:8888 to access the public internet:

However, because beta-server cannot access you directly to access the HTTP proxy, we need to create a tunnel from the bridge host back to us:

This commands creates the tunnel:

you : $ ssh -R 8080 : localhost:8888 bridge-host

This creates a remote tunnel whose ingress is on bridge-host ’s localhost:8080 and whose egress is at you ’s localhost:8888 , which is where our tinyproxy daemon is listening.

Pay close attention to where the ingress and egress are: they are in opposite positions to where they are in a local ( -L ) tunnel, meaning the tunnel is entered on the tunnel host rather than on the client host . This is the definition of a remote tunnel.

With this tunnel as it is, we could access the public internet from the bridge host like so:

While this is neat, we’re only halfway done. As we did in the double local tunnel, we’ll use this SSH connection to make our second remote tunnel:

To create this tunnel:

you : $ ssh -R 8080 : localhost:8888 bridge-host bridge : $ ssh -R 9999 : localhost:8080 beta-server -N

The second remote tunnel has ingress at beta-server ’s localhost:9999 and egress is at bridge-host ’s localhost:8080 , which is where the first tunnel’s ingress is. The tunnels join on bridge-host so that HTTP connections made on beta-server:9999 (the effective ingress) are forwarded to tinyproxy running on you:8888 (the effective egress):

As mentioned at the beginning of this document, before you can create an SSH tunnel, the client host must be able to connect to the tunnel host via SSH. This is the first thing you should test when troubleshooting.

If that works properly, you might check to see if firewall rules prohibit opening any of the ports you are trying to forward. This may require a little experimentation or co-opting of existing open ports.

Further, many SSH installations are customized. Some administrators require public key authentication, others require password authentication 1 . Is agent forwarding permitted? Prohibited? Are you using the same keypair for every connection or do some connections require one keypair and others another?

Many of these configuration differences can be put into ~/.ssh/config files on the hosts you use as clients and tunnels, allowing you to use aliases and simplifying your SSH connections.

Try ssh in verbose mode; did you know ssh accepts up to three -v flags? Finally, there is no substitute for the manual. OpenSSH and other SSH variants have extensive documentation that’s worth a gander.

SSH tunnels can provide strong security for data in transit and can compensate for baroque network topologies. SSH tunnels can also be used to circumvent reasonable security measures designed to prevent certain kinds of network access.

Knowledge is a two-edged sword: I hope that you will use this information to do good, not evil. I neither encourage nor condone using SSH tunnels to bypass your network administrator’s intentions to protect access to specific hosts on the network.

Be wise, be good!

A third possible host is defined in the egress definition, but if the host is set to “localhost”, then either the client host or tunnel host will be used for egress (depending on if the tunnel is a remote tunnel or a local tunnel, respectively).  ↩︎   ↩︎   ↩︎   ↩︎   ↩︎   ↩︎   ↩︎   ↩︎

Last modified on 2015-08-16

How To: Surf Securely with an SSH Tunnel

By the time most people read this post I will have stayed in three different hotels in New York, New Jersey and Maryland while trekking along with Challenge X teams for their final competition. That means I have had a chance to glance through several terms of service agreements for various hotel internet connections. They usually include some clause stating that they retain the right to monitor your online activities and so on - Orwellian Big Brother stuff. The same generally goes for places that have free or for-pay Internet connections. Although, with unsecured Wi-Fi Internet connections it's more an issue of other users sniffing your data with network analyzer tools like Wireshark.

If you're paranoid about those types of privacy and security issues and you happen to have access to a server with SSH, you can securely send your Internet data through your server in an encrypted network tunnel. SSH tunnels are nothing new and there are many ways of setting them up, even standalone applications that can do it for you. You can even setup specific tunnels for different ports, such as for securing your email. For now, I'm just going to deal with securing HTTP traffic.

Fire up a terminal session and enter in the long SSH command below. Naturally, change out the username and domain info for the server you're using. ssh -D 8080 -f -C -q -N [email protected]

If you want to find out the specifics of those flags, the ssh man page gives a good rundown. The 8080 number is the port that I will be sending traffic through instead of the regular HTTP port 80. You can pretty much use any port number, but port 8080 is the standard HTTP alternate as defined by the IANA (interesting link nonetheless) .

The changes should be automatic in Safari. You can check by visiting a site like What's My IP . You're good to go if it displays the IP address of your server, not your computer.

How often do you use networks you don't trust? How do you deal with them?

Twitter · Mastodon · Subscribe ( RSS )

Paul Stamatiou is a designer who codes. He's the Co-Founder of Rewind AI , previously designed at Twitter for 9 years, and has been writing here for 18 years .

• Zero Trust Suite
• Quantum-Safe Cryptography (QSC)
• Secure Business Communications
• Security Risk Assessment, Quantification & Mitigation
• Just-in-Time Access
• Secure vendor access
• Credentials & Secrets Management
• Hybrid & multi-cloud access management
• Interactive tour: Privileged Access in the Cloud
• M2M connections
• IT Audits & Compliance
• Secure file transfer
• Managed Service Providers (MSP)
• Operational Technology (OT)
• Federal Government Security
• PrivX™ Hybrid PAM
• Universal SSH Key Manager®
• NQX™ quantum-ready encryption
• Tectia™ SSH Client/Server
• Tectia™ z/OS
• Deltagon Secure Email
• Deltagon Secure Sign
• All-in-one Deltagon Secure Communications Suite
• PrivX Zero Trust Suite
• Secure Collaboration 2024
• Strong ID-based access with Entra ID & Zero Trust Suite
• OpenSSH by SSH
• Device trust & access and identity verification
• Identity-based authentication & converged IAM and PAM
• Hybrid & Multi-Cloud Access Management
• M2M Connections Management
• Secure File Transfer
• Healthcare Data Security
• Secure Mail 2024
• Secure Messaging 2024
• Secure Sign
• All-in-one Secure Collaboration
• PrivX™ hybrid PAM
• PrivX™ OT Edition
• Tectia™ SSH Server for IBM z/OS
• NQX™ quantum-safe encryption
• SSH Risk Assessment™
• Professional Services
• PrivX Zero Trust PAM
• Enterprise Key Management UKM
• Tectia SFTP for servers & mainframes
• SSH Secure Collaboration
• SSH Academy
• Content library
• Press releases
• Events & Webinars
• Report a vulnerability

SSH Tunneling

This page explains SSH tunneling (also called SSH port forwarding ), how it can be used to get into an internal corporate network from the Internet, and how to prevent SSH tunnels at a firewall. SSH tunneling is a powerful tool, but it can also be abused. Controlling tunneling is particularly important when moving services to Amazon AWS or other cloud computing services.

What is an SSH tunnel?

SSH tunneling is a method of transporting arbitrary networking data over an encrypted SSH connection. It can be used to add encryption to legacy applications. It can also be used to implement VPNs (Virtual Private Networks) and access intranet services across firewalls.

SSH is a standard for secure remote logins and file transfers over untrusted networks. It also provides a way to secure the data traffic of any given application using port forwarding, basically tunneling any TCP/IP port over SSH. This means that the application data traffic is directed to flow inside an encrypted SSH connection so that it cannot be eavesdropped or intercepted while it is in transit. SSH tunneling enables adding network security to legacy applications that do not natively support encryption.

The figure presents a simplified overview of SSH tunneling. The secure connection over the untrusted network is established between an SSH client and an SSH server . This SSH connection is encrypted, protects confidentiality and integrity, and authenticates communicating parties.

The SSH connection is used by the application to connect to the application server. With tunneling enabled, the application contacts to a port on the local host that the SSH client listens on. The SSH client then forwards the application over its encrypted tunnel to the server. The server then connects to the actual application server - usually on the same machine or in the same data center as the SSH server. The application communication is thus secured, without having to modify the application or end user workflows.

Who uses SSH tunneling?

The downside is that any user who is able to log into a server can enable port forwarding. This is widely exploited by internal IT people to log into their home machines or servers in a cloud, forwarding a port from the server back into the enterprise intranet to their work machine or suitable server.

Hackers and malware can similarly use it to leave a backdoor into the internal network . It can also be used for hiding attackers's tracks by bouncing an attack through multiple devices that permit uncontrolled tunneling.

To see how to configure an SSH tunnel, see this example . Tunneling is often used together with SSH keys and public key authentication to fully automate the process.

Benefits of SSH tunneling for enterprises

SSH tunnels are widely used in many corporate environments that employ mainframe systems as their application backends. In those environments the applications themselves may have very limited native support for security. By utilizing tunneling, compliance with SOX , HIPAA , PCI-DSS and other standards can be achieved without having to modify applications.

In many cases these applications and application servers are such that making code changes to them may be impractical or prohibitively expensive. Source code may not be available, the vendor may no longer exist, the product may be out of support, or the development team may no longer exist. Adding a security wrapper, such as SSH tunneling, has provided a cost-effective and practical way to add security for such applications. For example, entire country-wide ATM networks run using tunneling for security. 

SSH's Tectia SSH Client/Server   is a commercial solution that can provide secure application tunneling along with   SFTP   and secure remote access for enterprises.

hbspt.cta._relativeUrls=true;hbspt.cta.load(470387, '2b9b443b-3db1-45a0-96ce-3411458968b6', {"useNewLoader":"true","region":"na1"});

Ssh tunneling in the corporate risk portfolio.

As useful as SSH tunneling is, it also creates risk that needs to be addressed by corporate IT security teams. SSH connections are protected with strong encryption. This makes their content is invisible to most deployed network monitoring and traffic filtering solutions. This invisibility carries considerable risk potential if it is used for malicious purposes such as data exfiltration. Cybercriminals or malware could exploit SSH tunnels to hide their unauthorized communications, or to exfiltrate stolen data from the target network.

In an SSH back-tunneling attack, the attacker sets up a server outside the target network (in Amazon AWS , for example). Once the attacker is in the target system, she connects to the outside SSH server from the inside. Most organizations permit outgoing SSH connections, at least if they have servers in a public cloud. This SSH connection is set up with an option that enables TCP port forwarding from a port on the external server to an SSH port on a server in the internal network. Setting up this SSH back-tunnel requires a single one-line command on the inside, and it can easily be automated. Most firewalls offer little to no protection against it.

There are several widely known and documented cases of malware leveraging the SSH protocol as a means for hiding data exfiltration and command channels. Several instances of malware have been actively collecting SSH keys. Captured and collected SSH keys have also been sold on hacker forums.

Combined with attacks based on unmanaged SSH keys , SSH tunneling allows an attacker to utilize stolen SSH keys for an intranet from the public Internet .

SSH tunneling attacks can also be used for hiding the source of the attack . It is common or hackers to bounce attacks off systems and devices that allow SSH port forwarding to hide their tracks. This allows them to probe for vulnerabilities, try various login credentials, or run attack tools against email, web, telephony and any other protocols. Bouncing an attack through a dozen random devices via encrypted tunnels also carrying other traffic makes it virtually untraceable. Akamai documented millions of IoT devices being used in this way.

Countering these risks requires the capability to monitor, control and audit encrypted SSH connections. For preventing bouncing, it requires proper configuration and hardening of IoT operating systems.

It should also be noted that tunneling attacks are not specific to SSH - a competent programmer can write a tool to tunnel ports in a few hours and can run it on any machine on the internal network. Any laptop or other device on the internal network can do it - it just needs to be able to communicate with some (any) service on the Internet. Such a tool could be made to work over SSL/TLS, could emulate HTTP, or could operate over UDP and use packets that look like DNS requests and responses. SSH just makes it easier for non-programmers. You can only protect from tunneling attacks against people who are able to run software on the inside or connect any device to the internal network by only allowing protocols you can inspect through the firewall.

How to configure an SSH tunnel

See the configuration example page for detailed configuration instructions. The SSH command line options and SSH server configuration file pages may also be helpful.

We at SSH secure communications between systems, automated applications, and people. We strive to build future-proof and safe communications for businesses and organizations to grow safely in the digital world.

• Zero Trust Suite & Entra ID Integration
• Security Risk Mitigation
• OT security
• MSP Security
• Hybrid cloud security
• UKM Zero Trust™
• Tectia SSH Client/Server™
• SSH Secure Collaboration 2024
• NQX™ Quantum-Safe

Stay on top of the latest in cybersecurity

Be the first to know about SSH’s new solutions, product updates, new features, and other SSH news!

© Copyright SSH • 2023 • Legal

Chapter 8 Tunneling

Table of Contents

Tunneling is a way to forward otherwise unsecured TCP traffic through Secure Shell. Tunneling can provide secure application connectivity, for example, to POP3, SMTP, and HTTP-based applications that would otherwise be unsecured.

The Secure Shell v2 connection protocol provides channels that can be used for a wide range of purposes. All of these channels are multiplexed into a single encrypted tunnel and can be used for tunneling (forwarding) arbitrary TCP/IP ports and X11 connections.

The client-server applications using the tunnel will carry out their own authentication procedures, if any, the same way they would without the encrypted tunnel.

The protocol/application might only be able to connect to a fixed port number (e.g. IMAP 143). Otherwise any available port can be chosen for tunneling. For remote (incoming) tunnels, the ports under 1024 (the well-known service ports) are not allowed for the regular users, but are available only for system administrators (root privileges).

There are two basic kinds of tunnels: local and remote. They are also called outgoing and incoming tunnels, respectively. X11 forwarding and agent forwarding are special cases of a remote tunnel. The different tunneling options are handled in the following sections.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Is it possible to tunnel https traffic via ssh tunnel with standard ssh-programs?

Can I reroute the https traffic (of an svn repository) via ssh-tunnel.

The problem is that the the services that use https don't work if I just create one tunnel for listening with e.g.:

Do I have to do something else? The aim is to tunnel https://PROJECT.googlecode.com/svn/ where PROJECT is the project name.

4 Answers 4

HTTPS connection can be redirected via SSH port forwarding - however the SSL/TLS certificate validation will fail in such cases as the host name does not match:

You are connecting to https://localhost:12345 but the server certificate contains the name server.com.

Instead of directly forwarding the HTTPS connection I would run an HTTP(s)/SOCKS proxy on the remote computer you are opening the SSH connection to. Then set-up the program you want to tunnel to use this proxy through port forwarding. This would be a clean solution.

Update: It seems like SVN can use HTTP proxies but not SOCKS proxies. If want to do so you need an additional "socksifier" on your local system. See Serverfault.com: How can I set proxy for subversion with ssh tunnel?

• 1 Can I actually use this kind of approach: dltj.org/article/ssh-as-socks-proxy ? So in the googlecode case, I would have a local-computer -> socks-computer -> googlecode. And this "ssh -D" would be run on local computer: ssh -D 12345 [username]@[socks-computer]. Now I have to tell svn to use proxy at local-computer:12345. Do I need something else? –  Juha Oct 19, 2011 at 11:26
• Cool, I did not know that OpenSSH already includes a SOCKS proxy. See also my updated answer. –  Robert Oct 19, 2011 at 11:38
• 12 You can get around the HTTPS certificate issue by adding the remote host to your local hosts file with ip address 127.0.0.1. Then you can actually use remotehost:12345 address but the traffic will still be directed to SSH tunnel. –  Juha Palomäki Aug 14, 2013 at 11:44
• @JuhaPalomäki you should add this as an answer –  elhefe Aug 8, 2018 at 0:43

To be able to work around the certificate DNS mismatch issue while accessing the remote server with SSH tunnel, I did the following:

• Configure an SSH tunnel in putty so that local port 443 forwards traffic to the remote server (L443 : <remote.server.com>:443 )
• Update C:\Windows\System32\drivers\etc\hosts file to add an entry such as 127.0.0.1 <remote.server.com>
• If you are using HTTP proxy server (for example if you are working from a corporate proxy), then bypass the <remote.server.com> host from system proxy
• Now you can access the remote server URL with https://<remote.server.com>

• This solution assumes putty and Windows. On Linux SSH is configured in ~/.ssh/config (doc in man ssh_config ) and if you are root, you can modify /etc/hosts instead. This feels hackish, still. –  Stéphane Gourichon Aug 20, 2020 at 15:29
• You can just tell whatever client program you are using to ignore the "bad" certificate. Usually all programs have some options for that (eg. -k in curl ). Since you are setting up tunnel to a well-known server, you can safely ignore warnings about certificate mismatch. –  raj Dec 1, 2020 at 21:40

For Linux one could just SSH dynamic port forwarding

Localhost ssh -fND 1234 user-name@remote-ip-address-A

Remote host ssh -fNL 12345:remote-ip-address-B:443 remote-ip-address-A

Open Firefox install FoxyProxy and set it up as shown in the screengrab. FoxyProxy settings

In Firefox click the FoxyProxy icon and select the proxy connection you just made. In the URL bar type https://127.0.0.1 .

Additionally you could just bypass this whole thing and just use sshuttle . Using sshuttle 's -H argument causes it to update your local /etc/hosts file as new remote hostnames are found. You will need this so that certificates will work properly.

Juha Palomäki's comment helped me.

My scenario is as follows:

server-i-want-to-get-to.com is only accessible via a certain list of IP addresses, my home network is not allowed, but the outgoing IP address of my-server.com (a server I control) is allowed.

So, I want to get to https://server-i-want-get-to.com/ , using the outgoing IP address from [email protected]

On my laptop (or desktop), I add an entry to /etc/hosts

Now, I ssh in to myserver.com , and use dig to find out the IP address of server-i-want-to-get-to.com

... and now from the ANSWER SECTION I know the IP address XX.XX.XX.XX

From the terminal on my laptop, establish an ssh tunnel

... pick a port not already in use, 8686 is just an example ...

Now, I can go to https://server-i-want-to-get-to.com:8686/ in my browser.

Thanks to the /etc/hosts entry, there is no SSL Certificate error.

... it might be necessary to clear browser cache, or start with a fresh browser ...

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged ssh tunnel https ..

• The Overflow Blog
• Reshaping the future of API platforms
• Between hyper-focus and burnout: Developing with ADHD
• Featured on Meta
• Our Partnership with OpenAI
• Imgur image URL migration: Coming soon to a Stack Exchange site near you!

Hot Network Questions

• Can I use "Britons" in data reports?
• Create an empty 8x8 One Up puzzle with a unique solution
• Quickest return from stable Earth orbit to ground?
• Ceiling box has two reds and two blacks - how to wire this?
• Is there any explanation or discussion regarding the change in the Bard class from its AD&D1ed orignal implementation?
• How does the centripetal force change when the radius changes?
• May the Fourth Be With You - a Star Wars Day Bounty Hunt
• I keep blowing up irrigation solenoids
• Is my DM taking too long to level us up?
• Can I swap a gravel wheel with 1x10 cassette for a new road wheel with 1x12?
• Conjecture about union-closed families of sets - attempt 2
• How accurate is the model 42179 Planet Earth and Moon in Orbit?
• Try Triling ("Triangular-Tiling")
• Are there countries where defendants are fully compensated for their time if they’re found not guilty?
• printf - store formatted string output in a variable
• Is consciousness causally superfluous?
• Dismissive and uncommunicative coworker when there are clear signs of tension
• Immigration and customs requirements on entering JFK (self-transfer)
• Is it bad to branch off data traces into two separate connectors?
• The Wu line drawing algorithm for anti-aliased lines optimization
• Can I safely customize fingering of arpeggios?
• Text Based Game about Synthesizing Fuel from Scratch?
• Can individual rings of Saturn be considered satellites?
• What is the equation relating the sides and the orthocenter segments of a triangle?

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

How do I tunnel and browse the server webpage on my laptop?

I run a web app in one of my lab servers, and I have already setup X11 Forwarding on those machines. Other lab members can tunnel through SSH, and browse that web app on their local browser at home.

I can't. Last time I checked with them, there is almost nothing I need to do.

When I type 192.168.1.113/webapp I get nothing.

I ended up using the second method :)

• @BlueXrider general, yes, on-topic, yes. For something like this, the versions of Ubuntu don't really matter, its about as on-topic as What is a torrent and how do I use it which is considered on-topic. :) –  jrg Mar 12, 2012 at 1:12

There are two ways you can do this with SSH.

Tunnel Everything with a SOCKS proxy

Log in to the remote machine using the following command:

Now go to your browser's proxy settings, and configure it to use a SOCKS proxy with host name 127.0.0.1 and port 8080 (or whatever port you passed to the -D option). Now all pages you load in your web browser will be tunnelled through the SSH connection. You should now be able to access the private web page in the same way you would from the remote host.

Once you are done, set your browser's proxy settings back to normal.

One down side of this method is that all other traffic in the web browser will also be going through the SSH connection. On the upside, you can access the remote servers with their real host names, and can easily access multiple private sites.

Tunnel a single port.

The alternative method is to use SSH to forward a single port:

Now if you point your web browser at http://localhost:8080/ , you should see the contents of http://server-hostname/ as it would appear from the remote host.

The benefit of this method is that it leaves the rest of the browser traffic alone. The downside is that some links might not work if the remote site uses absolute URL references. If the site mostly uses relative URL references, then this method should be sufficient.

For both of these solutions, there is nothing special about the port 8080 . You can use any free local port number you want, as long as you remember to use the same one in the ssh invocation and in the web browser.

• 4 Thanks. It was very helpful! I managed to do it this way: ssh -L 8080:<server-ip-address>:80 <username>@<remote-addr> -N something like this (the second method). –  CppLearner Mar 12, 2012 at 1:43
• Is it correct that I must configure only a socks proxy in the first method (see: spareclockcycles.files.wordpress.com/2009/04/… ). I.e. it would not work, if I point the http proxy to 127.0.0.1:8080? If this is correct, perhaps you could point out in your great answer, that one has to set up only the socks proxy. –  student Jul 18, 2012 at 11:31
• If you use Chrome (second browser?) you can pass proxy parameter for SOCKS5 directly on start: chromium-browser --proxy-server="socks5://localhost:8080" –  panticz Nov 18, 2015 at 8:31
• why are you not using any .ppk or .pem to connect the instance? How should I change your code if I need to use one? –  Seymour Nov 10, 2019 at 10:13
• Note that this method fails for secured websites; A company website, I need access too, will say "we don't know the URL you used to access our website, so we don't allow you in", and Google will say "page not found", when trying to forward the HTTPS port. –  kdb Mar 27, 2020 at 13:56

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged ssh remote tunnel ..

• The Overflow Blog
• Reshaping the future of API platforms
• Between hyper-focus and burnout: Developing with ADHD
• Featured on Meta
• Our Partnership with OpenAI
• Imgur image URL migration: Coming soon to a Stack Exchange site near you!

Hot Network Questions

• Is a tactical nuclear strike against a military target different on a legal standpoint than a tactical nuclear strike against a civilian target?
• Troubleshooting why my hammock fell
• Is the estimand in a Regression Discontinuity Design the ATE, ATT, etc?
• Origin and grammaticality of "I like me ..."
• I keep blowing up irrigation solenoids
• Generating a Visible Barcode to a Darkened Back Cover
• Electrolysis experiment with CuSO4
• Are there any fallacies in Stephen C. Meyer's argument for classical theism from the Big Bang singularity?
• Is my DM taking too long to level us up?
• Where is the mistake in the argument in favor of the (erroneous) claim "every Dedekind cut is a rational cut"?
• How does Russia exactly define Russian territory in its state policy?
• A short fiction about an American poetess who supposedly foiled, thanks to posthumous poems, the Martian invasion described by H. G. Wells
• Is consciousness causally superfluous?
• Immigration and customs requirements on entering JFK (self-transfer)
• printf - store formatted string output in a variable
• What is an argument (in philosophy)?
• How can I work with a senior researcher who is less knowledgeable than myself?
• May the Fourth Be With You - a Star Wars Day Bounty Hunt
• FourierTrigSeries doesn't know Jacobi–Anger expansion?
• Why does the EU find the foreign agent law in Georgia against their values?
• Scientist travels back in time to murder his wife’s secret lover
• How do I enable a PHP extension on GitLab CI?
• code format and steps web scraping using beautiful soup
• What does "come the nut-cutting" mean?