2

All, How bad (or good) an idea would it be to utilize SSH tunnels from my sensor gathering remote computers (imagine an "industrial" Raspberry Pi-like device w/ Linux) to my centralized server (also Linux) that ingests the sensor data?

SSL certificate management can be a real pain and SSH is already required for our remote maintenance operations. Therefore it seems that extending SSH to provide tunnels to secure our two-way sensor to server comms would be a reasonable approach... or not?

We could have hundreds to potentially 'low' thousands of these machines connecting across our corporate LAN which will consist of a VPN segment to a telecom provider's private APN for the cellular connectivity leg. I'd expect resource utilization could be the biggest challenge at some point for the server, as there are probably a number of proxy solutions for managing SSL/TLS connections while SSH... probably not. What else should I be considering?

I'd be interested in hearing the experts opinions on the pros/cons of utilizing SSH tunnels for securing the comms between many remote "field" devices and a centralized server.

The data would be submitted every few minutes (let's use 5 minutes as an example) so it likely makes sense to keep the tunnels persistently open to avoid constant key exchanges and the associated processing costs and bandwidth overhead.

EnemyBagJones
  • 135
  • 4
  • 2
    How frequently you want to gather data? Will the "tunnel" be open "all the time"? How does the network look like? Is it over Internet? – Jakuje Apr 21 '16 at 16:33
  • @Jakuje, thanks for pointing out the areas needing additional clarification. I've updated my question accordingly. – EnemyBagJones Apr 21 '16 at 17:38
  • 1
    If you control both ends, what's the problem with SSL certificate management? You can create your own CA, and put signed certs with long expiration times on the client end. How is this any harder than managing ssh key signatures? – Steve Sether Apr 21 '16 at 18:18

2 Answers2

2

Using ssh instead of https will probably cause some maintenance headaches. There could be a firewall between your devices and the server (say at the APN exit or at your company's entrance) that will block ssh access. Even if there isn't, allowing ssh access to the server means, well, allowing ssh access to the server with all the risk that opening up shell connections entails. Any logging of the ssh port to look for bad actors is going to be completely overwhelmed by the IoT devices' connections. Presumably you're going to lock down the ssh access pretty tight, but any mis-configuration (like to solve an unrelated problem 3 or 4 years from now) will let someone into your server. Use https instead with a server that listens only for specific reports and throws away everything else and you can defend your server better.

Also SSL has a lot of management utilities already built in, like being able to revoke certificates. If you try to use SSH you'll just end up DIYing a lot of this as you realize you need those features; just set it up right the first time. Whoever comes after you (or you in 5 years when you get called back to maintain this system) will thank you for it!

  • 1
    Thanks @drewbenn. I think that nicely explains the drawbacks, and while I agree with your comment above that this skirts with being an implementation challenge, not a security one, I think your points on the potential for security holes to when configuring/maintaining SSH and potential masking of "bad actors" are relevant. – EnemyBagJones Apr 21 '16 at 21:28
0

If all you are doing is sending a simple one-way report every five minutes from the sensors to a central server, then I agree with the previous advice to avoid full-blown SSH connections. For what it's worth, however, I've chosen to enable SSH connections in the portable scientific instrument that I'm currently working on. We want the option to shell into a device when a customer calls our help desk, with the ability to make changes to the device if necessary. SSH is a good fit for that sort of complex two-way communication.

William Dye
  • 1