To overcome this, you'd have to establish a server outside of your homelab that your homelab's device could SSH into to establish the reverse SSH connection. That router, like our homelab's own router/firewall, also won't allow a remote device to establish an SSH connection across it. Chances are, if we're working remotely, we ourselves are also behind another router, one that we don't control. Now, there's still one problem with this whole idea. It's the stuff of nightmares for corporate IT security admins because it's subverting their firewall- we've bypassed it. The image below illustrates this concept. Once the connection is established, we redirect the port, allowing us to use the established connection to SSH into the remote host. (It's remote relative to us- we're on our local laptop, the homelab being on a different network is remote to us). ![]() We instead allow the remote device on the homelab SSH into us. Since your attempted SSH traffic from outside the network splatters on the firewall's windshield, how do we connect? The answer is, "we" on our local laptop outside of the homelab don't. This is what I normally do, but this is dependent on your VPN being alive and that may not be the case. Sure, there are ways to secure your SSH server, but why do it if you don't have to? Limit your attack surfaces.Īlternatively, you can keep port 22 closed and when you need to SSH into a device remotely, you just VPN in and then, once you're on the network, establish an SSH connection like you normally would. If you ever review your pfSense logs, you'll see that you're being scanned all the time for open ports. A lot of people do this, but I see it as a needless risk. To get around this, you'd have to open up port 22 on your router and port forward it to your RPi. However, when you're trying to SSH into a host remotely, this isn't as easily accomplished due to your router's NAT (network address translation) and firewall. ![]() For those of us with a homelab, we're typically on the same network as the device and so SSH is simple. If you're not, think of it as a secure terminal that allows you to connect to a remote host. If you've been following my blog, you're undoubtedly familiar by now with SSH. In this guide, I will walk you through the steps to create the easiest reverse SSH tunnel so that you can remotely access a device on your homelab securely and easily. I could build a second, redundant VPN server, and that's probably not a bad idea, but it's not in the budget right now and it's prone to the same risks. Therefore, I need an alternate way to access my homelab when I am remote to it. ![]() Alternatively, my VPN server could just outright fail. However, if my IP address changed (as could happen in the event of a power outage), and for some reason my dynamic DNS service also failed, I would not be able to VPN into my homelab network. Normally, I connect to my homelab remotely via VPN which tracks my homelab's public IP address via a dynamic DNS service. Once I had identified these key points of failure, I came up with a strategy for being able to handle them, leading to the creation of my Unattended Server Checklist. This used to be a source of anxiety for me, until I analyzed my homelab loadout and identified key points of failure. If something goes wrong, I obviously don't have physical access to my network. I travel a lot, which means that often my homelab is left unattended. ![]() The easiest, quick step-by-step guide for accessing your homelab network remotely via a reverse SSH tunnel on a Raspberry Pi (or any other Debian/Ubuntu device).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |