I'm curious, what don't you like about ngrok? Is it just that it's a paid service? You do need a server somewhere to forward connections and that normally costs money to run
Ideological reasons. I'm no Richard Stallman, but try to exclusively use FOSS software. I have made concessions for requirements at work (G Suite, Slack, Ngrok for conference calls/webhooks, etc).
The source for the backend portion is also available, https://github.com/localtunnel/server. Going to set it up shortly on my own personal box, and if it works smoothly I'll be able to present it as a self-hosted alternative to my employer.
There's still no client-server encryption over the http leg. Someone snooping on packets can see the traffic of the person using the web-service in plaintext. HTTPS would mitigate this.
How does that help you access your app from some other machine? And how does ssh help you get secure access from a remote browser to the tunneled port? The ssh security is only from the tunneled port to your local port.
There commands above are suggesting two tunnels, appropriate for when both parties have private IP addresses behind NATing routers. This requires a rendezvous server with a publicly visible IP address, The first (with -R) forwards the listening port of the local private server to the rendezvous server:
This allows connections to the private local server from processes on rendezvous.example.com which connect to their localhost:8080. This requires configuring "GatewayPorts yes" on the rendezvous server, which is disabled by default. The person you are sharing with then sets up their tunnel to using the forwarded port:
ssh -L 8081:localhost:80 rendezvous.example.com
(port number changed to distinguish between the endpoints) This creates a tunnel from their localhost:8081 to rendezvous.example.com:8080, which is then forwarded to port 80 on your server that you wanted to share.
Both tunnels are encrypted. While traffic analysis is still possible, the tunnels also obscure the details of each request; eavesdroppers only see the tunnels as a stream of encrypted data regardless of how many GET/POST requests actually happen.
If one side has a public address that can be directly accessed, the rendezvous server is not needed; just use one tunnel. The fact that we ever need a rendezvous server is part of the incredible damage IP Masquerading (private IPv4 addresses behind NAT) has done to the internet. Working around "party lines" is incredibly frustrating.
If you're setting up many forwarded ports, it may be easier to use a SOCKS proxy server (ssh option -D <local_proxy_port) instead of many "ssh -L" tunnels. The other side (-R) will be the same.
While I do see the value having free https, Localtunnel requires you to trust that whatever code they're running on their server is what they say it is (you could deploy their code on your own server, but then you'd probably need to set up https yourself).
For my use cases this outweighs the need for https--on the off chance I need to expose localhost to the web, it's usually for a quick prototype that's only up for a few minutes and doesn't require any sensitive info to be sent.
I wrote an SSH server in Go to try to get the best of both. ssh -R 80:localhost:8888 serveo.net. Automatically gives you a subdomain, has features for HTTP inspection/replay, but nothing to install.
Great work. I was thinking of a service using autossh and assigned names would be nice for raspberry pi users that don't know networking. Forward sshd also, and help them setup apache with mod_python... and on and on.
What's the configuration with the SSL? The cert DN name didn't match my assigned sub-domain and it wasn't a wildcard, so how did you make that work? I saw it's from Lets Encrypt, but it seemed instantly setup, so you're not requesting a new cert for each sub-domain, right?
Cool use case! Right, I'm not requesting a new certificate for each subdomain. I found a list of a few thousand of the most common latin words, then got certificates for batches of 100 at a time. Requesting certificates on demand runs me into Lets Encrypt's rate limiting (20 per week max).
19 comments
[ 3.2 ms ] story [ 36.8 ms ] threadIt's good to ensure survival and utility of cool things such that Tragedy of the Commons doesn't spoil them.
The source for the backend portion is also available, https://github.com/localtunnel/server. Going to set it up shortly on my own personal box, and if it works smoothly I'll be able to present it as a self-hosted alternative to my employer.
SSH encryption is your "Free HTTPS"
Both tunnels are encrypted. While traffic analysis is still possible, the tunnels also obscure the details of each request; eavesdroppers only see the tunnels as a stream of encrypted data regardless of how many GET/POST requests actually happen.
If one side has a public address that can be directly accessed, the rendezvous server is not needed; just use one tunnel. The fact that we ever need a rendezvous server is part of the incredible damage IP Masquerading (private IPv4 addresses behind NAT) has done to the internet. Working around "party lines" is incredibly frustrating.
If you're setting up many forwarded ports, it may be easier to use a SOCKS proxy server (ssh option -D <local_proxy_port) instead of many "ssh -L" tunnels. The other side (-R) will be the same.
We have a /23. I've opened ports 7000-7010 to a few developers' computers, so they can easily share what they're working on when they want to.
With IPv6, anyone can do this.
For my use cases this outweighs the need for https--on the off chance I need to expose localhost to the web, it's usually for a quick prototype that's only up for a few minutes and doesn't require any sensitive info to be sent.
What's the configuration with the SSL? The cert DN name didn't match my assigned sub-domain and it wasn't a wildcard, so how did you make that work? I saw it's from Lets Encrypt, but it seemed instantly setup, so you're not requesting a new cert for each sub-domain, right?
thumbs up!