Self-hosted HTTP tunnels with SSH and nginx

girlonthemoon | a day ago

huh this is pretty neat. i never thought of using nginx for this. (i use caddy for everything over nginx, though, so that's probably why.)

honestly since i have a pico.sh sub i'd probably opt for their tuns.sh service over setting this up, but if i didn't have access to tuns, i might've put in the effort to get this going.

tuxes | 21 hours ago

I like "solve problems with off-the-shelf tools".

The nginx auth logic is a bit fiddly for me to follow, but it looks like the generated URL includes a token (with a ye olde MAC) that lasts for 24h and authenticates the port?

If a port is reused for a subsequent tunnel, what stops the token from the old tunnel from being valid for the new tunnel?

vbernat | 17 hours ago

Yes, it's still valid. nginx has no way to know this is a different SSH session. Sometimes, instead of 0, I specify the port explicitly to reuse a previous one.

We could forward from an Unix socket instead, but the user has to provide a "unique" one. OpenSSH does not seem to support abstract Unix socket, so you also have to specify the full path.

tuxes | 16 hours ago

I suppose the risk is pretty low, especially for the common case where the tunnel creator is semi-trusted and the tunnel user is semi-trusted too.

We could forward from an Unix socket instead, but the user has to provide a "unique" one.

Rather than the tunnel creator providing their own unique string, could the tunnel service just pick a UUID?

That said, if the user provides their own unique string, valid tokens would remain valid across reboots (assuming the tunnel creator re-established the tunnel with the same unique string).

vbernat | 15 hours ago

Then, you need something else than OpenSSH on the server side. Or you could tie the forwarding nginx to the SSH session by running it as a command. You would also get access logs on your terminal this way.

loige | 14 hours ago

Love this kind of stuff! We often assume we need very specific dedicated software for each use case, while forgetting the unix philosophy of being able to easily combine smaller software that can do 1 thing really well!

Thanks for the great reminder and the neat solution!

creesch | 17 hours ago

Interesting, I did something somewhat similar a while ago with autossh. Though not with your authentication scheme and more with the goal of a persistent single tunnel so I can target specifically what gets exposed. Slightly different use case, though I'd say that for yours I would consider adding similar restrictions to the user and ssh key.

Roughly what I did is autossh like this.

autossh -M 0 -N \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes \
  -R 127.0.0.1:8080:localIP:8080 \
  vpsUser@vpsIP

With a dedicated user on the VPS and ssh key configured like this

restrict,port-forwarding,permitlisten="127.0.0.1:8080" ssh-ed25519 AAAA... comment

Then for authentication I simply had caddy do basic_auth since I didn't want to publicly expose the service (it was just for me).

whatever.domain.here {
        basic_auth {
                username $hash
        }

        reverse_proxy 127.0.0.1:8080 {
                flush_interval -1
        }
}

I had the autossh part wrapped in a docker container so I could easily spin it up in my unraid nas. But doing it by hand also works if it is just for testing purposes.

hwj | 14 hours ago

On OpenBSD you can skip the Nginx part with a PF rule:

pass in proto tcp to port 8080 divert-to 127.0.0.1 port 2441 label "self-hosted http"

I guess this works on other BSDs and Linux (with netfilter) too.

aae | 9 hours ago

I do this with caddy and rathole currently, but I might consider switching from rathole to ssh