Remote access as never seen: Meet ShellHub Architecture

ShellHub Team

• 4 min read
Três pessoas jovens analisando o funcionamento de uma engrenagem.

Learn more and stay on top of the architecture of this remote access solution that is revolutionizing the Embedded and IoT market.

It is common when using new software that some doubts arise about its operation behind the scenes, especially when it involves critical data and the system’s remote access. Questions about security, quality, or even the structure of the software are recurrent. Speaking about ShellHub, its source code is open, which allows users to explore it further. But if you aren't a do-it-yourself person, then come on here. In this article, you'll discover how ShellHub works and why your devices are safe and protected with ShellHub.

Modern option to traditional SSH

The possibility of accessing any device from anywhere in the world is impressive, and that's why we created ShellHub. The idea came from the growing need to manage a device's fleet quickly and safely. To this end, we have a team with almost 20 years of experience in embedded systems, which considered all the requirements of physical or virtual machines, including the market demand for greater access, which is possible in traditional SSH solutions.

In the traditional SSH model, the connection between a client and a server works as follows:

The client connects to a server that has the SSH service running. On this server, it is necessary to release firewall rules and configure routing such as NAT. These layers make the remote access process hard, especially on a large scale, which is the case for most companies that develop embedded devices. Can you imagine doing this for 500 machines?

So, rather than opening up network ports and forwarding traffic individually to specific LAN devices, accessing them through a centralized point would be better. That's where ShellHub comes in. ShellHub is an optimized, simple-to-use, and secure software for remote access.

Understanding the Process

Before we get started, let’s see some basic concepts of ShellHub.

On one side, we have the client like a browser or an SSH client like “Putty” or SSH Native to Linux. In the case of the web browser, this one, in particular, is redirected to a Web UI on port 80. The firewall/router is set up to send traffic to the predefined static IP address and for the port number of the ShellHub server on the LAN, translating the network address as needed. So, ShellHub behaves like a midfielder on each connection, forming a secure SSH tunnel to each device. The devices have a ShellHub agent installed via Docker used to register them.

These components are exemplified in the diagrams below:

Image shows a user client at the top starting a connection on internet by command line or Web UI. At the middle a blue box representing Internet connected to another box representing ShellHub. Below ShellHub box, three devices are connected to ShellHub: a RaspberryPi, a laptop, and a PC.
Figure 1. ShellHub diagram core

Main Architecture

Now you know how ShellHub performs, let's go deeper into its architecture and understand the role of each component.

As we can see in the diagram above, ShellHub provides greater versatility by centralizing access to devices, which can be servers, laptops, industrial machines, trackers, IoT devices, single boards, or many others.

The image below details how each component behaves individually.

To exemplify the diagram below, imagine that you intend to access your device using a command line client (it can be through your machine's shell or another tool such as Putty) or using the ShellHub web interface.

This connection is made based on the HTTPS protocol (a network protocol that adds a security layer, fully encrypted) and the WebSocket. So, from the moment we start a connection, the server or machine we want to connect to opens a connection with ShellHub on port 443. This SSH connection goes through the HTTPS I mentioned before via WebSocket. At this point, we no longer need to release port 22, which is usually reserved. So even if this server is a virtual machine that you have locally (VirtualBox/VMware) with no internet access, it will still be able to be accessed because it is the one who opens the connection.

That's the trick that makes ShellHub so good at that. Let's check it out.

The image shows two computers representing clients in a private network starting a Websocket or an SSH protocol connection. In the middle, a box showing web UI, API, and SSH Gateway representing ShellHub. At the last, a computer and a single board are also in a private network representing devices that will be accessed by clients through a secure firewall tunnel.
Figure 2. User interaction with ShellHub service

Icing on the cake

To make the process even more efficient, ShellHub provides an identifier for each registered device, the SSHID.

SSHID is a unique address to identify a device on the SSH gateway specified in the following format: user@domain.hostname@server. It is nothing more than a technique applied to facilitate access. The SSHID closely resembles a conventional email address, so it's easy to identify who is the host/device user and the other information required to connect.

syntax explanation for remote access using sshid: user (device user) @ Domain (Organization domain in ShellHub) dot hostname (device hostname) @ server (Server address in ShellHub)
Figure 3. SSHID components description

All these components, in the end, make the “gear” work great, allowing you to access your device from anywhere in the world with no trouble. In addition, its architecture based on microservices makes the software much easier to develop, maintain and become scalable.

If you liked this article and are interested in ShellHub, I invite you to try it out and, if possible, share it with more people.

Your experience will never be the same.