Comment by purplehat_ | Hacker News Reader

Comment by purplehat_ | Hacker News Reader

Parent Full thread

i'm trying to understand how outer shell works here. on the website you give the following as your motivation:

> Apps like Jupyter and Tensorboard are not typically visible to standard web browsers if they’re running on remote servers, because it would be terribly unsafe to let the whole internet touch this app. Instead, they run on a local port on the server, which your computer can’t access directly.

> Classically, to get access to these, you had to open a new terminal and run:

> ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &

> ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &

is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.

if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.

all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?

I think there are different clusters of people who use servers, SSH, etc.

I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer.

For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting!

And, to me, this just feels like one of the fundamental things that could exist; it's like a graphical operating system, but remote-first.

I still don't get it. Isn't this what X11 forwarding is for?

It's too slow. I mention this in the video at 1:20 - 1:50.

I guess it saves you the hassle of dealing with reverse proxies and TLS certs if your use case is "userbase is 1 person and it is me, and i only access services from a desktop os"

Ever since I started using Caddy, doing that has been soooo easy.

Download the binary, make a Caddyfile

  myservice.example.com {
   basic_auth {
    admin some_password_hash_here
   }
   reverse_proxy :3000
  }

And then just "./caddy start"

Caddy can also proxy to unix sockets !

I just use https://tuns.sh which has a handy bash script to make the ssh tunnel simple

does this work with multiple caddy servers? ie can you bind multiple caddy servers to port 80/443?

You can have multiple configs in a single Caddyfile and reload when you make changes, and it'll just route them as you wish, e.g.

domain1.com -> service on port 1234

domain2.com -> service on port 5678

domain3.com -> serving a file directory.

And then you still access domain1.com, domain2.com, domain3.com on port 80/443

You set up multiple services behind a single caddy reverse proxy

Btw, if you find yourself sending a lot of ports over ssh, you can also consider the option of having ssh start a socks5 proxy

ssh -D 4711 -q -C -N user@host

sets localhost:4711 up as a socks5 proxy you can tell your browser to use

...

A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)

HTTP basic auth is not secure.

basic auth is secure, if used in combination with TLS.

Unfortunately, that only takes care of one of the vulnerabilities that comes with basic auth.

As basic auth sends the header for every single request, it is also vulnerable to CSRF attacks.

My typical use case for SSH port forwarding is to rescue a network from some kind of configuration failure.

Reply on news.ycombinator.com