Access your Raspberry Pi without a public IP
9 points
8 hours ago
| 8 comments
| pinggy.io
| HN
resoluteteeth
8 hours ago
[-]
> However, all of these methods usually require port forwarding, which can pose security risks.

Except that pinggy appears to be an ngrok clone which is basically equivalent to port forwarding in terms of security

If you don't want to expose the port for security reasons you are better off using tailscale/zerotier/wireguard

reply
PLG88
7 hours ago
[-]
Except its not. Port forwarding exposes your local environment to the internet, unrestricted. Pinggy (and other sharing platforms - https://github.com/anderspitman/awesome-tunneling) share a resource on a public IP, which should be at the very least behind basic auth. The 'better alternative' you describe is an overlay network. These things have different purposes.
reply
resoluteteeth
5 hours ago
[-]
OK, looking into it more it appears that pinggy actually has pretty good options for adding authentication (I guess that's what you were referring to by basic authentication, not just the service being exposed having basic authentication) and based on that it does seem that it could be more secure than just forwarding the port if the service being exposed doesn't have built in authentication, and that would make me a lot more tempted to use it.

The article for some reason didn't explain that at all or show examples using pinggy's authentication features. If the article had talked about that, the assertion about being more secure would have made a lot more sense.

reply
PLG88
4 hours ago
[-]
Agreed. It surprises me that many of these services do not either lead with auth or have it as an important secondary. For many, port forwarding is a pain, so it solves that, but the security IMHO is just as important.

It's a shame lists like - https://github.com/anderspitman/awesome-tunneling - do not call this out. fwiw, the one I work on, zrok.io (in truth, I work on its parent project, OpenZiti) has that hardening and auth because we believe its vital.

reply
mossTechnician
7 hours ago
[-]
How do you tell Pinggy is closer to ngrok than Tailscale? To me (I've never used any of these services) they all look more or less the same, with slightly different interfaces. I wouldn't know how to distinguish a more secure option from a less secure one.

I see somebody else also mentioned Raspberry Pi itself has a similar service.

reply
abound
7 hours ago
[-]
> How do you tell Pinggy is closer to ngrok than Tailscale?

Taking a quick look at the article, it seems like you route traffic through Pinggy, whereas Tailscale is mostly (minus the TURN stuff) peer to peer with some NAT-busting

reply
PLG88
7 hours ago
[-]
The main difference is that Pinggy works via a public IP, whereas Tailscale is a private network overlay. Pinggy falls into the bucket of solutions like ngrok, zrok, Tailscale 'Funnel', Cloudflare Tunnel etc.
reply
james_pm
8 hours ago
[-]
reply
dlachausse
7 hours ago
[-]
Thank you! I never knew about this.
reply
waingake
7 hours ago
[-]
Here is a much better technique which only relies on SSH https://www.jeffgeerling.com/blog/2022/ssh-and-http-raspberr...
reply
supportengineer
8 hours ago
[-]
How/why would I trust "xrdp" and/or pinggy.io? It sounds like I'm allowing them unfettered access into my home network.
reply
josephcsible
7 hours ago
[-]
xrdp is the standard Linux RDP server and is probably provided by your distro, which you have to trust anyway. And that `ssh -R` command only gives pinggy.io access to the host:port you specify, not your entire network.
reply
hedora
7 hours ago
[-]
It's had remotely exploitable vulnerabilities in recent years, and I know of no Linux distribution that configures it to listen on an external port by default.

Pinggy does seem to support incoming IP whitelists, at least.

reply
dlachausse
7 hours ago
[-]
In theory what you’re saying is true, but in practice if someone gains access to a machine on your network it becomes significantly easier to gain access to additional machines on your network.
reply
emmelaich
7 hours ago
[-]
If you do this or similar, choose very good passwords because it is certain to be probed.

Also consider using the whitelist option.

reply
ta988
7 hours ago
[-]
How is it different from tmate that allows to use ssh keys for auth?
reply
sleepybrett
7 hours ago
[-]
tailscale/wireguard
reply
morninglight
4 hours ago
[-]
reply