Access your Raspberry Pi without a public IP | Hacker News Reader

Access your Raspberry Pi without a public IP

pinggy.io

48 pointsghoshbishakh31 comments

Or just use https://www.raspberrypi.com/software/connect/

Thank you! I never knew about this.

Are you associated with Pinggy?

Oh! Something like this exists! Thanks for sharing.

This post's content and tone in context of OP seems strange. You posted OP, yet didn't know about a first-party competitor to a product that you seem associated with, as per your bio? Is this some kind of astroturfing?

https://en.wikipedia.org/wiki/Astroturfing

> Astroturfing is the deceptive practice of hiding the sponsors of an orchestrated message or organization (e.g., political, advertising, religious, or public relations) to make it appear as though it originates from, and is supported by, unsolicited grassroots participants. It is a practice intended to give the statements or organizations credibility by withholding information about the source's financial backers.

> The implication behind the use of the term is that instead of a "true" or "natural" grassroots effort behind the activity in question, there is a "fake" or "artificial" appearance of support.

> 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

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.

> 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

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.

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.

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.

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.

The question is: how long until a vulnerability in your - now public - resource behind Pinggy is discovered and exploited?

The vuln is there, trust me.

If you use Wireguard or Tailscale, your network is private. Only other devices in this private network could explore this vuln.

We dont disagree. As I stated, "These things have different purposes". If you want to publicly share a resource, use a tool which provides that in the knowledge that if there is a vulnerability, it could be exploited. Using an overlay network reduces the risk further, but it means the end user needs to have an endpoint (unless you have an overlay with a 'clientless endpoint', but that's another topic). For some use cases, the endpoint is infeasible.

You still need to open a port for WireGuard. And you may be forwarding that open port if your gateway device doesn’t handle the vpn termination.

How does each compare to setting up a Tor hidden service that forwards to your ssh listening port? That's been my go-to for having a slow but reliable way to access a machine that might change network environments frequently, or be behind an odd network layout.

I don't know what the security's like, but I haven't seen any other solution beat ease of the setup process. (install tor, write service ports into config file, copy URL somewhere safe, done.)

That's quite interesting. It would need Tor unblocked on both ends however, unless you are using a public gateway.

Here is a much better technique which only relies on SSH https://www.jeffgeerling.com/blog/2022/ssh-and-http-raspberr...

> In this blog, we’ll discuss how to securely connect to your Raspberry Pi or IoT device remotely from anywhere over the internet without port forwarding

Port forwarding over ssh is still... port forwarding.

This is neat and can be quite useful, but it's still port forwarding. There's nothing wrong with that - it's not like people will easily guess the hostname and port number and will start brute forcing ssh using this.

But neither VNC nor RDP should ever, for any reason, be connected directly to the Internet, even if using a random port number. Use ssh with -L to connect to VNC or RDP over ssh.

How/why would I trust "xrdp" and/or pinggy.io? It sounds like I'm allowing them unfettered access into my home network.

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.

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.

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.

I've done tunneling/port forwarding/ANT config for years. I know how to get them work.

But fundamentally, I still don't understand why such issue exists.

Like, my (behind NAT, no public IP, whatever) device can visit any website or web services fine without any extra configuration. And obviously the servers of these services can reach me to send the content I need.

But then suddenly, if I want to reach my device from outside, I need all these extra stuff. What's the difference?

(I understand this is a very, very dumb question. Forgive my ignorance!)

i would consider this bad advice.

The ssh process that does the port forwarding is not reliably running in the background. Opening ports like ssh or xrdp to the public internet is not good security practice. OP says it's not port forwarding, but it's still port forwarding.

This seems like a simple service to make a quick buck.

What you should really look into is setting up a VPN like wireguard.

tailscale/wireguard

This.

(but using headscale on the tailnet coordination)

These are certainly good ways to go about it, but https://www.raspberrypi.com/software/connect/ does exist and is completely free and pretty easy to use

If you do this or similar, choose very good passwords because it is certain to be probed.

Also consider using the whitelist option.

How is it different from tmate that allows to use ssh keys for auth?

AT&T Archives on YouTube.

https://www.youtube.com/playlist?list=PLDB8B8220DEE96FD9

Reply on news.ycombinator.com