Show HN: Put Localhost on the Internet Instantly(localhost.run)
localhost.run
Show HN: Put Localhost on the Internet Instantly
https://localhost.run/
7 comments
Just tried it out, it works nicely. Congrats on the launch!
How does this work internally, though? How is ssh used for tunneling
How does this work internally, though? How is ssh used for tunneling
i use an amazing ssh library called asyncssh, altho I've had to go very low level in it to scale beyond a single instance so my code looks quite different to the examples.
ssh tunnels are a part of the ssh spec, like most of what you "see" when using ssh it uses an ssh channel. Every time a request comes in from clients I read (technically MSG_PEEK for those that love TCP) into the TCP stream to find the destination and match it up with an opened tunnel. on the free plan and port 80 requests to the paid plan this means reading up to the HTTP Host header, and on TLS this means reading up to the SNI headers. Once I have that match I create an SSH channel and wire up the traffic to flow back and forth.
You can try your own ssh reverse tunnel if you have a server on the internet, all you need to do is install an SSH server on it and then use the same command as you do to connect to localhost.run, but change my hostname for yours. You won't get the Host SNI level routing so this doesn't work as well for more than one user but it is an interesting exercise to see SSH tunnels in action when you control both ends of the connection.
If you want to dive deeper into the internals of SSH definitely give the RFC a read, https://tools.ietf.org/html/rfc4254#section-7.2 is the beginning of a tunnels journey. I know RFCs can be intimidating if you've not read them much, i felt that myself pre-localhost.run, but they're written concisely and unambiguously, and once you've gotten to grips with the writing style they're by far the best way to understand standards like SSH.
ssh tunnels are a part of the ssh spec, like most of what you "see" when using ssh it uses an ssh channel. Every time a request comes in from clients I read (technically MSG_PEEK for those that love TCP) into the TCP stream to find the destination and match it up with an opened tunnel. on the free plan and port 80 requests to the paid plan this means reading up to the HTTP Host header, and on TLS this means reading up to the SNI headers. Once I have that match I create an SSH channel and wire up the traffic to flow back and forth.
You can try your own ssh reverse tunnel if you have a server on the internet, all you need to do is install an SSH server on it and then use the same command as you do to connect to localhost.run, but change my hostname for yours. You won't get the Host SNI level routing so this doesn't work as well for more than one user but it is an interesting exercise to see SSH tunnels in action when you control both ends of the connection.
If you want to dive deeper into the internals of SSH definitely give the RFC a read, https://tools.ietf.org/html/rfc4254#section-7.2 is the beginning of a tunnels journey. I know RFCs can be intimidating if you've not read them much, i felt that myself pre-localhost.run, but they're written concisely and unambiguously, and once you've gotten to grips with the writing style they're by far the best way to understand standards like SSH.
I learnt a lot from this comment. Thank you!
Why would I use localhost.run over something like ngrok, or webhook.site?
heya good question!
there's a few players in this space and I'd encourage anyone to look around to find the one best suited to their workflow, they're all great tools.
I wrote localhost.run as a natural evolution from a SSH reverse tunnel I had running on an EC2 instance, I was using it to develop webhooks. I thought it was neat that I didn't have to download a client to use it so I opened it up to the world not long after.
webhook.site looks great, I've been using requestbin.com for years which is a similar tool. I'd place these in my pre-development toolkit, where I only want to see the shape of hooks rather than react to them. Once I start working on handling those webhooks tho I find it more useful to pull development back to my local development environment, and that's where a tunneling tool like localhost.run can speed up my feedback loop significantly.
I hope you too find it useful, please do tell me more about something you use it for in the future!
there's a few players in this space and I'd encourage anyone to look around to find the one best suited to their workflow, they're all great tools.
I wrote localhost.run as a natural evolution from a SSH reverse tunnel I had running on an EC2 instance, I was using it to develop webhooks. I thought it was neat that I didn't have to download a client to use it so I opened it up to the world not long after.
webhook.site looks great, I've been using requestbin.com for years which is a similar tool. I'd place these in my pre-development toolkit, where I only want to see the shape of hooks rather than react to them. Once I start working on handling those webhooks tho I find it more useful to pull development back to my local development environment, and that's where a tunneling tool like localhost.run can speed up my feedback loop significantly.
I hope you too find it useful, please do tell me more about something you use it for in the future!
Hey man, this is great. Also awesome to see someone using asyncSSH. I've been using paramiko in an app and wanting to transition to it. I think this has given me all the justification I need. Plus its a cool service!
hello, my name is Tom :)
I wrote localhost.run to help me quickly and easily work on webhooks and collaborate on web apps.
It uses the SSH protocol which the 3 main operating systems already have clients installed for. That means no signup or even a download is necessary, you can instantly to share something running on localhost.
I'm most often using this for reactjs apps which listen on port 3000 by default but you can change the port 3000 in that command line to any local port.
Please try it and tell me what you think. I hope some of you find it as useful as I have over the years.