SSH: the Swiss Army knife that protects nearly every connection in the IT world

Every time you log into a cloud server, every time you run a command on a remote machine, every time you push code to GitHub, a technology is working behind the scenes to keep everything secure. You do not see it, you do not touch it, but without it the world of modern infrastructure would simply collapse. It is called SSH, Secure Shell, and even though it is more than 30 years old, it remains the pillar of remote administration in the software world.

This article is a deep dive into SSH: what it is, who created it, what language it is written in, why platforms like GitHub use it as their main cloning method, and above all, why in 2026 it is still as relevant as day one.

What is SSH?

SSH stands for Secure Shell. It is a cryptographic network protocol that allows a user to securely connect to a remote system over an insecure network, such as the Internet itself. The name "Shell" comes from one of its most common uses: executing commands on the remote machine's terminal, as if you were sitting in front of it, but with the difference that every keystroke and every result travels inside an encrypted layer that no one can spy on.

Originally, in the 1980s and early 1990s, the standard tool for this was Telnet. However, Telnet had a severe problem: it sent absolutely everything in plain text, including login passwords. SSH emerged as the encrypted alternative that completely replaced it, becoming the de facto standard for remote system administration.

The origin: how Tatu Ylönen secured the Internet in 1995

The story of SSH begins at Helsinki University of Technology in Finland, in 1995. A young Finnish researcher named Tatu Ylönen faced a very concrete problem: at his university, an attacker had installed a network sniffer that captured student passwords when they logged in via Telnet. The only way to be safe was to avoid any unencrypted connection.

Faced with a lack of viable and free alternatives, Ylönen decided to build his own solution. In just a few months he wrote the code for the first version of Secure Shell (SSH-1). The goal was simple: encrypt all traffic so that even if someone intercepted the communication, they would see only unreadable data.

The response from the software world was immediate. SSH spread rapidly by the end of that same year, and by 1996 it had become a daily tool across the planet. The need for security on the Internet was so great that this protocol filled a gap that had existed since the birth of the network.

What language is SSH written in?

If we talk about the original implementation created by Tatu Ylönen, as well as the most popular one today, OpenSSH, the main language is C. The choice was not accidental. In the mid‑90s, C was the standard for UNIX systems, offered maximum control over memory and performance, and allowed direct interaction with operating systems.

Today the ecosystem has matured. The most widely used implementation is OpenSSH, an open‑source project maintained primarily by the OpenBSD team. It is written in pure C with a focus on security and simplicity. Moreover, because SSH is a protocol, there are implementations in other languages like Go or Rust, but the global reference remains the C implementation for its efficiency and portability.

SSH and software development: why do Git, GitHub and GitLab use it?

One of the most frequent uses, and one you certainly know if you are reading this, is cloning repositories via SSH. When you copy a project URL on GitHub or GitLab, you have two options: use the HTTPS URL or the SSH URL. The SSH version uses the Secure Shell protocol to authenticate you and transfer data without exposing your password on every command.

The mechanism is very simple and robust. First, you generate a pair of cryptographic keys on your local machine using the ssh-keygen command. You upload the public key to your GitHub or GitLab profile, while the private key remains on your hard drive, protected.

When you run a command like:

git clone [email protected]:username/my-repository.git

Git uses the SSH client to initiate an encrypted connection. Since your public key is already registered on the server, the system authenticates the user without sending the password over the network. The commit, branch, and file data travel inside the encrypted tunnel. This is why, once you set up SSH, you can run git push as many times as you want without having to type credentials manually. It also adds an extra layer of security: even if someone intercepted the traffic, they could not obtain your password or clone your repository without physically possessing your private key.

The transition from SSH-1 to SSH-2: a necessary evolution

Not all of the history was perfect. The original version of SSH released by Ylönen, known as SSH-1, contained some design weaknesses that became evident over time. Security issues with data integrity and vulnerabilities in its key exchange algorithm led the industry to call for a complete revision of the protocol.

