ssh workups - plumbing and piping - tunneling, reverse tunneling, socks5, ssh jumps and funsies.

ssh is the defacto 'go-to' for secure plumbing and piping. Let's start with the basics and work our way up.  We do this deliberately to prevent skill-fade.

SSH with graphics:

• By adding either the -X or -Y option one can easily pipe graphics from most X11 enabled Linux machines.

ssh -X c@192.168.1.3

And then typing 'xclock' is the easiest and quickest way to verify you can pipe graphics:

SSH Via Socks5 Proxy

A very easy method of building your own VPN service like NordVPN can be done between two linux boxes with a simple command:

ssh -D 12000 c@someserver.com

Once this is done one can simply point their browser to access the internet via port 12000 at localhost:

Additionally you can specify the originating port of the server itself which will just make it open a port for other devices on your home net to use as a proxy, as in:

ssh -D 12000 c@localIP

A nice feature is that one can install firefox add-in 'Containers' and 'Container-Proxy.' Once this is done one tab of your browser can be direct, another can be through your proxy:

Additionally one can add the -N option for 'no-login'

ssh -D 12000 -N c@somelinuxserver.com

SSHFS - One can mount remote filesystems through SSH tunnels. In this guide I was able to mount the 'hard drive' of a SD card on a VPS 1000 miles away and have it come back:

0x0007 - Gumstick your VPS (Virtual Private Server) with a raspberry pi zero - and give it a 256 GB drive on a small watt budget (Part 2)

Gumstick your VPS (Virtual Private Server) with a raspberry pi zero - and give it a 256 GB drive on a small watt budget (Part 2)

Technical Blogthinkmelt

Advanced ssh Punching Funsies: ssh through a SOCKS5 Proxy.

There is almost no documentation on the internet how to do this properly and it is a neat feat to see if you can even do this.  Above the standard SOCKS proxy works fine for rerouting http web traffic - But what if we punch a ssh session through a SOCKS proxy itself.  Here is how to do it!

Install netcat-openbsd (the regular nc cannot do this)

sudo apt install netcat-openbsd

Next get your standard SOCKS proxy working as in:

ssh -D 12000 user@someserver

Once you have that working it should be identifiable from a localized nmap scan:

nmap localhost

Will show that your local port is open:

Now punch your ssh through the SOCKS5:

ssh -o ProxyCommand='nc.openbsd -X 5 -x 127.0.0.1:12001 %h %p' c@destination

Some explaining:

-X 5  (ssh cannot use SOCKS5 proxy but nc.openbsd can)  If you had a SOCKS 4 it would be -X 4
-x 127.0.0.1:12001  (Proxy that nc.openbsd will punch through)
%h %p are expected following parameters 
c@destinationserver  (Where you are going)

Old Style Proxy Jumping:

One can also utilize 'old style' proxy jumping as in:

# In this example we are copying a key to a distant Class C isolated machine as in:
ssh-copy-id -o ProxyCommand='ssh -W %h:%p user@jumphost' user@192.168.0.3

Advanced ssh Punching Funsies: ssh proxy with Jump.

Experimenting with this did not seem to work more than two servers.  The -J option is a alias for the 'ProxyJump' command but will effectively route through one ssh tunnel through a second and come out at point 3.

ssh -D 9999 -J c@138.128.223.76 c@166.212.158.61

# Advanced porting with external IP binding has a small modifications as in:
ssh -D 0.0.0.0:9999 -J c@ip_a c@ip_b etc.. 

In this example (which somehow actually works!) We are opening up a SOCKS5 proxy to the localhost and it tunnels through the midpoint server (138.128.223.76) and finally hits the internet at the end (166.212.158.61)

Limitations.

ssh -D 9999 -J c@pointA c@pointB c@pointC

Does not work. I've tried several times so one will quickly find limitations. But knowing that you can use the above ProxyCommand you can technically tunnel SSH through the SOCKS5 jump proxy to get to point 4.  But probably by that time there are so many layers it probably would not work well.

-L Mastering: Port Forwarding Grainularity

The basic port forwarding can be accomplished as in:

ssh -L 9000:servera:9000  account@serverb

This is not very well explained, try considering the difference between these three:

ssh -L 9000:192.168.1.3:22 c@192.168.1.63   # or,
ssh -L 9000:192.168.1.63:22 c@192.168.1.63   # or,
ssh -L 9000:192.168.1.63:22 c@192.168.1.3 

Unfortunately all will be accepted but not all will work! The key is that the left-side address must be one of the bindable addresses from the originating server.

Because in this case the originating server is 192.168.1.63 in actuality only the last two options will work!  Few guides will actually identify this or mis-identify the seoncd server option.

-R Reverse Port Tunnelling

Simply turn the command backwards as in:

ssh -R 9000:localhost:5555  user@outsideserver.com

In this case we are mapping remote port 9000 at outsideserver.com to localport 5555.  Anyone logged into outsideserver can do:

ssh localhost -p 9000 

And will show up at the remote host.

Reverse Remoting Through Your Home Network:

A reverse tunnel with the -R option is a great way to allow you to access your home networks very securely.  Consider:

ssh -o ServerAliveInterval=30 -R 9000:localhost:22 user@203.282.182.113

- Routers will kill connections that do not have traffic on them in variant time amounts.  The option

-o ServerAliveInterval=30

Will make sure to keep the connection alive.

-R 9000:localhost:22 c@203.282.182.113

Will allow one to ssh back through the local ISP infrastructure (which actually has a lot of hidden port overloading) through your local router, and back to your home computer from the outside server at 203.282.182.113.

Summary:

ssh is powerful but has a lot of gotchas. Many of the guides do not deeply explore what actually works in testing just as the -J option which actually does not work past the 3rd point, or what really is happening with the -L option.