ShellHub enables teams to easily access any Linux device behind firewall and NAT | Hacker News Reader

ShellHub enables teams to easily access any Linux device behind firewall and NAT

github.com

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/ 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/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).

Also, there are some third party services to reverse proxy to if you don't have your own server: https://serveo.net/ https://alternativeto.net/software/serveo/

You only have two more wishes. That first one was good though; the Internet is a lot better now.

"* 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?

I 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.

> 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.

Keep in mind, my point was that the possible trade-offs seemed worth it to me.

> Is this a big deal? The device can just discard it.

I read someone around here who stated this was the original goal of firewalls. The device could indeed discard it, but having dedicated hardware for that check could avoid denials of service.

> I've used a SIM with a non-firewalled public IP for months. I haven't noticed any extra battery drain.

I am a bit jealous: mine is firewalled. Such extra drain could happen if you had, say, an ssh server on it, and someone was trying to bruteforce its way in, or if you had an http server with a few crawlers hitting it, but those are theoretical issues. On the other hand, you get much easier push notifications (too many of those, and the battery starts being an issue again).

As long as you don't have something overly nasty like symmetric NAT everywhere, p2p is possible over UDP.

Blocking-by-default is absolutely necessary given the sorry state of affairs for software these days.

While it would be nice for that to be optionally disabled for specific people/cases, these options already exist, but come with a high dollar barrier to entry. Ideally, it shouldn't come at a high cost.

I'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?

TURN 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.)

Does ipv6 use nat, though? Firewalls for certain, but nat? Have you got an example?

> 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

For a number of years now — I think I got the idea from a HN comment — I've just been exposing ssh as a Tor hidden service. Really easy to set up, and I can donate a few kbps to the tor network.

Is it just me or documentation is lacking? What is server, what is device? In both introduction and "getting started" it is mentioned that "The ShellHub SSH gateway is a modern SSH server built using the microservices design pattern" but does it really bring any information about what exactly am I doing by generating keys, creating users? How is it really an improvement over let's say VPN? Maybe a simple image/scheme would help to understand all the hierarchy and what exactly is happening where?

> but does it really bring any information about what exactly am I doing by generating keys, creating users?

The keys are used by ShellHub as "ssh host keys" that ensures you are connecting to the right server.

The users that are created by 'add-user' script are used to login in the Web UI running on port 80.

> How is it really an improvement over let's say VPN

The improvement is that you don't need to run your own VPN server and setup the client on every host :)

> Maybe a simple image/scheme would help to understand all the hierarchy and what exactly is happening where?

I fully agree with you

> Maybe a simple image/scheme would help to understand all the hierarchy and what exactly is happening where?

Please see https://shellhub-io.github.io/introduction/

A security critical daemon running in docker?

Given docker abysmal security track record?

DigitalOcean doesn't charge for their floating ips, so it's a fairly economical way to traverse NAT. $5/month total assuming you keep the floating IP assigned. Fairly simple with wireguard and port forwarding via firewalld or iptables.

Is this just another client that wraps SSH and provides a Web interface?...

Or am I missing something?

It seems to also include a gateway component you run on a public machine that brokers ssh access to machines behind nat.

So you could piece together your own with ssh tunnels, or a VPN, and a web terminal. I assume the appeal is that's done for you.

The docs are pretty light though, with a lot of typos. It doesn't inspire a lot of confidence that it's done in a secure way.

Not a bad idea, I have seen some simular but for the love of god why the docker dependancy ?

Any stripped down version ?

Let me rephrase that, I'd like to test this out, maybe even use it, but I don't want docker near my machine..

Why the hate for Docker? :-) As I wrote in another post, using a Docker in this case is a form of packaging, which is reasonable for a young project. Of course, ideally (and/or in the long-term), one would use something more specific, like distro-based packages or snaps/similar.

I don't have a hate for Docker, its really useful for certain things, but with a project like this I would preffer to run it myself without th docker scafolding and hand holding, I would like to go straight in here and play around.

It's just a preference I guess, but it's time consuming now to go and extract the docker fluff for me.

> which is reasonable for a young project

I would argue a more mature project would benefit more from stronger versioning management though.

> Not a bad idea, I have seen some simular but for the love of god why the docker dependancy ?

ShellHub is built using the microservices design pattern, meaning that multiple small, isolated services. Docker is an excellent tool for managing and deploying microservices.

I'm open for suggestions and other options.

We need a way for software to declare its runtime dependencies. This product must use some sort of running process on the public internet, and yet there's no mention of it in the readme!

Runtime dependencies are a matter of packaging. Does this differ from your requirement(s)?

In this case, packaging is in the form of a Docker image. It's definitely suboptimal, but for a young project, that's reasonable.

The ports exposed are:

80 - web ui, http api

1883 - mqtt

22 - ssh

I will add this to documentation, thanks!

Due to the amount of messages I've received about ShellHub I've created a channel on Gitter (https://gitter.im/shellhub-io/community)

You could also use https://ngrok.com/

its worth noting this, as well as shellhub, cannot get around Bluecoats javascipt clickthrough transparent proxy, which imo would be a serious win.

Neat. This looks like a self hosted version of AWS SSM/Systems Manager + Session Manager Plugin

Reply on news.ycombinator.com