![]() ![]() Thankfully, there is such a service- (formerly known as weaved). They have the specialized knowledge to secure such things. Let the people who specialize in such things do them. While I believe it's good to have the knowledge and understanding, I also believe in economies of scale and comparative advantage. No, no, you don't need to do all of that. You came here looking for information about how to remotely SSH into a host on your homelab and now I'm telling you that you need to not only create this reverse SSH tunnel, but you also now need to buy, secure, and maintain a new server outside of your homelab? Geez, opening up port 22 and just port forwarding is starting to sound pretty good right now. This is why you should monitor the traffic not only going into your network, but even more importantly, the traffic leaving it.īy this point, all of this sounds like a lot of overhead. This is usually what botnets are- large swaths of infected devices phoning home to a control server "mothership". This server is often called a "mothership" and we refer to this connection between the remote homelab host and server as "phoning home to the mothership". It would be this remote server that you yourself would remote into. ![]() 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 |