SSH Tunnels SIMPLIFIED!

Using SSH tunnels is the most magical, incredible, HORRIBLY CONFUSING thing you can do with SSH. But once you understand how they're actually redirecting traffic, using them becomes second nature. Plus you can do sneaky things like getting around a firewall and accessing servers that are supposed to be hidden!
I promise it's worth the effort.
In this video I explain how both local and remote tunnels work, why some people call them "forward and reverse" tunnels, and some pretty crafty reasons you might want to use them.
NOTE: SSH tunnels, particularly remote tunnels, can be SUPER SNEAKY and powerful. That bypassing firewall thing I talked about is the real deal.
If you're enjoying this series, let me know in the comments!
#tunnels #ssh #firewall #linux
All My Online Homes are Here:
shawnp0wers.com
Check out my comic!
/ mybigroundworld

[@JPBennett]

I was doing on-sight support for a hardware install at a hotel a few years ago. The remote tech's remote desktop software didn't want to play with my laptop, so he couldn't get into the switch he needed to configure, to make the install work. I asked if it had an SSH port he could use, if he were in the room with me. Of course it did, but that didn't do him much good. I ran a reverse SSH tunnel out to my public server, and pointed it at the switch on the local side. Had him SSH to my server on the given port, and he was magically connected to his switch. He was literally in awe of that trick, and demanded to know how it could be done.

[@shawnp0wers]

I had a client a few years back who was very VERY insistent on not forwarding any ports into their server infrastructure (including VPN). For the purpose of what they were doing, that was fine. BUT. I was the system administrator for hundreds of servers, and I lived across the country! Long story short, I set up two outgoing remote tunnels (for redundancy) that automatically connected to two separate public servers of mine, and reconnected if there was an outage. Accessing the whole thing using a tunnel wasn't ideal (TCP over TCP makes for some weird throughput issues), but since it was all just commandline work, it worked out pretty well. So yeah, SSH is our Swiss Army Knife in the NerdWorld. :D

[@Kimberwit]

Subscribed. I'm a lifetime follower now. You're the only person online who has explained this in a way I can understand.

[@shawnp0wers]

That’s incredibly kind, thank you!

[@Thomas_Grusz]

Thanks Shawn, this video really help me understand the concept of tunneling. Just preparing for my final LPIC 1 exam. Love your wok!👍

[@prettybasic9545]

You are such a good teacher, I have taken some of your courses on CBT Nuggets. Hope your videos reach much more people.

[@joir2000]

Many thanks for this very clear explanation!

[@petergaudiomonte1080]

Subscribed! Thanks to Network Chuck! Just finished your podcast with him. Great story! 33 yr dialysis and OHS survivor here learning as much as I can. Been an electrician for years, can't crawl under houses and in attics that well anymore. So tired of trying to live off disability. Thank you guys for sharing all this!

[@shawnp0wers]

Awesome, and welcome Peter! I'm currently setting up a "micro datacenter" at my farm, and I'm actually making it mostly off-grid, because running electrical wiring is... itchy and sweaty, lol! I'm glad you're here. :)

[@toddfitzgerald7185]

100% perfect understanding. Thank you! Just what I needed.

[@shawnp0wers]

Thank you!

[@dinz2321]

You are actually my hero when it comes to Linux! I started my journey learning from your videos in CBT nuggets!

[@shawnp0wers]

w00t!!! I'm glad you found me here. It's great to be making videos again. :) Welcome!

[@flyinokie]

Awesome tutorial. Thank you!

[@sm7udb]

Wow 😮. This I really have to watch again and try out.

[@thoril.pegason]

This was super helpful, thank you!

[@shawnp0wers]

Glad it was helpful!

[@ehmoratallar]

I just discovered the gateway ports option yesterday. It’s amazing !!! This video really explains the concept well. I really enjoyed it. Now I will be able to configure my nextcloud without a vpn which is just what I wanted.

[@shawnp0wers]

Cool! I do really like SSH. It’s almost scary how powerful it is!

[@ehmoratallar]

@@shawnp0wers Very true! I really like your enthusiasm!

[@aayushkubitkar4827]

great explanation with diagrams

[@GeoffreyKnauth]

Really great explanation!

[@shawnp0wers]

Thank you!

[@dechobarca]

Your video randomly got in my recommendations, so just stopping by to say hi. I think you're a very elaborate teacher, if that's the right word. I think something like what you explain in the video can be very useful for development and debugging, but I also learned something else. Because I saw you use "kermit" instead of typing out the server IP or domain name in the SSH command, it prompted me to research how it's done and subsequently create a ~/.ssh/config file, which I didn't know about but is actually super useful. Previously I was using .bash_aliases. Either way, cheers!

[@shawnp0wers]

Nice! Welcome, Decho. I do like to use hostnames instead of trying to remember IP addresses, and another nice trick is to add entries in your /etc/hosts file -- your computer checks there for name mapping before querying a DNS server. (It's a REALLY great way to test name-based virtual hosts with webservers, without the need to set up DNS in advance)

[@dechobarca]

Thank you for the great advice. I actually kinda do that for a slightly different purpose. Instead of buying a domain name, you could just map any domain name to localhost in /etc/hosts and be able to use self-signed certificates in development! Super handy with Nginx. I've subbed to your channel and will keep an eye on the content, looking forward to learning new things :)

[@OARomanov]

Awesome! Please go on with your channel!

[@shawnp0wers]

Thank you! I'm have a lot of fun, so hopefully I can keep cranking the videos out!

[@selvin9845]

👌👨‍💻thank you very much, that great explanation made me want to SUBSCRIBEd!! 👍

[@ifzen77]

Great explanation :) Thanks !

[@shawnp0wers]

You're welcome!

[@waleedarab7850]

I spent over a week on youtube as will as with super speed professor who explained it 30 ml seconds trying to understand it but I couldn't you caame and explained every thing in 20 minutes You're great man I wish that you are my professor ;) mine is broken.

[@shawnp0wers]

Oh, thank you! While I probably can't be your professor (although I did teach a Cisco class to highschoolers for a couple years, lol) -- you're welcome to stick around and learn all sorts of nerdy things. :D

[@MrMehi-hw3mq]

The wait is finally over!

[@shawnp0wers]

I know -- I've been doing so many things, and I've neglected the video series. Today I'm starting construction on the micro-datacenter at my farm. I'm going to try to record as much of the process as I can. Today is just building a server rack, maybe mounting the inverter/charge_controller. Tuesday the commercial fiber and block of IPs go live. Servers arrived this past Wednesday. I'm obviously super excited, but I do need to remember *all* my commitments! I'll try to be a little more consistent. Over on my blog I'll be writing about the "lots of irons in the fire" issue. The links to my other stuff are on shawnp0wers.com - and I'll be honest, there are a few I haven't even listed there! Thanks for being patient with me. :)

[@mananamin8175]

Amazing video. thanks

[@shawnp0wers]

Thank you too!

[@qwarlock4126]

The thing I have used -R for in the past is when I needed to access the internal servers from my home network. I would set up a -R to my home server listening to the internal ssh server. Now I can -L from my house to the -R that is also no on my home server... and with that ssh into any server at work.... from my home network.

[@shawnp0wers]

I really do love SSH. :D

[@13bimbou]

Thank you for those great explanations. I simply used forward tunnel with putty without really knowing the CLI behind, and today i decided to deep dive into CLI and also...that damn reverse thing ! You re my 4rth video on the subject but my first one that i can understand :-). There is only 1 thing i dont get, when you Reverse SSH, how can this work using only "Kermit" keyword in CLI and not "user@ip" ? 🤔

[@shawnp0wers]

Ahh, sorry that wasn’t clear. “Kermit” is the hostname of my server in Austria. Since I have the same domain set in my office, I did t have to type the whole fully qualified domain name. And since my local user is “spowers” and the user on my Kermit server is also “spowers” - I didn’t have to specify. If you don’t specify “user@“ it just uses your local username.

