Self-hosted HTTP tunnels with SSH and Nginx

aliasxneo

This is one of the core things I've been working towards with DNTLS [1]. I love the idea of tunnels, especially for sharing between private parties. The SaaS providers (Tailscale, Cloudflare, etc.) have done a good job making it really easy on their infra, but it really blurs the line of "self-hosted" to me. Ideally we end up with solutions like this that can be run entirely without an intermediary. [1]: https://dntls.substack.com/p/the-new-internet

guessmyname

If self-hosted, then why do you need a third-party service *.ssh.luffy.cx ?

toomim

For this stuff, I'm most excited about https over iroh. - https://github.com/aflin/iroh-webproxy - https://github.com/n0-computer/iroh-proxy-utils No port forwarding. No public IP required. No special proxy to set up. Iroh already runs public relays. Your two computers will signal through those, and then port-knock and form a direct connection to each other, perfectly encrypted. We just need to define a new https:// url, like ... let's call it "irohttps://" maybe, so then you could contact my laptop with "irohttps://<hash>/path?query".

snehesht

I'm working on something similar with userspace wireguard, will share it soon.

gonzalohm

I don't have the code at hand, but I think it's better to just have a nginx server that only serves content if the browser has a specific certificate installed. That way you generate a key pair, share the public key with anyone that you want to share the content with and that's it. Downside is that some browsers don't handle the certificates properly (especially on phones)

Transformanshen

This is what I needed, but I didn't know it

esseph

While I do appreciate very much the "we already have the technology, let's just use it!" approach + the self hosting aspect, one of the downsides of self hosting without a proxy is having to expose your endpoint and likely having minimal defensive tools.

superkuh

I forward port 80/443 on my router to port 80/443 on my home LAN nginx webserver and point my domain name to my home IPv4. Then I put files in directories. It works great and has worked great for a couple decades. While the number of static nginx vulnerabilities that have come out since AI became good at coding has increased I still haven't run into one that applies to my simple static nginx setup. All this tunneling and secrecy and credentials is... well, it applies to some cases and I don't want to dismiss those. But it really doesn't apply to most human person's use cases. Just host a normal server on your home IPv4. There's nothing to break.

jamiesonbecker

This is wildly over-complicated and also has a bunch of footguns and security risks. For example, that very first NGINX section allows an attacker to direct their incoming traffic to any arbitrary listening port on localhost. They can even write a simple for loop in bash that would use curl to test all of the different ports. This also bypasses any firewall rules that you might have blocking traffic from the outside world. be very careful following the instructions in this article. Read the man page for SSH, and especially the remote forward section. https://man7.org/linux/man-pages/man1/ssh.1.html

antoniomika

A number of years ago, I created a fully open source (MIT) project called sish [0] that does just this. sish is a SSH server written specifically for tunneling. You get all of the benefits of SSH, but also automatic TLS, a web console of requests a tunnel has received, and various other features. You can also tunnel more than just HTTP(S). You can tunnel websockets, TCP connections, and even have internal alias connections for using ProxyJump within the tunnel. All stateless and all protected with SSH auth. If you’re not interested in self hosting, there’s a hosted version at tuns.sh [1] that has multi region support and a few other cool features (including UDP tunneling) as part of the pico.sh [2] membership ($2/mo). Happy to answer any questions in this space! [0] https://github.com/antoniomika/sish [1] https://tuns.sh [2] https://pico.sh

pbreit

Instead of tunneling, why aren't there easier ways to develop and deploy to publicly accessible servers (for mere mortals)?

soltanov

I like that the design composes existing tools instead of creating a new daemon, but what threat model covers leaked URLs, tunnel enumeration, forwarded credentials, and abandoned sessions?