One of the most common tasks in local and Internet networks is controlling a device remotely to carry out configuration, maintenance, or even file exchange operations. To accomplish these tasks successfully and securely is essential to use a communication protocol that makes sure your data is not violated or mutated. Luckily, there’s one that takes care of that, and it’s called SSH. In this article, we’ll give a brief introduction to the SSH protocol, the basics of how it works, and demonstrate how you can implement it in your future projects using your NetBurner devices.
SSH is an acronym for “Secure Shell”, and is a TCP application protocol used to make secure connections to a remote device in order to perform file-sharing or host configuration tasks.
This protocol was born as a successor to the Telnet protocol, which essentially serves to perform the same tasks as SSH. The only problem with Telnet is that the information was totally transparent during transmission, i.e., it had no encryption. This made it an excellent target for people who wanted to get your information. Using Telnet on the modern Internet is totally unthinkable because of all the security breaches it could cause.
In 1995, the Finnish technology researcher Tatu Ylönen created the SSH protocol, inspired by a password sniffing attack at his university. This protocol replaced text-based Telnet communication with a new one, emphasizing encryption-based security.
For a long time, its version of SSH was released free of charge, but a few years later, it was decided to start commercializing the protocol, thus giving birth to the SSH Communications Security Corporation.
How does SSH Works?
The operation of the SSH protocol is somewhat complex because it uses several encryption algorithms and multiple steps to ensure the security of your data. The good news is that you don’t need to know the guts of SSH to be able to implement it very quickly in your projects.
In this article, we aim to help you understand how it works at a high level so that you can use SSH without having to be a mathematical expert in encryption.
One of the simplest examples that abstract SSH operation quite well is to imagine the following scenario.
- You have a friend to whom you want to send some important documents, but you don’t want anyone to be able to intercept them on the way.
- First, ask your friend if he is available so that you can send him the files.
3. In case he answers yes. You share with him a list of the forms you prefer to send the documents. For example, a briefcase, a safety deposit box, a backpack, etc.
4. He responds with a list of how he prefers to receive the documents. If he doesn’t like any of them, the sending is interrupted.
5. If you both agree on one of the ways to send the documents, for example, you decided to use a briefcase, you’re ready to send your documents. You put your paper inside the briefcase and close it with a padlock that only you have the key to. You then send the briefcase to your friend.
6. Your friend receives the briefcase and puts a padlock on it that only he has the key to open and send it back to you.
7. You open your padlock with your key and send the briefcase back to your friend.
8.Your friend receives the briefcase, opens the remaining padlock with his key, and obtains the documents you sent.
As you can see in this example, if someone were able to intercept the documents during the transaction, they wouldn’t be able to see them since the briefcase would always have a lock on it.
Since it’s a protocol for sending “secrets,” I call it “sshhhhh”.
As mentioned before, this example is a very abstract way of how SSH works. However, it’s a good analogy of what happens. It seems to be a very complex process, but the protocol takes care of doing everything in a few microseconds and with high efficiency during the process.
The following section will give a more technical explanation of what really happens inside SSH.
SSH is a protocol that works with the TCP client-server model, so there’s a device that requests the connection (client) and a device to which you are trying to access remotely (server). TCP port 22 is usually used, but it can be changed depending on the required configuration.
Generally speaking, the SSH protocol can be understood in 7 stages, which allow the necessary steps to be taken to communicate encrypted data effectively and efficiently. Image 1 shows the communication flow during these stages.
The client requests to connect to the server implementing a TCP Handshake, usually through port 22. If the server accepts the connection, the process continues.
Identification String Exchange
The client then builds and sends to the server a packet containing:
- SSH Protocol version
- Software version
The server responds with its own identification packet, which contains the same information, but representative of the server.
Next, both the client and the server negotiate the algorithms for key exchange, message encryption, authentication code, and the compression algorithm.
The client sends the server a list of algorithms supported by the software, sorted in order of preference (the highest in the list are the most preferred). This message is called the Key Exchange Initialization Message.
Once the server receives this message, it sends back the same message with the list of supported server-side algorithms. The server will choose the first algorithm from the client’s list that it supports. If none of the algorithms used by the server and the client are compatible with each other, the connection will be closed and will not proceed to the next step.
In this stage, the secret key exchange is made using key exchange protocols, such as the Diffie-Hellman, to encrypt the data sent. In the case of SSH, one of the most common is the “Elliptic Curve Diffie Hellman” algorithm. These algorithms are basically complex mathematical equations that satisfy certain conditions, so obtaining encrypted information is very complicated unless you’re the intended recipient.
The process starts when the client creates a pair of ephemeral keys, a private one that only the client will have and a public one sent to the server in a message. Once the server receives this key, it creates its own pair of ephemeral keys, public and private. A new shared secret key is generated with these keys and the public key sent from the client.
Once the server has that key, it starts another stage called “Exchange hash”, using the key exchange protocol agreed upon during the previous phase. For this process, a message is created using as input:
- Client identification string.
- Server identification string.
- The payload of the client’s Exchange initialization key message.
- The payload of the server’s key Exchange initialization message.
- Server public key. This key is different from the one used in the key exchange algorithm. It’s one of a pair used in asymmetric algorithms such as digital signatures or certificates and is provided to the server by an admin or responsible party.
- Client’s public ephemeral key. This is the one sent by the client in the previous step.
- Server public ephemeral key.
- Secret shared key.
- Once the message is created, the server uses its private key to sign or hash the message.
The Hash is very important since it proves to the client that the server can generate a shared key based on the client’s ephemeral public key. It also allows the server to authenticate itself and assures the client that it’s the server it claims to be.
The server then creates a message containing the Hash, the server’s public key, and the server’s ephemeral public key generated based on the key exchange algorithm. This message is sent to the client.
Once the client receives this message, it uses the ephemeral server key and its private and public ephemeral key pair to create the shared secret key. Once it has this key, the client makes its own hash message with the same entries as the server.
The client verifies the server’s identity based on the digital signature or local databases. If the validation is not successful, the software used for SSH may display a message warning of this. It’s up to the user to decide whether to accept the connection. Once the server’s identity is taken, the client uses the server’s public key to decrypt the hash message sent by the server and compares it with the one created by itself earlier. If the value is the same, the server’s authenticity is validated.
From here onwards, the communication will be encrypted, but the shared secret key will not be used. Instead, it’ll be used as a base to generate six more keys, three on each side of the connection. Two keys are used for encryption from server to client and vice versa, two initialization vector keys that are nothing more than two random numbers to make the symmetric algorithm more robust, and two more for integrity from client to server and vice versa used as a digital signature.
At the end of this, the server sends a message to the client called “SSH Message NewKeys” and the client sends it back, agreeing between both parties that all data will be sent encrypted from then on.
Last but not least, the client sends a message to the server requesting user authentication. The server responds with an acceptance message, and it’s there where the user enters the username and password of the user who will log in to the remote server. If the user is successfully authenticated, a connection is then maintained where all communication will be through an encrypted and secure channel.
Although the username and password is the most common authentication method, it’s not the most secure because brute-forcing scripts can be used to guess your password. A safer way is to use SSH Keys, which authenticate the device based on keys that only the client device should have and should be kept secure.
SSH Clients for Your Computer
Now that you know how the SSH protocol works internally, here are a series of links so that you can use an SSH client using Windows, Linux, and Mac systems. You don’t have to bother with these are very easy and simple to use.
SHH at NetBurner
As you can see, the SSH process is complex, but it ensures the security of your data. The good news is that when you are dealing with SSH applications, the software you use will do all the dirty work for you, and you won’t have to worry about implementing all the intricate details.
NetBurner is no exception, and that’s why we have developed a series of examples using our SSH library that show you how to start run a server or client on your module. It’s included with our NNDK development kits, so you can integrate it into your embedded application at a low cost. Built with the SSH library developed by our friends at wolfSSL, there’s no easier way to add SSH to your project.
You can find a detailed list of NetBurner’s SSH examples along with a short description for each here. They provide a good base for your own project, whether you’re writing a server or a client application. Designed to be short, to the point, and easy to work with, they demonstrate the libraries core functionality, while also showcasing how flexible it can be. Along with their API documentation, you’ll be up and running in no time.
Useful links and References
Hopefully, this article will be helpful to all those who are looking to implement the SSH protocol on their embedded systems using NetBurner. We would love to hear your comments, suggestions, or ideas for new content.
Feel free to contact us directly with any questions or concerns. We’ll be happy to help you.