In the late 1990s and early 2000s, the IETF standardized SSH-2. This new version was completely incompatible with the previous one, but came with substantial improvements: a much more robust Diffie‑Hellman key exchange, stronger public‑key authentication, and integrity protection via message authentication codes (MACs).

Today, SSH‑1 is completely obsolete and discouraged. Any modern server or client uses SSH‑2 exclusively. OpenSSH, for example, does not even compile support for SSH‑1 by default in its current versions.

Why is SSH still king in 2026?

If SSH was invented in 1995, how can it still be so relevant in 2026? The answer is that the technology has evolved alongside the needs of the industry. It is no longer used just to log into Linux servers from the 90s, but to manage entire cloud infrastructures, containers, and orchestration.

However, the passage of time has also brought challenges. In 2026, Linux kernel vulnerabilities have become a growing concern. Vulnerabilities like CVE-2026-46333, discovered recently, allowed local attackers to steal SSH private keys by exploiting a flaw in the Linux kernel's ptrace access check. What is most alarming is that this flaw had been present in the kernel since November 2016, almost nine years.

The way keys are managed has also changed. The concept of "SSH key sprawl" has gained traction: hundreds of static SSH keys scattered across thousands of servers, with no expiration or control. Security experts in 2026 recommend abandoning the permanent key model and adopting short‑lived SSH certificates or ephemeral access mechanisms.

Currently, paths to modernize SSH without breaking compatibility with decades of deployed infrastructure are being explored. The use of FIDO/U2F cryptographic tokens has gained ground, although in 2026 critical vulnerabilities were discovered in the implementation of these tokens within OpenSSH (CVE-2026-39831). Alternative tools like Teleport, which add auditing layers and temporary authentication, have proliferated without replacing the core of the protocol.

The SSH paradox: a success that must keep evolving

SSH's strength has always been its conceptual simplicity. One protocol, one port (port 22), one key pair, one encrypted connection. That simplicity has allowed it to survive three decades of technological change. But its success is also its Achilles' heel. Now that SSH is everywhere, key management has become a scaling problem.

The ecosystem around SSH in 2026 is much broader than Ylönen could have imagined in 1995. Solutions such as Teleport, Warpgate, and JumpServer offer bastion hosts and access brokers that rely on the SSH protocol to provide just‑in‑time access, session video recording, and manual connection approvals.

Final reflection

When you use SSH, you are not just running a command. You are using a standard designed more than 30 years ago by a developer who refused to accept that passwords should travel in plain text. His creation completely changed Internet security and remains, today, the most reliable tool for securely connecting humans and machines.

Whether you are cloning a repository, managing a container in production, or simply accessing your personal test server, SSH is there. Quiet, robust, and more relevant than ever.

References

SSH Communications Security. (n.d.). Tatu Ylönen - Inventor of SSH Protocol. USENIX. https://www.usenix.org

CyberArk. (2025). What is Secure Shell (SSH) & How Does It Work?. https://www.cyberark.com

GitLab Documentation. (2026). Use SSH keys to communicate with GitLab. https://handbook.gitlab.com

CoreUI. (2025). How to clone a repository with SSH in Git. https://coreui.io

TechTarget. (2022). SSH2 vs. SSH1 and why SSH versions still matter. https://www.techtarget.com

Qualys Threat Research Unit. (2026). CVE-2026-46333 (ssh-keysign-pwn) Linux kernel vulnerability. Canonical.

SSH Communications Security. (2026). From prevention to ephemeral security. https://www.ssh.com

HashiCorp. (2026). The 2026 Linux security threat landscape and strategic defense pillars. https://www.hashicorp.com

VulDB. (2026). CVE-2026-39831 - OpenSSH FIDO/U2F vulnerability. https://vuldb.com

Wikipedia. (2025). OpenSSH. https://en.wikipedia.org/wiki/OpenSSH