[@13bimbou]

Ahhh ok ! Indeed this makes sense for me now ! Thanks for your answer 😃

[@veljkovostinic3268]

What app/program are you using to blackboard/whiteboard the ssh arguments slide. Great presentation thank you!

[@shawnp0wers]

Thanks! It's honestly just powerpoint. :)

[@mikeolear]

Thanks!

[@shawnp0wers]

Shawn Powers, broken record here. You're incredible, and have gone WAY above and beyond.

[@MrJohnnyJW]

Can you clarify, in a reverse tunnel when a PC connects to the remote server, where does the authentication happen? Are you supplying the login for the machine at the end of the tunnel or the beginning? Hopefully this makes sense!

[@shawnp0wers]

The authentication takes place on the remote server. That’s what gives us the “permission” to use its network.

[@MrJohnnyJW]

@@shawnp0wers Thanks!

[@bullittstarter4408]

“Like a good neighbor, stay over there.” -Fake Farm hahahaha

[@shawnp0wers]

hehehe -- this is the first time anyone has noticed (or at least commented) on that little plaque. :)

[@jasonluong3862]

How do services like ZeroTier and Tailscale work compared to SSH? Is it better in terms of ease of use and security than SSH?

[@shawnp0wers]

So, from what I can tell, it looks like they provide an encrypted VPN sorta protection. SSH is still how you get access to another server's terminal. So using something like Tailscale in conjunction with SSH can give you some benefits, I don't think they are a substitute, just something that can work together with SSH.

[@nilpo]

Tailscale uses Wireguard protocol which is very fast, but has some inherent limitations. ZeroTier uses it's own protocol that is very similar to IPSec. Comparing these isn't exactly possible. A VPN encrypts an entire network (all traffic in/out of a machine-or network-on every port). SSH works at the application level encrypting a specific data stream through a single port. While some nerd-fu gymnastics can make them both tools for the same job at times, they really are two different things. The real power be using them together. With a VPN, you can use SSH to get a remote terminal without having to set up a tunnel.

[@hosseinshamloo]

Can I Route my windows DNS requests over SSH tunnel ? my ISP spoofs DNS traffic to implement filtering. I have SSH tunnel to my VPS overseas. FireFox is capable of socks proxy but DNS requests returned 10.x.x.x from my ISP.

[@shawnp0wers]

It would likely require some IPTABLES work. I recommend looking at "sshuttle" -- which is a sort of VPN over SSH. It does tunnel DNS. Or set up Wireguard on your overseas VPS. It's super efficient, and you can force DNS through it too. (I have a video on Wireguard here on the channel somewhere)

[@MsSam676]

now i get it ....thanks alot

[@shawnp0wers]

Most welcome 😊

[@nilpo]

Reverse tunneling doesn't bypass any firewall. It still relies on port 22 being open on the local side.

[@shawnp0wers]

No it doesn't. You have to be able to get *out* of the local network, but you do not have to have an open port of any sort for incoming traffic. I'm not being pedantic here, that's just literally how it works. I had a client who refused to have any open ports on their firewall, so in order to get in remotely, I had to establish a connection from inside their network to my publicly accessible server. Then I could use that connection to get into the datacenter by connecting to my publicly accessible server, where the reverse tunnel was listening. The remote server needs to have an open port, but the local network absolutely does not.

[@nilpo]

@@shawnp0wers Sorry, you are correct in your explanation but incorrect in how it works. It uses port 22 both in and out. Most firewalls are set up to block incoming ports only. They use a method known as port triggering to allow communication once an outgoing request has been made. So if you create an outgoing request on port 22, port triggering will open that port and allow the response to come back to you over the same port. This is typically allowed on "well known ports". However, an explicit deny rule on port 22 will stop port triggering from working. So yes, you must have an open port for SSH to work. Either explicitly allowed via rules and filters or implicitly allowed with port triggering. This isn't to be confused with the Port Triggering setting in many routers. While related, this setting allowed an application to open a different incoming port than the outgoing one. On some hardened networks that I have set up for clients, SSH tunneling does not work in either direction. I have explicit deny rules for port 22 through the network firewall. All traffic must be passed through a strictly controlled VPN. This prevents phones, tablets, and IoT devices from compromising a network by being controlled by a remote threat actor.

