Rendered at 11:12:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
antoniomika 1 days ago [-]
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!
sish does get a mention: "Some only require a plain SSH client but rely on a specific SSH server, like sish.:
joshstrange 23 hours ago [-]
Thank you, I’ve been using sish for the past month or so to expose my dev severs over the network when it time to review changes. It means I can review from my second laptop or my phone as if I were sitting at the computer running the dev server.
duc_minh 1 days ago [-]
Thank you so much for this! I self-host sish and we used it extensively at my previous company for engineers to integrate with others.
toomim 1 days ago [-]
For this stuff, I'm most excited about https over iroh.
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".
Muromec 1 days ago [-]
>and then port-knock and form a direct connection to each other, perfectly encrypted.
so... ICE/TURN/STUN ? Sorry I forgot which one of them actually works, but they do work
flippingheck 1 days ago [-]
Yes, and TLS/QUIC/Wireguard all offer encryption.
What toomim is excited about is this combination of technologies, and that's more than just NAT punching or encryption.
1vuio0pswjnm7 19 hours ago [-]
"Iroh already runs public relays."
That's not "self-hosting"
Last I checked this project also automatically forwards traffic through their servers when direct connections fail
It's not even peer-to-peer
1vuio0pswjnm7 12 hours ago [-]
As indicated by the quote, I'm responding to the statement "Iroh already runs public relays."
AFAIK, the project does not claim these relays are only for testing
As such, the project is promoting something other self-hosting
The OP relates to self-hosting
bigbadfeline 17 hours ago [-]
You can run your own relay server, see "Setup Relay Server" below
Not perfectly, but good enough for port forwarding web interfaces through cgnat
flippingheck 1 days ago [-]
Where doesn't Iroh work well?
aliasxneo 2 days ago [-]
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.
If that's all that was necessary then I feel like a lot of these SaaS tools wouldn't be as popular. I suspect a lot of Tailscale's success is because wireguard is not easy nor does it solve the full problem space (i.e. discovery). With `tailscale serve` I can get a private HTTPS endpoint to my local machine in almost no time.
nagaiaida 18 hours ago [-]
presumably somewhat more like nebula
jamiesonbecker 1 days ago [-]
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.
The attack you mention is solved in the second part of the article.
jamiesonbecker 1 days ago [-]
I did notice that you tried to mitigate the risk, but why not just pick a high port rather than this complex redirection?
Your scheme is smart and creative but unnecessarily risky.
SSH can do remote listens to the world by itself, no second nginx needed, but sish or ngrok might be a better solution for the general case.
Anytime you punch holes, you're taking a risk, so make it as narrow as you can.
vbernat 1 days ago [-]
It's already using a high port. Forwarding a high port directly with SSH prevent exposing the service through a virtual host and provide HTTPS (but I didn't think of it until your mentioned it). And it would open the service to be discovered by enumerating all possible ports, like you mentioned in your first comment.
sish and ngrok are mentioned in the intro along with the reasons I didn't go this way (specific SSH server to run for the first and not self-hosted for the later).
This domain is crowded with solutions. I only explored that myself because the "free" solutions only requiring an SSH client were unreliable, including the free tier of ngrok (broken SSH tunnel).
zac-builds 1 days ago [-]
[flagged]
Tepix 1 days ago [-]
You could also use the SSH SOCKS5 proxy if you don't want to hardcode ports in your ssh config.
gonzalohm 1 days ago [-]
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)
1 days ago [-]
jagged-chisel 1 days ago [-]
An HTPS server always hands out its public key. Do you mean client secrets or something?
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?
pawel_nowak 1 days ago [-]
[flagged]
snehesht 1 days ago [-]
I'm working on something similar with userspace wireguard, will share it soon.
pbreit 1 days ago [-]
Instead of tunneling, why aren't there easier ways to develop and deploy to publicly accessible servers (for mere mortals)?
v3ss0n 21 hours ago [-]
Just install pangolin and call it a day
guessmyname 2 days ago [-]
If self-hosted, then why do you need a third-party service *.ssh.luffy.cx ?
benatkin 1 days ago [-]
You replace it with your domain.
Transformanshen 1 days ago [-]
This is what I needed, but I didn't know it
vdqtp3 21 hours ago [-]
Everything old is new again. Reminds me of patching apache 2.2 to properly support tunneling ssh over https with mod_proxy_connect and proxytunnel
superkuh 1 days ago [-]
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.
tredre3 1 days ago [-]
> Just host a normal server on your home IPv4. There's nothing to break.
There is a privacy aspect. For example you seem to have watched Meet Joe Black and Six Days Seven Nights recently. Do you care that we know that? Maybe not, but I can also see the porn you enjoyed.
1vuio0pswjnm7 19 hours ago [-]
"There's a privacy aspect."
But the OP made no mention of "privacy"
It refers to "self-hosted"
superkuh 1 days ago [-]
I don't understand how you would know that. If you mean those sites where you put in an ip address and get a list of torrents that IPv4 has been associated with then I guess you aren't aware that those things are wildly inaccurate in the false positive sense. Because of this I am not sure if you were just giving a made up example of information you might find on those sites, or if you actually checked my profile and pinged superkuh.com to get my ipv4 and ran it and got fake results. An IP address is not private info. It's how we participate with each other on the internet. In either case I'm not worried because I know those site's purported results don't mean anything. If you mean nation state level actors or the like, well, yeah. That threat model is a bit beyond this.
It is much more private to host on your static webserver and link your friend to http(s)://my.ip.goes.here/orwhatever.jpg than it is to use a third party corporate services that both establish third party doctorine of no assumption of privacy and who have a profit-motive to sell your info. Do it yourself and you have a legal assumption of privacy and no one's continued existence is dependent upon selling information about you.
jagged-chisel 1 days ago [-]
ISP ToS become an issue. Certainly depends on how rabidly one’s ISP enforces the rule …
esseph 1 days ago [-]
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.
DominoTree 1 days ago [-]
It seems like every day there's some new "expose your laptop to the internet!!!111" service (or protocol or methodology) that I have to block or otherwise disable at work.
Users and their agents are constantly trying to make all sorts of horrible things forward-facing, and what sucks is that there's not a comprehensive way to block this stuff categorically without severely impacting a ton of legitimate usage.
(And yes, we have _very_ easy sanctioned ways for users to deploy things onto actual managed hosts and make them forward-facing)
k7peak 1 days ago [-]
i think my ai found your article because it did 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
- 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".
so... ICE/TURN/STUN ? Sorry I forgot which one of them actually works, but they do work
What toomim is excited about is this combination of technologies, and that's more than just NAT punching or encryption.
That's not "self-hosting"
Last I checked this project also automatically forwards traffic through their servers when direct connections fail
It's not even peer-to-peer
AFAIK, the project does not claim these relays are only for testing
As such, the project is promoting something other self-hosting
The OP relates to self-hosting
https://github.com/rustonbsd/iroh-ssh/blob/main/CUSTOM_RELAY...
Not perfectly, but good enough for port forwarding web interfaces through cgnat
[1]: https://dntls.substack.com/p/the-new-internet
I stopped using Windows many, many years ago. The company behind it now runs a dubiously consensual "botnet" (C&C, RCE) called "Windows Update"
Dropbox as I understand it was a company that wanted people to store their personal files on someone else's computers
This is the antithesis of "self-hosting" which what the OP is about
Re Dropbox: https://news.ycombinator.com/item?id=9224
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
Your scheme is smart and creative but unnecessarily risky.
SSH can do remote listens to the world by itself, no second nginx needed, but sish or ngrok might be a better solution for the general case.
Anytime you punch holes, you're taking a risk, so make it as narrow as you can.
sish and ngrok are mentioned in the intro along with the reasons I didn't go this way (specific SSH server to run for the first and not self-hosted for the later).
This domain is crowded with solutions. I only explored that myself because the "free" solutions only requiring an SSH client were unreliable, including the free tier of ngrok (broken SSH tunnel).
Downside is that some browsers don't handle the certificates properly (especially on phones)
There is a privacy aspect. For example you seem to have watched Meet Joe Black and Six Days Seven Nights recently. Do you care that we know that? Maybe not, but I can also see the porn you enjoyed.
But the OP made no mention of "privacy"
It refers to "self-hosted"
It is much more private to host on your static webserver and link your friend to http(s)://my.ip.goes.here/orwhatever.jpg than it is to use a third party corporate services that both establish third party doctorine of no assumption of privacy and who have a profit-motive to sell your info. Do it yourself and you have a legal assumption of privacy and no one's continued existence is dependent upon selling information about you.
Users and their agents are constantly trying to make all sorts of horrible things forward-facing, and what sucks is that there's not a comprehensive way to block this stuff categorically without severely impacting a ton of legitimate usage.
(And yes, we have _very_ easy sanctioned ways for users to deploy things onto actual managed hosts and make them forward-facing)