Secure Shell

Many computers don’t sit on a desk, but in large data centers, far away from the person who is supposed to operate them. Secure Shell, or SSH for short, is the usual method for controlling such a remote machine anyway. You type commands on your own laptop, and the remote machine executes them and sends the result back. Everything that travels over the internet in the process is encrypted: it is transformed so that outsiders only see unreadable data gibberish. Without this protection, anyone eavesdropping on the connection could read passwords and commands. The name comes from the fact that a shell is the program that accepts typed commands — SSH is thus the secured version of that.

Why servers could hardly be operated without SSH

Before SSH, there were programs like Telnet that could do exactly the same thing, but without any encryption. Back then, a password was sent through the network in plain text. Anyone who intercepted it somewhere along the way immediately had full access to the remote machine. Since the 1990s, SSH has therefore practically completely displaced these programs.

Today, almost the entire operation of websites, databases, and AI systems depends on this access method. When a company trains an AI model on rented graphics cards, those cards sit in a foreign data center. The developers never see them. They connect via SSH, start the training, check the progress, and download the results.

Precisely for this reason, SSH is also a popular target for attacks. Whoever takes over a server’s SSH access controls the entire machine. Attackers automatically try out passwords around the clock. An SSH server that sits openly on the internet often sees thousands of such attempts per day.

Key pairs instead of passwords

SSH works on the client-server principle. The client is the program on one’s own computer, the server runs permanently on the remote machine and waits for connections. When establishing a connection, both sides first negotiate which encryption method they will use. Only after that is the connection secure does the login get checked.

For logging in, one rarely uses a password, but usually a key pair instead. In doing so, you generate two matching files: a private key, which stays secret on your own device, and a public key, which you place on the server. On every login, the server poses a computational puzzle that can only be solved with the private key. The secret part never leaves your own machine in the process. You can think of it like a padlock, copies of which you hand out while keeping the only key yourself.

During the first connection, the client also displays a so-called fingerprint of the server, a short string serving as an identifying feature. If you confirm it, the client remembers the server. If the fingerprint suddenly changes later, the program issues a loud warning. In that case, someone might be impersonating the server.

SSH in developers' everyday life and in security reports

On a Mac or under Linux, SSH is already built in; under Windows it can be installed afterward. A command like ssh name@server.com is enough to establish the connection. Anyone running a Raspberry Pi in the basement or renting a small web server ends up using it almost automatically. Related tools use the same technology too: SFTP transfers files over it, and when programming with GitHub, uploading code often runs over an SSH connection.

In the news, the term usually comes up when something goes wrong. A well-known example was the 2024 backdoor in the compression program xz, which would have given attackers access via SSH. It was discovered by chance before it could cause major damage. Such cases show how much trust is placed in this one access route.

A common misconception is confusing SSH with HTTPS. Both encrypt, but HTTPS secures the loading of websites in the browser. SSH, on the other hand, gives you direct control over a remote machine. That is considerably more powerful — and one should handle the private key with correspondingly great care.