Yes but the Pi is calling home, so isn't that trading privacy for convenience? And I fail to understand how it's more secure than ssh + private key? There is still a connection outside.
My best guess is that its made for the lower end of tech user, who knows they want to ssh but doesn't know enough to be able to do it securely on their own? Otherwise I have no idea what the use-case is
That's exactly the use case—I think after they switched to wayland, and RealVNC didn't work (it was included with the default install on every full version of Pi OS), they wanted to make sure there was an easy to use replacement.
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.
I didn't read the domain, and was first a bit upset that the OP apparently flew to visit a store[1], but then realized that it's Mr Geerling (I don't follow him) so I guess it's more of a work thing, at least.
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.
Some people grew up in a household too poor for travel-by-plane to become a thing. I only knew about airplanes because i could see them in the sky and in the TV. I thought it was a rich people's thing.
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.
When I lived in the USA, I flew almost every month - for work, for interviews, for a few days in some nice place. It really was like catching a bus. But, man was it stressy. Just getting to the airport, going through the security theatre, commuting on soulless American freeways for hours on end.
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 still remember my first times in the US at the end for the 1990ies beginning 2000s for business reasons. At that time before the security theater it was really much more like taking a bus. It was really like in TV where the relatives say God bye at the gate, because there was no (obvious) security in place at all.
I'm from and based in Germany. I haven't been much in the US in the last 10 years for several reasons.
In Italy, the most busy domestic route (Roma-Milano), was replaced by the high speed trains.
Who would take a one hour flight if you can take a 3 hour train with no security controls, more space and arrivals and departures in the city center?
Yes, the rail lines of Europe really are a boost to ones quality of life.
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.
If he was taking a bus, that would be well over a 13 hour bus ride, if he’s in fact located in St. Louis, as I guessed based on his most recent work experience listed on the site.
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 believe he lives in St Louis or Kansas City. They don't have Micro Centers there.
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.
We do have one in St. Louis (I'm lucky to live 10 min away), but I was out in Charlotte for one of their grand opening days—they sponsor a few video creators to come to a grand opening and do a special build/project.
They also have an industrial automated 3D printer filament retrieval machine customers can use, so I was lucky to get to try that out!
- 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.
You're right and I used to do the same for years (dyndns xD)
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.
The trick is that the connection is made using a third-party server: both the laptop and the Pi make an outgoing connection to this server, and the server sets up a connection between the two when there's pre-existing authorization. This means there's no need to poke a hole in your NAT/firewall to allow an incoming connection to the Pi.
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.
I generally like Jeff's content but this headline borders on clickbait. The "39000 ft" part is achieved with airplane wifi over satellite. Otherwise it's just remote shell to a Raspberry Pi.
You expose VPN to the internet, and expose SSH access just to the private VPN. You can still use SSH keys for your SSH auth, but now with the added layer of listening only on the VPN network.
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.
Layered security is good, but you're still using a key to access a resource.
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.
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.
I agree it's click baity. My personal favorite related moment, where I felt strongly "the future is now" was when I connected to a research station running autonomously on the Greenland ice sheet... while flying over the Greenland ice sheet to the UK last month. I was able to debug a software problem via satellite link while hurtling through the air in a tin can. Blew my mind. The latency was about 8 seconds, which was painful.
A) this is great for hobbyists who aren't super technical, but
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.
As one of the comments says, mosh is great for this sort of thing. I use mosh from my laptop, and it is simply bullet-proof. I can hibernate my laptop, warm it up a few days later, and it's all still connected absolutely fine. Running processes that produce loads of output don't care either. In fact, it's now my preferred way to run long jobs for work that don't want to be interrupted by a dropped connection - the alternative is running them with nohup or "at now".
I would argue that it's still much better to run "real" jobs in a daemon or in a multiplexer like screen or tmux. But for picking stuff up, agreed, mosh is amazing.
Yes, the difference is that if the computer running mosh client crashes (or runs out of battery without you realising), then you lose the ability to re-connect with the mosh server, which is where screen or tmux win.
While the title might make one think, "They've caught up to 1999!", the real point of the article and video seems to be "Raspberry Pi Connect", which is neat, but somewhat orthogonal to ssh and to choosing ssh over VNC on an airplane.
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.
50 comments
[ 2.4 ms ] story [ 108 ms ] threadMost 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.
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:
Then VNC handshake: If no authentication is used: If the client chose authentication, more steps are added in between. E.g. if the client chose TLS this happens: 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.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.
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.
https://github.com/aristocratos/btop
Silly to think this is relevant at all to HN.
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.
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.
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.
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.
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.