[@shawnp0wers]

So... we're starting to split hairs here -- but port 22 can be blocked and this still works just fine. The session starts from inside on some random port, and terminates on the remote server on whatever port SSH is listening on (port 22 by default). But it doesn't "open" the port on the local firewall, it starts a session (yes, on a port) and establishes a stateful connection. The firewall allows traffic to go back and forth on that established connection. The encrypted connection between the local computer and the remote server is such that the firewall has no idea what is happening inside of the connection. It could be text on the commandline, or it could be tunneled traffic in a tunnel. There are performance issues, because it's creating TCP tunnel inside TCP, and so the packet size is wonky. But it doesn't require (or dynamically create) and open port on the local firewall, any more than visiting a remote website would open a port. Perhaps the concept we're sniggling over is "open" -- when I say no open port on the firewall, I mean there is no outside port listening for an incoming connection.

[@shawnp0wers]

Also -- "it uses port 22 both in and out" -- that isn't how connecting to an SSH server works. The server listens on port 22 (by default), but the client starts a connection from a random high-numbered port. If it was port 22 on both sides, you could never SSH *out* from a server that is running its own SSH server, because port 22 would be busy.

[@shawnp0wers]

@@nilpo You edited your comment, so I'll address the change -- yes, of course you can firewall off outgoing SSH connections. But if you can connect to a remote SSH server, you don't need to "open a port" on the local firewall in order to set up a reverse tunnel. The established connection *tunnels* the traffic through the SSH session. Again, perhaps we're debating the terminology here. When you connect to a remote server, yes it "opens" the firewall for that session -- but it doesn't open the port for external access, and it's a random port, not a static port. Servers and clients dont' connect to each other using the same port number on both sides, that's not how network connections work.

[@thoughtchanger6252]

It's can collect our data ?

[@nilpo]

Anything can collect your data. However, OpenSSH is open source. You can examine the source code. The traffic itself is encrypted in transit and therefore safe from everyone except 3-letter agencies. But data collection can still happen at the application level on both machines. So you always need to know who you are connecting to.

[@MarcelRobitaille]

Please be careful when you do things like this. Firewalls exist for a reason, and not everybody appreciates their firewall being bypassed. Not that I don't do this all the time. Just know the risks and use responsibly.

[@nilpo]

I agree with the warning, but any good network admin worth his salt will have this disabled anyway in production environments. Or at the very least, locked down to some specific IP addresses. It is a tool for the toolbox though. Sometimes you're stuck using legacy applications that are hard coded to insecure ports or without built in encryption in transit. This can be used as a solution for those instances to encrypt the traffic in transit and move it to a different port. I has a client with a copier that had scan to email hard coded for port 25. Port 25 was blocked by the ISP and they wouldn't open it. An SSH tunnel solved the problem by routing the traffic over SSH and then allowing port 25 on the mail server, but only from localhost.

[@user-wr4yl7tx3w]

Did you say what Kermit was?

[@shawnp0wers]

LOL, whoops, maybe not! Kermit is just the domain name for my co-located raspberry pi in Austria. Quite a few years back, a hosting company out there offered free rackspace and free IP if you shipped them your RPi. I was lucky enough to get mine racked before they stopped the promotion. It's been probably 7 years, and while I did have an SD card fail, they replaced it when I sent a new one, and it's still running strong! :D

[@sampowers1234]

i bet our usernames are the same lol

[@shawnp0wers]

Team spowers FTW!

[@hellomihai]

WTH is "kermit"... where is that defined!?

[@shawnp0wers]

It’s a server of mine in Austria. I don’t think I showed the full domain to protect a bit of privacy.

[@hellomihai]

@@shawnp0wersgotcha… was pretty confused. How can we add our own? Just the ip or equivalent?

[@ssh-dev]

WA