Every home lab hits the same moment: you're away, something needs a look, and the box is at home behind a router. There are five reasonable answers to that, and they're not interchangeable. Here's how I think about choosing.
A service is stuck. A backup didn't run. You want to check a log. You're not home.
The first solution everyone reaches for is the one that takes ninety seconds: forward port 22 on the router, remember the WAN address, done. It works immediately, which is exactly why it's so popular.
Then you read auth.log.
Failed password for root from 45.148.10.x port 51234 ssh2
Failed password for admin from 193.32.162.x port 44120 ssh2
Invalid user oracle from 141.98.10.x port 33210 ssh2
... 4,812 more lines since TuesdayNobody targeted you. Scanners sweep the entire IPv4 space continuously; an open 22 is found within minutes and then probed forever. That traffic is background radiation on the internet.
Honestly: often not. A properly configured SSH server is a hard target. Key-only authentication,
PermitRootLogin no, fail2ban, and a current OpenSSH will shrug off every one of those
attempts. Plenty of people have run exactly that for a decade without incident.
The problem isn't that it's guaranteed to fail. It's what you've taken on.
You now maintain an internet-facing service, permanently, forever. Every OpenSSH CVE is your homework. Every misconfiguration — a password auth that crept back in, a forgotten test account — is exposed the moment it happens rather than being contained. And the blast radius isn't one machine: SSH is the key to everything that machine can reach.
That's a lot of ongoing responsibility for "I wanted to check a log."
A VPN home. WireGuard on the router or a Pi, and your laptop joins the home network from anywhere. Genuinely excellent, and if you already run one, you may not need anything else. You still expose a UDP port, but WireGuard's design means an unauthenticated scanner gets no response at all — it's silent to anyone without a key. The cost is setup and upkeep, and that every device you want access from needs to be enrolled.
A mesh network. Tailscale, ZeroTier, Nebula. These take the VPN idea and remove almost all of the administration — devices find each other, keys rotate, NAT traversal is handled. For many home labs this is the pragmatic best answer, and I'd recommend it without hesitation to someone who wants every device to see every other device. The tradeoff is that you're adopting a network layer: an identity system, a client on each machine, and a coordination service in the middle.
A bastion / jump host. One hardened, exposed box; everything else reachable only through it. This is the classic answer and it's classic because it works. It's also the most work, and you still have an exposed SSH server — you've just reduced how many.
A reverse tunnel to a public URL. Cloudflare Tunnel, ngrok, HLE's own tunnels. The machine dials out, you get a public HTTPS address, no inbound port. Ideal for web things you want to open in a browser or share with someone. Less natural for SSH: you're wrapping a protocol that isn't HTTP in something built for HTTP, and now your SSH server has a public front door of a different shape.
A private point-to-point bridge. Both machines dial out to a relay that pairs them. No public address exists, and nothing is exposed. This is the narrowest option — it connects two specific things rather than joining networks — and that narrowness is the point.
Want every device to reach every device? That's a network problem. Use a mesh or a VPN. Nothing else will feel right, and fighting that with point-to-point forwards is miserable.
Want to share a web UI with someone who isn't technical? They need a URL they can open. That's a tunnel, with SSO in front of it.
Want to reach one port on one machine, yourself? That's the narrow case. A private bridge does exactly that and nothing more, which means there's very little to get wrong.
Running a real multi-user environment? A bastion with audited access is still the right shape, and the extra work buys you something real.
Most home labs end up with two of these, not one. A mesh for your own devices and tunnels for the things you share is a very common, very sensible combination.
I wanted SSH to one Raspberry Pi from whatever laptop I had with me. I didn't want to join a network, enroll devices, or maintain an exposed host for it.
So HLE grew a thing called firepuncher. An agent on the Pi already holds an outbound connection to the relay. A command on the laptop opens its own outbound connection, and the relay pairs the two:
hle fp --agent rpi --to 22 --port 9922
ssh -p 9922 pi@127.0.0.1Neither machine accepts an inbound connection. There's no public address to find, so there's nothing for a scanner to sweep. SSH does its own authentication exactly as before — HLE moves bytes, it doesn't terminate your session or hold your keys.
The agent also refuses to dial anything that isn't on its allowlist, which defaults to itself. That constraint is deliberate: it means holding the credential doesn't imply reaching the whole LAN behind the Pi.
With the forward installed as a service and four lines in ~/.ssh/config, the whole thing
collapses back to ssh rpi. The
walkthrough is here if you want the specifics.
It's TCP only. No UDP, so no WireGuard through it — and that's not an oversight to be fixed later. Carrying UDP over a reliable, ordered transport turns dropped packets into stalls, which is worse than not offering it.
It connects things, not networks. One local port per remote port. If you want broadcast discovery, or forty machines seeing each other, use a mesh.
There's a relay in the path. Your traffic is encrypted end to end by whatever protocol you're running — SSH stays SSH — but the connection depends on a third party being up. A VPN straight home has fewer moving parts.
If you already have a mesh you're happy with, you don't need this. Use the thing that's working.
Forwarding port 22 isn't reckless. It's just a much broader commitment than the problem usually requires — a permanent public service, maintained by you, to solve an occasional need to check a log.
Whatever you choose, the good options share one property: the thing at home dials out, and nothing at home listens. Mesh, VPN, tunnel, private bridge — all of them get that right. Start there and pick whichever fits how you actually work.
One agent on the machine you care about, one command on your laptop. Free tier, no card.