SSH Port Forwarding

Update 4/9/2019: So anyone interested in this topic should read this article from Black Hills Information Security. Carrie Roberts does a much better job than I do at explaining how to do this and she implements it better. Anyway, I’m leaving my article up in the event that someone finds it useful, but seriously, go read the other article.

Today I’m going to attempt to explain how to do some different SSH port forwards. There’s a lot of different reasons to use port forwards, but I’ll be putting this in perspective of conducting a pentest from a remote computer. Buckle in because this can get a little confusing. Also, my images got a little too compressed so the commands get hard to read. Don’t worry. I added the text into the blog as well. 🙂

First, I’ll set the scenario. Computer A is the machine I want to conduct a penetration test with. It’s a virtual machine (VM) that a client has downloaded and installed in their local environment. Computer B is in the Amazon cloud and simple acts as an intermediary. Computer C is my local machine. What I want to do is run commands on computer A from computer C. This is fairly simple to setup.


There are three stages to this setup. First computer A creates a reverse ssh connection with computer B. So Computer A connects to B via ssh on port 22. At the same time, it establishes a local listener on Computer B port 2200 that will forward traffic back to itself over the established ssh connection. Now Computer C just needs to ssh into Computer B as normal. This establishes a ssh terminal enabling me to run commands on Computer B. So now I’m on Computer B running commands from computer C. Hopefully that makes sense. Now I issue another ssh command on Computer B’s local port 2200. The reverse connection kicks in and forwards my commands to Computer A. Scenario one complete. I can now run commands on Computer A from Computer C and it’s completely seamless.

ssh -N -i PATH/TO/Key/File – R 2200:localhost:22 UserName@AddressForCompB

ssh -p 2200 UserForCompA@localhost

ssh -i PATH/TO/KEY/FILE UserName@AddressForCompB

This works great for command line but what if I need to run a vulnerability scanner that uses a web GUI? Now I need a way to get my local web browser to render a web page two hops away. To explain this better, I’m going to break things down into stages.

First, let’s just deal with a web page that is one hop away. We’ll say our cloud server is hosting an internal page we need to view. sshblog2

This is something I learned from the Metasploit CTF and it’s really quite simple. When connecting from Computer C to Computer B, adding the -D and a port will create a dynamic port forward using a SOCKS 5 proxy. Browsers can the be set to use the proxy to reach the webpage. In this case, I told SSH to use 9392 as the proxy port but this could be anything. I then set Firefox to use the proxy on localhost 9392. Then I simply enter the URL as if I was browsing locally on Computer B. The proxy sends the URL requests over the SSH connection and now I can browse any and all web pages as if I was locally on Computer B.

ssh -i PATH/TO/KEY/FILE UserName@AddressForCompB -D 9392
Set Firefox Socks5 proxy to port 9392
Set URL to anything reachable by CompB

So that’s great and all, but the computer I really need to access with the browser is one more hop away. First, we’ll need to combine some concepts before adding the last piece.


Here I’ve combined the first and second scenarios. Computer A still makes the same reverse connection. The only difference is that now it also hosts an internal web page for a vulnerability scanner on port 9392 (That’s what OpenVAS uses in case you’re wondering). Anyway, it’s nothing different than scenario one.

ssh -N -i PATH/TO/Key/File – R 2200:localhost:22 UserName@AddressForCompB

Computer C connects to Computer B just like in Scenario two. Nothing new here either.

ssh -i PATH/TO/KEY/FILE UserName@AddressForCompB -D 9392
Set Firefox Socks5 proxy to port 9392
Set URL to web address on CompC –

The one thing that’s missing is a connector. Connecting with a normal SSH command, like in scenario one, on Computer B will not work.  Our proxy would forward the traffic to Computer B, but Computer B wouldn’t know what to do with it. Computer B would think Computer C is looking for something hosted on it’s internal port. That’s not what we want. Now let’s add the final connector.

ssh -p 2200 UserForCompA@localhost -L 9392:localhost:9392


Using a static port forward, Computer B will now take anything that comes in on port 9392(the socks 5 proxy from Computer C for example) and forward it to 9392 on Computer A using the SSH connection on the internal port 2200.  Now I can browse to the vulnerability scanner’s GUI interface just as if I was locally on Computer C. It is important to note that if the web page redirects to a different port, it will break the connection. This is different than in scenario two where Computer C could browse to any page. Scenario three is confined to just a single port.

Hopefully that all made sense. It’s much easier to understand when you’re actually doing it. I would encourage you to set up a lab and give it a try. You could even add an extra step and configure Burp Suite along the path. While that wouldn’t be helpful in a vuln-scanning scenario, you never know when you might just need to view a remote web page.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s