> ssh -R 8080:localhost:8080 my.server.com
and have Caddy webserver running on my server (my.server.com) which is configured to proxy any requests to localhost:8080. It adds LetsEncrypt and makes sharing local web projects easy.
Multiple upstream sites are supported with ease as well as multiple exit node domains. If SSH is working for your use-case, then I'd say stick with it.
At first I did not like it, and responded like others, over kill for something many people can do (or are doing) without the aid of a fancy tool like this. But then I realized trying to covey to others who are not system programmers how to setup something and realized I would rather spend my time doing something else and just point them to a tool.
Good job on this!
Some sort of tooling to point "this machine to this VM" becomes needed.
Then for full stack development it is even harder, as the app has to have this endpoint injected into it.
It is all possible, just a pain. Writing a mobile app (https only!) that talks to a service I am writing has a rather annoying set of minimal requirements to get up and running. (This may be why Firebase Functions are so popular, super easy to go from nothing to deployed endpoints in just a few minutes.)
I don't think these tools are really claiming to sell anything fancy that you can't fairly straightforwardly do yourself - what you're buying is convenience (saved time and focus) - just pay for this tool and you're ready to go, within minutes.
Then I found out how easy it was to set up ssh reverse tunneling. Sshd + systemd turned out to be all I needed for a pretty stable and persistent connection from anywhere. I was so satisfied to find that the most common tools out there could already handle this. Yay!
1. Don't require installing a local client, use something that is installed almost everywhere: ssh
2. Use a protocol that is already great at multiplexing: ssh
3. Supports authentication using PK/password auth: ssh
4. Completely opensource
Nothing crazy or flashy, just simple and does the job.
Also, let's learn from our history: https://news.ycombinator.com/item?id=9224
These projects really need to consider plain TCP connections. It's a deal breaker for me.
My company installs ngrok on our embedded devices. When there is an issue, they connect it to the internet, type a keystroke, and I'm in.
You can also use ngrok1, which you can host yourself. It's got the features you'd need. This would get around firewalls.
Disclaimer: I work for gravitational but not on teleport.
This has saved me and my customers so many times.
I'm a bit curious about the choice of websockets as a protocol over the tunnel, though. Why is "tunnelling plain (non-HTTP) traffic over TCP" a non-goal? What's the benefit over just tunneling the HTTP traffic over a reverse SSH tunnel or similar?
EDIT: Maybe it's just a question of the author finding websockets "good enough" (despite performance overhead) and wanting to keep the scope small with a single implementation that isn't really going anywhere. Here a suggestion on using WebRTC instead of Websockets: https://github.com/alexellis/inlets/issues/49
> Thanks for the suggestion. I'll look into webrtc when I get time, but for the time-being I think web sockets are going to be the way inlets works.
A decade ago we used another solution which seemed to work well enough: Developers had a Unix accounts on a Linux server. Their workspace was mounted as a remote filesystem. Interactive console access was available via SSH.
Inlets seems to still require a remote Linux server, but seems a like a more complicated way to solve the problem.
By using a shared server, we didn't need maintain container image to keep laptop environments sync'ed. If we wanted to upgrade the development database version, we upgraded the DB once on the shared server and everyone had the new version immediately.
I've used ngrok before and it's a great solution for quick tests. I guess this is an open-sourced version of that.
I'll bookmark this in case I have this need in the future.
Simple and works well
It'd be great some of the folks commenting to try the project and then bring some feedback via GitHub, Slack, Twitter etc.
What did you like? What would you like to see next? What can be improved?