Gymnastics with SSH

Let's say you travel a lot or are on vacation in Greece. Is Greece awesome? You're goddamn right it is - Dining above Athens with a bottle of Domaine Romanée Conti overlooking the Parthenon is surely to be etched into eternal memory. Seriously though, if you've never been quit your job tomorrow, live a little, and kick it in Greece for a few weeks. Next go to Nepal and learn the true meaning of 'Namaste'...It'll change your life.

As awesome as traversing the planet is, we must remember that foreign entities may feel the same way about you and your data. Let's say you needed a quick way to hop back and forth between networks, transfer files, and do so in a secure manner.

Introducing SSH (AKA: The kickass solution to modern problems)
The SSH protocol (also referred to as Secure Shell) is a method for secure remote login from one computer to another. It provides several alternative options for strong authentication, and it protects the communications security and integrity with strong encryption. It is a secure alternative to the non-protected login protocols (such as telnet, rlogin) and insecure file transfer methods (such as FTP). 1

How do we use SSH?
SSH has several key usages but here are the one's we'll be highlighting in this entry:

• Remotely accessing another machine
• File Transfers
• Dynamic SOCKS Proxies
• Port Forwarding and Pivoting

Remotely Accessing Another Machine
To hop onto another box with the SSH service running:

ssh -p someport user@ourbox
[Note: An optional -i to specify key file]

File Transfers
Transferring a file to a remote host via Secure Copy (SCP):

scp -P someport somefile.txt user@ourbox:/tmp/somefile.txt
Pulling a file down from a remote host:

scp -P someport user@ourbox:/tmp/somefile.txt /home/myuser/somefile.txt
[Note: An optional -P can be used if SSH is running on a non-standard port... Strongly recommended.]

Dynamic SOCKS Proxies
What on earth is a Dynamic SOCKS Proxy?

Unlike HTTP proxies, which enable the proxying of HTTP traffic, SOCKS proxies enable us to proxy socket connections. This enables us to proxy application traffic (non-protocol dependant) through an SSH tunnel and 'interlink' any service we'd like.

Using SSH as a dynamic SOCKS proxy

ssh -D 8080 -p someport user@ourbox
[Note: -D represents the port you are binding on your local machine]

This configuration enables us to proxy any traffic through 'ourbox' en route to its final destination. One common example for this would be in the instance of web application testing etc... If a particular machine has access to a webpage that we don't have access to, we can pivot through the middleman and hit the web page.

Upon configuring the tunnel with:

ssh -D 8080 -p someport user@ourbox
We could then set up our web browser to use a local SOCKS proxy within the browser's configuration as shown below:

Using this configuration, we can now hit any web application that 'ourbox' can.

Port Forwarding and Pivoting
My personal favorite use of SSH is for port forwarding and pivoting throughout a network. Leveraging SSH, it is possible to 'bind' to any port we may choose. As a result, we can tunnel any protocol we'd like over SSH which is pretty awesome if you think about it.

Scenario: RDP over SSH over the Internet
Let's say you wanted to be able to interact with your desktop from outside of your network. There are several ways to accomplish this but we're going to stick with SSH tunneling. Things we need:

A machine running remote desktop (Box #1 - End goal)
A box on the internet that we control to use as a middle (Box #2 - Think of it as a bridge)
Our machine located in Greece (Box #3 - Entry point)

Here's a visual reference of what we're trying to do, albeit an abysmal attempt to draw in paint:

Microsoft RDP runs on port 3389. What this means is if we can bind a port on a machine we own to port 3389 of the Windows machine then we should be able to hop through the tunnel and access our Windows machine via our VPS over SSH tunnels.

We can accomplish this easily using SSH tunneling as demonstrated below:

From Box #3 to Box #2

ssh -R 8888:localhost:3389 user@mybox
What did this just do? We bound the local machine (Box #3) port 3389 to port 8888 of Box #2. If we hop on Box #2 we will notice a connection listening on 127.0.0.1:8888.

[Note: The -R signifies a 'Remote' port forward. You can think of this as us 'offering' our port 3389 to another machine.] This is the opposite of -L 'Local' port forward which is shown in the next example.

Now, let's bind port 8888 on our local machine (Box #1) to port 8888 of our VPS (Box #2).

From Box #1 to Box #2

ssh user@mybox -L 8888:localhost:8888
[Note: The -L signifies a 'Local' port forward. You can think of this as us 'asking' another machine to borrow their port.]

In this particular case, from our local machine we are authenticating to Box #2 and 'asking' to bind to port 8888... Box #2 agrees and we choose to bind it to 8888 on our local machine.

Now, if we look at our local machine's active connections we should notice a new connection 127.0.0.1:8888

On Box #2

netstat -antp | grep "8888"
Now, let's attempt to use Remote Desktop and hit our local machine on port 8888, if everything is configured properly we will tunnel to our VPS on port 8888 (which is bound to 3389 of the end machine).

And voila, we can now interact with a remote machine via RDP over SSH tunnels.

One Last Note
For non-proxy aware applications we can use a tool called proxychains which enables us to force applications through an existing proxy configuration. There will be a future entry highlighting the use of proxychains.

**References: **
https://ssh.com