tommyvan

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.

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!

Start a webapp, it can be a react frontend, nodejs, python's flask, ror, anything, listening on port 3000 and run "ssh -R 80:localhost:3000 [email protected]" on the command line. You'll get an internet accessible URL for you or anyone else to access your locally running app.

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.

Thanks for trying it and for such a detailed response!

That host check prompt is a SSH security feature, it will only ask you the first time to accept the key and after that it will only check that the key hasn't changed, to verify no one is impersonating my ssh server, and allow you in without a prompt if it is ok. It's kind of like how your browser expects a valid certificate signed by a certificate authority when visiting https sites, but without the certificate authority. In most cases accepting the first time means you will never be asked again. Certainly the check can be skipped as you described tho if preferred tho.

for port 2000 try this: ssh -R 80:localhost:2000 localhost.run The first port number needs to either be 80 or 443, and for most people 80 is the port they will use. the second port number is the port your local app runs on. https://localhost.run/docs/http-tunnels explains what 80 does and https://localhost.run/docs/tls-passthru-tunnels 443, but 443 is for very specific use cases.

Butterfly looks awesome! If i'm understanding what you're after you want to be able to run butterfly locally and give someone else an internet URL to connect to your butterfly server, right? I'm not clear on how authentication in butterfly works, I'd need to read more, but certainly you could do client x509 authentication with a TLS passthru tunnel (that's the 443 advanced use case I mentioned), altho I'm not sure if someone like letsencrypt does client certs, so you might need to live with a certificate warning in your browser unless you can get a CA signed client/server cert. Maybe butterfly allows other authn/authz methods tho, like username/password over http, in which case you could use a normal http tunnel and connect it to the internet. If I get a chance to try it I'll reply back, and you get it working before me pls let me know!

i'll make that clearer, thanks for the tip! to answer immediately tho, it's a similar shape, https://?????.localhost.run, and it is printed out when you run the command.

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, the 3 main operating systems already have clients installed for this, which means you can use it without signup or even a download to instantly to share something running on localhost.

If you want to try it now, start a webapp, it can be a react frontend, nodejs, python's flask, ror, anything, listening on port 3000 and run "ssh -R 80:localhost:3000 [email protected]" on the command line.

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.

I've been lurking on HN for years and I've found many awesome products on show HN with some great feedback given in the comments, so I'm now hoping that you can also let me know what you think about my product, maybe features you'd like to see, maybe even someone wants to know more about the SSH protocol and what else it can do.

does anyone know what happened to serveo BTW? As happy as i am to welcome peeps onto localhost.run it's sad to see peeps in this space disappear, especially peeps that like SSH as much as I do. I read a medium article about serveo after it disappeared that suggested you could choose your own stable subdomain. localhost.run used to work like this but I got hammered by phishing sites, almost got shut down by my registrar and my hosting provider. I wonder if that was it? Stopping phishing is, by far, the thing I've had to do the most work on.

A few years ago I wrote a custom SSH server to do exactly this, but for webhook development rather than tunneling to a pi. other peeps found it useful so it's turned into a bit of a side project. If you want to have a go before spending time on setting up your own server run "ssh -R 80:localhost:8080 ssh.localhost.run" to tunnel to localhost:8080, you'll see an internet accessible domain returned to your terminal.

I've seen a few servo refugees recently land on my service, https://localhost.run/ I didn't get to try serveo before it ended but I _think_ I do something similar, "ssh -R 80:localhost:8080 ssh.localhost.run" will give you an internet accessible address tunneled to localhost:8080.

I'm trying to source a windows 10 machine to test it on because I can't duplicate your problem on my development environment I'm afraid. Watch this space, I'll drop a reply once I've figured out what's up.

It's fixed, please try again

Oversight on my part, my bad. Currently it requires an SSH key to work. A quick fix if you want to try it out is run "ssh-keygen -t rsa" to generate a key pair and try again. I'll look into allowing keyless access this week. If you follow the twitter account you'll see a tweet when it's fixed.

yeah, that's the next item on my todo list. If you follow the twitter account from the website I'll drop a tweet when it's on https.