4 ms·
This is interesting, but how does it work? By leveraging a STUN/TURN server? Can we connect on port 22? Actually, there is this link in the subtitle (and in th
by MayeulC 7y ago
This is interesting, but how does it work? By leveraging a STUN/TURN server? Can we connect on port 22?
Actually, there is this link in the subtitle (and in the readme, but only mentions "getting started", now "how does this work"): https://shellhub-io.github.io/ https://shellhub-io.github.io/ this should probably be the story link.
So, short answer to my question (though I had to read https://github.com/shellhub-io/shellhub/commit/fb0ebf10b12700e56ab470634d3c150cd3f34036 https://github.com/shellhub-io/shellhub/commit/fb0ebf10b1270... to understand it, the website wasn't enough):
* You host a TURN-like server somewhere
* You locally host an ssh server (see the above commit: using docker)
* When you ssh to the local server, the TURN server is contacted, and performs the handshake; your local server proxies to the remote one on the right port
This is an interesting proof-of-concept, but:
* I wish people would deploy ipv6 without (or with minimal) firewalls instead
* As with all TURN, doesn't work with symmetrical NATs
* This is a bit overkill. If I could ssh into the TURN server and have it reply with the right ssh command, it would work as well (need to be quick)
Given the above, this could be built into ssh: specify a TURN server (or plain ssh host) to negociate a port and have the client & server perform the handover.
The way I do NAT traversal usually is to setup a reverse tunnel between the target sshd and another server (initiated by the target host), which I then proxy/jump on with `-p`. Obviously this uses some of the server's bandwidth, hence my proposed offer to add something like TURN negotiation on the server. The intermediate server doesn't even need to be aware of this, if you can execute arbitrary commands.
I wish more applications were compatible with something like this. The Internet really is broken if we have to jump trough these hoops to get any p2p going. There might be a way to do it in a way that's transparent to the application, but we might need a new TCP for this. I wonder if Yggdrasil or GNUnet offer to solve that kind of issues over the current TCP network (making a VPN of sorts between the computers, but not firewalled/NATed).
- MayeulC 7y agoAlso, there are some third party services to reverse proxy to if you don't have your own server: https://serveo.net/ https://serveo.net/ https://alternativeto.net/software/serveo/ https://alternativeto.net/software/serveo/
- 0xdeadbeefbabe 7y agoYou only have two more wishes. That first one was good though; the Internet is a lot better now.
- tssva 7y ago"* I wish people would deploy ipv6 without (or with minimal) firewalls instead" Do you mean deploy IPv6 without NAT or do you truly wish people deployed IPv6 without firewalls?
- MayeulC 7y agoI am not sure I saw any IPv6-with-NAT deployment in the wild, which is probably a good thing. Then, yes, I really mean it. Or at the very least provide a way to punch holes trough the firewall from the inside, like UPNP does. The Internet is completely asymmetric in how users are expected to open connections nowadays, probably thanks to big tech. If I have a p2p chat app, I would like to be able to use it at my friend's place with his Wi-Fi without relying on external servers, for instance. Same for mobile networks: my carrier has deployed IPv6 on its network, but I have no mean to open ports to the outside, for SSH or similar. The abuses I can see without firewall are: * sending broken packets: there should still be a firewall rejecting invalid traffic * hosting servers on public Internet hotspots: yes, that could be an issue. But is it really? * incoming connections could drain battery a lot faster for mobile devices (including rejected ones). A remotely configurable firewall would be nice for these. * it would expose all sorts of services not meant to be exposed, or with security flaws, to the internet. How about we accept that this is an issue that needs to be solved at the root? You wouldn't empty the pond because your boat is leaking? Though I agree that blocking-by-default lowers the attack surface, not everyone wants it.
- Nextgrid 7y ago> sending broken packets Is this a big deal? The device can just discard it. > hosting servers on public Internet hotspots There's really no difference between someone hosting a server and streaming or uploading video on a social media platform. There are already ways to control or bill for data usage (some of which are stupid, like data caps), they will work just fine to control this behaviour too. > incoming connections could drain battery a lot faster for mobile devices I've used a SIM with a non-firewalled public IP for months. I haven't noticed any extra battery drain.
- 7y ago
- kbenson 7y agoI'm confused. SSH already supports a wide variety of port redirection, proxying and jump hosts specifically. If you have to run a local SSH server, you can just have the remote side connect to it with a dedicated keypair on start and proxy ports. Is it just making that a little easier to set up?
- JoeOfTexas 7y agoTURN is the solution for communicating around Symmetric NAT. STUN is used to determine the type of NAT a user has, which helps determines the connectivity method to use between endpoints. Connectivity can be direct to each other or must routed through a TURN server. IPv6 still uses NAT and Firewalls, which is a pain, but it is a reliable method of defense. Almost all Cellular Networks are on Symmetric NAT, so P2P games are always going to require a TURN server. However, almost all WiFi networks use Port Restricted NAT (a level below symmetric), or lower, which is still possible to make direct p2p connections. (I am working on my own Networking/P2P library for Unity, which is a painful process.)
- alanfranz 7y agoDoes ipv6 use nat, though? Firewalls for certain, but nat? Have you got an example?
- oarsinsync 7y ago> Since at least Linux kernel version 3.9.0 and using ip6tables since 1.4.18 also Network Address Translation (NAT) is usable. https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html