What’s secure shell (SSH)

“A bit of history is good for Impressing your friends at lunch!”

Telnet was one of the earliest communication protocols existed to communicate between your host machine(the client) and remote servers. In the early days, communication mostly happened within closed networks like universities or research campuses, where administrators could control security. This worked fine when the networks were private, but as the internet grew, so did the need for security!

protocols – set of rules to be followed to achieve something

In those early days, any information sent from your host machine(the client) to a remote server was transmitted in plaintext, meaning that the data could be easily read by anyone with access to the network. As the internet expanded and more communication started happening over public networks, it became increasingly risky. Bad guys/girls could intercept and read your data with a tool called a packet sniffer, which is definitely not a good thing.

The Birth of SSH

In 1995, Tatu Ylönen, a Finnish researcher, was facing a serious security problem—a password sniffing attack. To overcome this, he realized that encryption could provide a solution. By using encryption, he discovered a secure connection can be made and protect his sensitive data while it was in transit. This led to the creation of SSH (Secure Shell)

Think of SSH as the “secure tunnel” for communication between two systems. When you connect to a remote server using SSH, all data transmitted between your computer (the client) and the server is encrypted, ensuring that even if someone intercepts the data, they won’t be able to read or manipulate it.

Any data you send or receive over SSH will be converted into small pieces called packets.

What’s in a packet?

When you initiate an SSH connection to another machine, the first thing that happens is the establishment of a TCP connection. Once the connection is up, SSH breaks down the data into small units called packets.

It’s up to the client to choose the communication medium—the default is TCP, but SSH can also use other methods such as UDP, serial connections, or even VPNs.

Think of SSH as a bus that securely transports data, but it needs a road to travel on. This is where TCP comes in—it’s the “road” that provides the pathway for SSH to deliver the data securely.

Each packet is not just a chunk of data; it carries essential information to ensure it reaches the correct destination safely. You can think of each packet like a sealed envelope containing the data, but also with extra details about where it’s going and how to get there.

Packet Size – The total size of the packet, including all parts (4 bytes)

Padding Length – A small value that tells how much padding is added at the end (1 byte)

Payload (actual data) – The main content being sent/received like text, images, commands

Padding – Extra random data added to make all packets the same size, improving security and preventing attackers from guessing what’s inside

Message Authentication Code – A security check to ensure the packet hasn’t been tampered with while traveling. It’s like a digital fingerprint to verify authenticity

The Padding Length and Padding Data are random bytes added to the packet to ensure that every packet is the same size. This makes it harder for attackers to determine the contents of the packet, as the padding creates uniformity and adds randomness. It’s like adding “fake” content to a message to disguise its true size and nature, helping to protect the data from being easily identified or tampered with.

Encryption and Decryption of Packets

When the data is ready to be sent, the entire packet (excluding the packet size and MAC) gets encrypted using a chosen encryption algorithm. The encryption and MAC algorithms are selected by the client and server at the beginning of the SSH session. These choices determine how the data will be scrambled to ensure privacy and integrity.

At the receiver’s end, the server or client decrypts the packet, checks the MAC to ensure it’s intact, and then reads the payload. This process happens for all the packets exchanged during the session.

Why Are Some Parts of the Packet Left Unencrypted?

You might be wondering why the packet length and MAC are left unencrypted. The reason is that TCP (which is used for the transmission) needs to know the size of each packet to properly route it. The MAC is also needed to check the authenticity and integrity of the packet, ensuring that it hasn’t been tampered with during transit.

So, while the payload (the actual data) is encrypted to protect it, the packet length and MAC are left intact to allow the system to ensure everything is in order and hasn’t been altered.

Final Thoughts

In a world where data can be intercepted and tampered with, SSH provides a much-needed solution for secure communication. By using encryption and carefully structured packets, SSH ensures that your data stays private and untampered with—even when transmitted over insecure public networks.

SSH is an essential tool for anyone who needs to remotely access systems or transfer sensitive data across networks. It’s the secure tunnel that keeps your digital life safe.

In the next posts, I’ll dive deeper into how SSH is used with Git, Remote server management, tunneling & multiplexing