Remote shell to a Raspberry Pi at 39,000 ft
jeffgeerling.com
jeffgeerling.com
Most of us on HN use our own VPNs, or have a dozen other ways to get at infrastructure from anywhere (and mosh, as others have suggested, is a better alternative for simple shell access over high-latency flaky connections)... but there are a _lot_ of people who don't want to (or couldn't figure out how to) maintain their own VPN. Or they want to deploy Pis at remote sites and each one has a weird and unique networking config, and they don't want to mess with Tailscale or the like.
It's a useful service, but it's not supposed to compete with homelabber setups, or enterprise solutions. At least I don't think so.
Otherwise no one on hacker news is going to care. We’ve been doing that for years on planes with traditional home VPNs or things like Tailscale.
I continue to be unimpressed with this guy and have no idea why he is plastered all over the internet.
Isn't that strictly better? I.e. even if an attacker exploits a vulnerability to get to your private VPN network, they now have to find another exploit to get SSH access (presumably with the same SSH keys setup).
Edit: Aaah, the VPN isn't a private VPN, but Raspberry Pi Foundation's VPN, to use some of their solution to get to your RPI, right? In that case, I agree, the attack vector is just larger. I was confused because the article mentions a private VPN that Jeff has set up himself.
I think that greatly depends on the VPN. For something like Wireguard with a tiny attack surface? Sure, you can make that argument. For something big and sprawling like a commercial VPN (or even something open source like OpenVPN) - I think unless you have some other reason to run that VPN system anyway, the VPN probably has more attack surface than OpenSSH (and, in all likelihood, a worse security record to boot.)
Also, consider that if you are running the VPN server on the same system as the SSH daemon, an attacker generally wouldn't need to compromise the SSH daemon after compromising the VPN server - they'd probably already have a root shell just from popping the VPN.
Looked at individually, using a key to access a VPN is not more secure than using a key to access SSH. The risk isn't a remotely exploitable bug in ssh, but losing your secrets due to some other vulnerability.
If someone has access to your SSH key, they almost certainly are able to also access your VPN key - both are saved in your home directory and need to be regularly accessible. If, maybe, your VPN uses two factor authentication, that makes it much harder, but you could also use two factor authentication for SSH, and we're back to where we were before.
Since many ISPs haven't deployed IPv6, or have done so half-assed, services like "Raspberry Pi Connect" may become more and more necessary. Some people have no choice but to be behind CG-NAT, like Starlink and T-Mobile Home 5G, so this is good for them.
While I don't see much wrong with "Raspberry Pi Connect", I'm not a fan of the intermingling between the for-profit and the not-for-profit parts of the Raspberry Pi Foundation. Let's just hope the for-profit part doesn't decide that all the money isn't enough and they want to monetize "Raspberry Pi Connect" in the future.
And remember, kids, "Raspberry Pi Connect" is not as secure as ssh, so don't set up services lazily thinking they're protected! Set up key-based ssh, anyway, and heck, have VNC listen only on localhost and port forward over ssh so that your VNC password can't be brute forced.
Silly to think this is relevant at all to HN.
The original Raspberry announcement about Raspberry Pi Connect
> All devices get remote shell out-of-the-box, and if you use a Wayland compositor, such as Wayfire, you can also share your screen. In practice, this means you can use screen sharing with Raspberry Pi 4 and later models, and remote shell with all models of Raspberry Pi, even the oldest.
Now I have another task to purge this out of my pi.
How does Pi Connect’s access differ from regular port forwarding? Isn’t the device still exposed to the Internet?
The article mentions Cloudflare tunnels near the end. Does this work on a similar principle as Argo? (I haven’t watched the video yet.)
There's some magic stuff going on in the background to avoid having all data flow via the server by making it peer-to-peer after initialization, but that's the gist of it.
1: Yes I'm from Europe and yes I know that the US is big and that domestic flights are like taking the (approved) bus for many of y'all, it just doesn't feel like something that "fits" today's climate, so to speak.
I'm telling that to make people aware that travel-by-plane is not only a carbon-intensive way to travel, but also a privilege not everyone has.
Now that I live in Europe I do the same, but with trains - and it is a far more pleasant experience.
I've even just taken the train for a couple of days so that I could get some work done - nothing gets the neurons firing better than an 8 hour train-ride to Prague or an overnighter to Hamburg or Paris.
Its a pretty decent office environment too, if you book things right, or take a sleeper car. I know some folks who just take the train to work, not to get to work, on a regular basis. I absolutely love to be able to see the landscape scroll by while I wait for a build.. and have even had a TV set up in my terrestrial offices with such videos on in the background, although I confess that these days I really like those hour-long "walk through <city>" videos as a viable attention-boosting tool.
And, this being Europe, Internet access is not so bad - never had issues with my remote shells being terminated due to altitude limits or zoning issues. Beer spills, and the opening of the disco car, on the other hand ..
I'm from and based in Germany. I haven't been much in the US in the last 10 years for several reasons.
Just the therapeutic action of gazing across the landscape for a few hours, then returning to the book or laptop on the table in front of you can be rejuvenating in ways that sitting on the 405 for a few hours in the afternoon, isn't.
By train might even be longer, I don’t know if there’s a direct route between St. Louis and Charlotte. There’s a chance you’d have to go through Chicago.
Edit: I checked. You do have to go through Chicago, and Washington, DC as well making it about a 39 hour train journey. It’s also probably at least twice as expensive as flying.
I can’t fault him for flying.
In fact, there are only a handful of Micro Centers in the US. (I am very thankful that I live in Houston, which has one). Micro Center is the closest thing we have to a real-deal electronics store with people who know their shit.
Flying to Charlotte to check it out totally makes sense to me.
They also have an industrial automated 3D printer filament retrieval machine customers can use, so I was lucky to get to try that out!
First TCP handshake:
- Client SYN
- Server SYN ACK
- Client ACK
Then VNC handshake: - Server sends highest version that it supports
- Client sends back the version that it wants to use
- Server sends a list of authentication & encryption methods it supports
- Client chooses from the list and sends its response
If no authentication is used: - Server sends a message to the client saying auth went ok
- Client sends init message
- Server replies with its own init message
- Client sends pixel format and supported codecs and requests the first frame
- Server sends frame
If the client chose authentication, more steps are added in between. E.g. if the client chose TLS this happens: - Server sends VEnCrypt version
- Client sends VEnCrypt version
- Server acks client's version and sends list of supported security subtypes
- Client chooses a subtype and sends it
- Server upgrades the connection to TLS which adds a couple of more round-trips (5 steps total for this item).
If, for example, each step takes 100 ms, you should have a total of 1.2 s without auth and 2.1 s with TLS.B) Tailscale achieves this, with even more security if you want (I.e. only make the box accessible through a subnet router within your tailnet) and
C) Most of Southwest's 737s have been updated with satellite internet that offers okay latency and high bandwidth. This will straight up not work on a regional jet with GoGo/intelsat terrestrial internet that relies on cell towers. Latency is way too high. Keystrokes take like two or three seconds to get picked up.
But my current ISP required me to pay extra for a static IP, where their ordinary "dynamic IP" offering shares IP and don't allow for direct connections from the internet. This never used to be the case.