A random argument

As I understand it, the hub establishes a persistent network connection to the cloud, which is what is used for remote access. Why would it be impossible to tunnel ssh through this connection?

1 Like

There is a persistent tunnel connection from the hub back to the cloud services. It's very likely this is using SSH as the protocol for the tunnel connection. SSH is used for more than just "shell access".

1 Like

The persistent connection is a HTTPS/SSL session I would assume, it certainly isn’t impossible to tunnel ssh over a HTTP session, but I can’t imagine that is how someone would implement it. I would buy that the hub polls a Hubitat cloud api endpoint for “jobs” and then runs those jobs. But that’s a distinct difference from an interactive shell and certainly a SSH tunnel. A full on ssh tunnel implies other functionality like port forwarding.

Yeah I disagree with this that it’s “very likely” but I have no inside knowledge. A ssh tunnel over an SSL connection like the hub establishes just doesn’t sound like a plausible way that a product would phone home. I’ve never heard of any product that implements behavior like that, but I guess we can go back and forth all day discussing something we have absolutely no inside knowledge about...

one wouldn't use ssh over an ssl tunnel....

That’s exactly my point. I haven’t looked in a while, but I’m pretty sure the hub establishes a standard ssl session to the cloud. There’s certainly a remote possibility someone would be running ssh over that but I would doubt that is what is happening. Like I said, the architecture I would expect is a cloud based API that the hub checks in with where one of those APIs might be a list of jobs that the hub should run - such as log collection. But that’s just a complete guess (just like suggesting the company can login and remotely interact with our hubs via ssh...)

Not sure why I even waded into this thread, I should have known better...

Yeah... me too. :slight_smile: I had said I was done so now I am.

2 Likes

Perhaps so someone could advise you to lookup "reverse ssh"?

1 Like

Yup - during the covid-shutdown, I've made heavy use of reverse ssh to access my desktop. I even run AFP over that to mount desktop drives at home.

1 Like

Man I wish I understood why people felt the need to be so rude sometimes... I'm honestly not sure how you've gathered that I don't have comprehension on the difference between a SSH session and a SSL/TLS based session. They are two distinct and different network protocols, with different ways of establishing a secure network session. The way in which key exchange occurs is generally a slightly different process. Unless Hubitat is doing some wild, it is plainly clear on a packet capture a TLS session being established vs SSH negotiating to establish a connection.

Example:

TLS:
image

vs

SSH
image

I routinely make use of SSH in my professional life and I'm fully aware of its capabilities, including its abilities to both do remote and local port forwarding and in fact I do make use of both quite frequently.

With that said, like I previously mentioned I have not recently sniffed the traffic from the hub, my assumption is they establish a TLS based session back to the Hubitat cloud over the standard HTTPS port of 443. No one has said otherwise other than to say "persistent network connection back to the cloud" (which doesn't necessitate a SSH connection) so I'm assuming this is true. Reviewing the DPI stats from my firewall, neither hub reports making SSH based connection, which further gives me some confidence in what protocol is in use to communicate with the cloud.

So unless the hub is doing something wild, establishing a plain old TLS session (via something like stunnel) and then separately establishing a SSH session over that TLS session, we aren't talking SSH. Unless someone here has MITM the TLS traffic and broken encryption to see what goes on inside of it, it's a fairly safe bet to say the hub is not making any sort of SSH connection, reverse or otherwise.

1 Like

I don't think there's anything nefarious going on with the Hubitat Hubs. If you want to interface to cloud services, like Alexa or Google Home (or countless others), your Hub is going to need to be making connections outbound and receiving information about devices being controlled by the cloud service.

I'm working on trying to get a memory leak problem on their end fixed, and they're not asking to ssh into my hub. Rather, they're asking me to turn on logging manually at my end, gather data on my end, and post the result in the forum.

It would be a lot easier for them to just log in and get that information on their own, if they had that ability.

Plus, the lack of requirement for cloud usage by the Hubitat is a selling point. You think they want to ruin their reputation for being a more secure kind of hub?

Just my $.02.

8 Likes