SSH: The Lock That Replaced the Password

The Sniffer in the Wires

This is episode twenty-one of What Did I Just Install.

Sometime in early nineteen ninety-five, on a university network in Finland, someone planted a listening device. Not a physical one. A piece of software. A packet sniffer, quietly sitting on the wire, reading every byte that flowed past it. And in nineteen ninety-five, a staggering amount of what flowed past it was passwords. Plain, readable, unencrypted passwords, typed by professors and students and researchers logging into machines all over the Helsinki University of Technology, sailing across the network in the clear like postcards in a mail truck with no envelopes.

The sniffer caught thousands of them. It was, in the language of the time, a password-sniffing attack, and it was not exotic. It was the most ordinary attack imaginable, because the entire internet of nineteen ninety-five was built on an assumption that now sounds insane. The assumption was that the network was trustworthy. That nobody was listening. That when you typed your password into a program called telnet to log into a remote machine, the password would travel safely to the other end because, well, why wouldn't it?

Among the credentials that sniffer captured was an account belonging to a twenty-seven-year-old researcher at the university. His name was Tatu Ylonen. And unlike most of the people whose passwords were stolen that year, Ylonen did not just change his password and move on. He sat down and built the thing that would replace the entire broken model. He built a program he called Secure Shell. Most people know it by two letters. SSH.

Today, that program runs on essentially every server on earth. Every time a developer deploys code, every time an administrator logs into a cloud instance, every time a backup script copies files to a remote machine in the middle of the night, it goes through SSH. It is the front door to the internet's infrastructure. And the story of how it got there runs through a password thief in Finland, a Finnish company that nearly killed its own creation by trying to own it, and a group of obsessive security programmers who took the last free version and made it free forever.

What It Actually Does

To understand why Ylonen's program mattered, you have to understand what people did before it, and how exposed they were.

In the early nineties, if you wanted to use a computer that was not the one in front of you, you used one of a small family of tools. Telnet let you open a terminal session on a remote machine. Rlogin and rsh, the remote login and remote shell commands, did something similar within trusted networks. Rcp copied files between machines. Ftp moved files around. All of these tools worked. All of these tools were, by the standards of any security engineer today, catastrophically naked. Every keystroke you sent, including your username and password, traveled across the network as readable text. Anyone with access to any machine along the path could read all of it.

It gets worse. The trusted-network tools, rlogin and rsh, did not even bother asking for a password in many configurations. They relied on a file that said, in effect, trust anyone connecting from this list of machine names. But machine names on the early internet were handed out by a system that could be lied to. If you could convince the network that your machine was one of the trusted ones, a trick called spoofing, you could walk straight in. No password required, because the whole model assumed the network itself was honest about who was who.

So here is what Ylonen's Secure Shell did, in plain terms. First, it encrypted everything. The moment you connected, before you typed a single character, the two machines performed a negotiation and agreed on a secret key that only they knew. From that point forward, every byte in both directions was scrambled. The sniffer on the wire would catch your password, yes, but what it caught was noise. Useless. Second, it authenticated the machine you were connecting to, so an impostor could not pretend to be your server and harvest your credentials. And third, it could authenticate you with cryptographic keys instead of passwords, so there was no secret to steal in the first place.

The original announcement, which Ylonen posted to a security newsgroup in July of nineteen ninety-five, described it with the kind of plainness that hid how radical it was. Secure Shell, he wrote, is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over untrusted networks. The threats he named were exactly the ones he had just lived through. Listening for passwords from the network. IP spoofing. DNS spoofing. He had been robbed, and he built a vault.

The Researcher Who Got Robbed

Tatu Ylonen was born in nineteen sixty-eight in Finland. By the mid-nineties he was at the Helsinki University of Technology, the engineering school in Espoo just outside Helsinki that Finns simply called T K K. He had earned his master's degree in computer science there in nineteen ninety-two and a licentiate, a Finnish degree that sits between a master's and a doctorate, in nineteen ninety-four. He was, in other words, deep in the research world, exactly the kind of person who lived on remote machines and typed passwords into the network dozens of times a day. When the sniffer caught the university's credentials, it caught his too.

What is striking about Ylonen's response is that he did not treat it as someone else's problem. The cryptography existed. The pieces were lying around. Public-key cryptography had been published in the nineteen seventies. The algorithms to encrypt a channel and exchange keys over an untrusted network were known. What did not exist was a tool that bundled all of it together into something a working researcher could actually use to replace telnet on a Tuesday afternoon without becoming a cryptography expert. Ylonen built that tool. He wrote it in C, for the Unix systems everyone around him was using, and he made it behave as much like the old tools as possible so people could switch without relearning anything.

And then he gave it away. The first release, in July of nineteen ninety-five, was free software with source code. Anyone could download it, read it, compile it, and use it without paying a cent. This was the decision that made everything that followed possible. Because the thing about a security tool is that nobody trusts a black box. If you are going to route every password and every command and every file transfer through a piece of software, you want to be able to see what it does. Free and open source was not just generous. It was the only way a security tool could earn the trust it needed to spread. And spread it did.

By the end of that same year, nineteen ninety-five, an estimated twenty thousand users in fifty countries had adopted Secure Shell. Ylonen, one researcher in Finland, was personally fielding around one hundred and fifty email messages every single day from people asking for help, reporting bugs, requesting features. He had solved his own problem and accidentally become the support desk for a global security tool. No human being can answer a hundred and fifty emails a day forever and also keep writing the code. Something had to give.

The Leap of Faith

Before we follow what Ylonen did next, we have to talk about the single most interesting decision in the whole design. Because it is the decision that a listener can take home and argue about, and it is the decision that made SSH actually win.

Here is the problem. SSH promised to authenticate the server you were connecting to, so that an impostor could not impersonate your machine and steal your login. Lovely in theory. But how does your computer know, the very first time it ever connects to a server, that the server is the real one and not an impostor sitting in the middle? The server presents a cryptographic identity, a host key, a long unique number that proves it is itself. But on the first connection, your computer has never seen that key before. It has nothing to compare it against. It cannot tell a genuine host key from a forged one.

There is a perfect solution to this, and it is the one the web chose for itself. You build a global hierarchy of trusted authorities who vouch for identities, a chain of trust that your machine ships with from the factory. That is the certificate authority system that sits underneath the padlock in your browser, the system we spent a whole episode on when we told the OpenSSL and Heartbleed story back in episode fourteen. It works. It is also enormously expensive, institutionally complex, and in nineteen ninety-five it essentially did not exist for the kind of random Unix server a researcher wanted to log into. There was no authority to ask. There was nobody to vouch for the machine in the lab down the hall.

So Ylonen made a pragmatic compromise, and it has a name. Trust on first use. Some people call it the leap of faith. The first time you connect to a server, SSH cannot verify its identity, so it does not pretend to. Instead it shows you the host key's fingerprint, a short string of characters, and asks you a blunt question. The authenticity of this host cannot be established. Are you sure you want to continue connecting? You say yes. And from that moment, SSH remembers that key. It writes it down in a file on your machine called known hosts. Every future connection to that server is checked against the remembered key. If it ever changes, if an impostor ever tries to slip in between you and your server, SSH throws an alarming wall of warning text and refuses to connect.

Now, a purist will tell you this is a hole. And they are right. That very first connection, the leap of faith, is genuinely vulnerable. If an attacker is already sitting in the middle the very first time you connect, you will trust their forged key and never know. The blog posts arguing that trust on first use does not really work have been written, repeatedly, by smart people. The cryptographers wince at it. But here is the counterargument, and it is the whole reason SSH exists at all. A model that is ninety-nine percent secure and that everyone actually uses beats a model that is one hundred percent secure and that nobody can be bothered to deploy. Telnet was zero percent secure and universal. SSH with trust on first use was almost perfectly secure for almost every connection, and crucially, it required no central authority, no paperwork, no fees, no infrastructure. You could install it this afternoon. That was the trade. Perfect security that ships never, against very good security that ships today. Ylonen chose today. And because he chose today, the password-sniffing era ended.

The Name and the Company

The name is the least mysterious part of the story, which is rare for this series. Secure Shell. A shell, in Unix, is the program that gives you a command prompt, the thing that interprets what you type. There were already remote shells, rsh, the insecure remote shell. Ylonen built a secure one. Secure Shell. SSH. It is descriptive to the point of being boring, and that turned out to be a strength, because a tool named after exactly what it does never confuses anyone.

What was not boring was the decision Ylonen made in December of nineteen ninety-five, five months after the first release, drowning in those hundred and fifty daily emails. He founded a company. SSH Communications Security, based in Finland, to maintain, commercialize, and continue developing Secure Shell. On its face this was sensible, even admirable. A critical tool needs sustained work, and sustained work needs money, and money needs a business. We have watched maintainer after maintainer in this series burn out precisely because there was no company, no salary, no structure. Ylonen tried to avoid that fate by building the structure first.

But commercializing the tool created a tension that would eventually fracture the entire project. Because the thing that made SSH spread, the thing that earned its trust, was that it was free and open. And a company, by its nature, needs to sell something. The early versions stayed open. But as the company grew, as SSH introduced new versions and new features, the licenses tightened. The source was still visible, but the terms on what you could do with it narrowed. Commercial use required payment. The free-for-everyone tool was slowly becoming a product. By the year two thousand the company had around two million users and had listed on the Helsinki stock exchange. The protocol had outgrown the researcher who invented it, and it was drifting, inch by inch, out of the commons and into a balance sheet.

Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over untrusted networks.

That was the promise in the original announcement. Strong authentication. Secure communications. Untrusted networks. The promise was universal. The product, increasingly, was not.

Version One, Version Two, and a Fatal Flaw

While the licensing was drifting, the protocol itself was changing in a way that matters to the rest of the story. The first version of the Secure Shell protocol, the one from nineteen ninety-five, is now called SSH-1. It was, by Ylonen's own later admission, a somewhat ad hoc design. He had built it fast, to solve a real problem, and as it spread, people started finding the rough edges. So in nineteen ninety-six, the company introduced a completely redesigned second version of the protocol, SSH-2. It used a cleaner cryptographic structure, a proper key exchange based on the Diffie-Hellman method, separate dedicated mechanisms for integrity checking, and stronger ciphers. And it was deliberately incompatible with version one. You could not mix them. A SSH-2 client could not talk to a SSH-1 server.

For a while this looked like over-caution. SSH-1 worked fine. Then, in nineteen ninety-eight, two researchers at an Argentine security company called CORE SDI, Ariel Futoransky and Emiliano Kargieman, found something that turned over-caution into vindication. They discovered a fundamental design flaw in the SSH-1 protocol. The way version one checked that a packet had not been tampered with relied on a simple mathematical checksum called CRC-32, a technique designed to catch accidental corruption, not deliberate attack. Futoransky and Kargieman showed that an attacker could craft malicious data that produced a valid checksum after decryption, slip their own packets into the middle of an encrypted SSH session, and ultimately execute arbitrary commands on the machine at the other end.

This is darkly funny in retrospect. The tool built to defeat people inserting themselves into your connection had a flaw that let people insert themselves into your connection. And the flaw was not fixable. It was baked into the version one protocol design itself. You could not patch SSH-1 to be safe without breaking it. The best anyone could do was bolt on a detector that tried to spot the attack as it happened, a file called deattack, which spread to nearly every SSH installation in the world. And then, in a twist that belongs in a tragedy, the detector itself was found to have a bug, an integer overflow, that handed attackers the very remote code execution it was meant to prevent. Worms exploited it. The patch became the wound.

The lesson landed hard. SSH-1 was finished. SSH-2, the clean redesign nobody had been in a hurry to adopt, was now the only safe choice. And the protocol that everyone needed to move to was the one increasingly tangled up in a commercial company's licensing. The free, universal, trustworthy tool was now neither fully free nor safe in its free form. This is the exact moment the story needed a fork. And the people who provided it were, even by the standards of open source, a special kind of stubborn.

The OpenBSD Obsessives

To understand the fork, you have to understand OpenBSD, and to understand OpenBSD, you have to understand Theo de Raadt. If you have been following this series, you have met him before. He showed up in episode fourteen as the famously blunt founder who looked at the OpenSSL codebase after Heartbleed, called it a mess, and forked it into LibreSSL. That is the same man, the same project, the same temperament, just fifteen years earlier and aimed at a different target.

OpenBSD is an operating system whose entire reason for existing is security and correctness. De Raadt and his collaborators audit code obsessively, line by line, looking for the kinds of mistakes that everyone else ships. Their whole culture is built around the belief that most software is sloppy and that the only cure is relentless, suspicious reading of every line. So when the OpenBSD team needed Secure Shell, and they absolutely did, every Unix server needs it, they faced a problem. The current SSH was drifting proprietary. They could not just ship a commercial product with restrictive licensing inside their free operating system. They needed a free Secure Shell, and the free versions were either old or, in the case of SSH-1, fatally flawed.

So in nineteen ninety-nine they went hunting for the last clean version. They found it in two places. First, the original SSH release numbered one point two point one two. That was the last version Ylonen had shipped under a genuinely free license, before the terms tightened. And second, a Swedish developer named Bjorn Gronvall had already taken that old free release and continued patching it, fixing bugs, in a derivative he called OSSH. The OpenBSD team took Gronvall's work as a starting point, less than two months before their next operating system release, and threw their entire auditing machine at it.

What happened next was a sprint. De Raadt himself started by ripping out everything that made the code hard to read, all the tangled portability layers and operating-system-specific special cases, on the principle that you cannot spot a security hole in code you cannot understand. Markus Friedl, a German developer, did the deep protocol work. Bob Beck in Canada wrangled the cryptographic libraries so they could be built without infringing the patents that still encumbered some of the algorithms at the time. Aaron Campbell wrote documentation. Dug Song handled an authentication subsystem while carefully not touching the crypto. And then there was the matter of where some of that code could legally be written at all.

Road Trips to Canada

This is the detail that turns the fork from a software story into a geography story, and it is one of my favorite facts in this whole series.

In the late nineteen nineties, the United States classified strong cryptography as a munition. Exporting it was governed by the same kind of law that governs exporting weapons. You have heard this echo before, in the OpenSSL story, where an Australian-written crypto library mattered precisely because it sat outside US jurisdiction. The same legal weather shaped OpenSSH. The team needed to strip out and replace cryptographic components and certain encumbered code to make the entire thing freely reusable by anyone, anywhere, with no strings. But doing that crypto work inside the United States risked entangling it in American export restrictions. So Niels Provos, one of the developers, physically drove to Canada to do it. Road trips, plural, across the border, so that the cryptographic and encumbered components could be removed and replaced on soil with freer export laws, ensuring the resulting code base was clean of legal claims from any direction.

The remaining cryptographic and encumbered components were removed by road trips to Canada, so that we could end up with a completely freely reusable source code base.

Think about what that means. The reason you can SSH into a server today, freely, anywhere on the planet, is partly that someone got in a car in the nineteen nineties and drove cryptography across an international border to dodge a weapons-export law. The code itself does not remember this. The git history is a little vague about it. But it happened, and it is the kind of absurd, physical, human detail that sits underneath the clean abstraction of a tool that just works.

They called the result OpenSSH. The name followed the convention of their world. SSH was the protocol. Open meant free, open source, OpenBSD-born. OpenSSH. The initial code import happened on the twenty-sixth of September, nineteen ninety-nine, and OpenSSH version one point two point two shipped inside OpenBSD two point six on the first of December that year. A free Secure Shell existed again. But it was still, at that point, only the old version one protocol. The dangerous one.

The crucial move came the following year. Markus Friedl led the effort to add the SSH-2 protocol, the clean, safe redesign, to OpenSSH. In June of two thousand, OpenSSH version two point zero shipped supporting both protocol versions in the same program, with Provos and de Raadt verifying the work. Now the free fork did everything the commercial product did, on the modern safe protocol, with a code base that had been audited by the most paranoid programmers in the business. The reason to pay for the original had quietly evaporated.

We replaced the protocol code, added support for the second protocol version, and kept the code small enough that we could actually read all of it.

The Tool Escapes the Island

There was one more wall between OpenSSH and the world, and it was a practical one. OpenSSH was built for OpenBSD. It assumed it was running on that one tidy, security-obsessed operating system. But almost nobody runs OpenBSD on their servers. The world runs Linux, and assorted other Unix systems, and eventually Windows and macOS. A Secure Shell that only worked on OpenBSD would have been a beautiful artifact that changed nothing.

So the project made a deliberate split. The core team, on OpenBSD, would keep the code as clean and as readable and as platform-specific as they liked. And a separate effort, called OpenSSH Portable, would take that clean core and wrap it in the messy, unglamorous compatibility code needed to make it run everywhere else. The person who became the long-running force behind that portability work, and behind much of OpenSSH for the next two decades, was an Australian developer named Damien Miller. He and a small group took the OpenBSD-native code and made it run on Linux, on commercial Unix systems, eventually on anything. He also wrote the client side of secure file transfer, the SFTP tool that replaced the old insecure file copies.

This split is why the thing on your machine is almost certainly OpenSSH Portable. The version that runs on your Linux server, the version Apple ships in macOS, the version Microsoft eventually added to Windows in twenty eighteen, all descend from that portable branch. The free fork did not just survive. It escaped its island and colonized the entire computing world. And it did it without marketing, without a sales team, without the company. It won by being free, being audited, being everywhere, and being good.

The original commercial SSH did not disappear, exactly. SSH Communications Security still exists, still sells products. But the protocol that bears its founder's design, the everyday tool that billions of connections flow through, is the free fork. The researcher invented the idea and the company tried to own it, and the commons took it back. If you have been listening to this series, you know the fork is one of our recurring shapes. Pillow forked from a dead PIL. The ffmpeg world fractured and reformed. Valkey split from Redis over a license. But the SSH story is its own particular flavor. This was not a coup and not a dead maintainer. It was a slow drift toward proprietary, met by a community that found the last free version, drove its cryptography across a border, and built something so much better and so much freer that the original simply stopped mattering.

The Trademark Tussle

There is a small, almost comic coda to the commercial-versus-free tension, and it is worth telling because it shows how completely the free version had won by the early two thousands.

In February of two thousand one, Ylonen's company informed the OpenSSH development mailing list that it intended to assert ownership of the trademarks on the terms SSH and Secure Shell. The argument was straightforward from a business point of view. They had coined the names. They believed they owned them. And they proposed that the protocol everyone was now standardizing through the official internet standards body should be renamed to something else, something like SecSH, to avoid infringing on what they considered their marks.

It did not go well for them. The internet engineering body considered the claim and effectively shrugged. By two thousand one, the terms SSH and Secure Shell had been used so broadly, by so many people, for so many years, without anyone enforcing a trademark, that they had simply become generic. They were like the word escalator or the word aspirin, names that had escaped into the language and could not be recaptured. The working group declined to rename anything. The standards that came out of that body, the formal definitions of the Secure Shell protocol published in two thousand six as a set of internet standards documents, kept the name SSH. The commons had not just taken the code. It had taken the name.

And this is the deeper meta-narrative, the one that runs underneath the whole story. Ylonen did everything that conventional wisdom says you should do. He invented something valuable. He started a company to sustain it. He tried to protect his intellectual property. By the logic of business, he played it correctly. And it almost cost the world the free tool. The thing that saved SSH was not the company that owned it. It was the decision Ylonen made at the very beginning, before the company existed, when he released the source code for free and let twenty thousand people in fifty countries read it and run it. That single act of openness planted a version that could never be fully recaptured. The company drifted proprietary, and the commons reached back to nineteen ninety-five, picked up the last free release, and grew it into the standard. You can spend years trying to own something. The thing that lasts is the part you gave away.

A Backdoor Aimed at the Front Door

To feel how central SSH has become, it helps to look at what attackers go after, because attackers always go after what matters most. And in twenty twenty-four, the most sophisticated open source attack anyone had ever seen was aimed squarely at SSH.

We told the full story back in episode ten. A patient, methodical attacker, working under a false identity, spent years infiltrating a small, obscure compression library called xz-utils. They earned the trust of the exhausted solo maintainer, took over the project, and planted a backdoor. But the backdoor was not really about compression. The compression library got pulled, deep in the dependency tree, into the SSH server software on major Linux distributions. The whole elaborate three-year operation existed to reach one target. The attacker wanted a secret key into sshd, the SSH daemon, the front door of essentially every Linux server on the internet. Compromise SSH and you compromise the way administrators connect to everything.

It was caught, barely, by a Microsoft engineer named Andres Freund who noticed that his SSH logins were running about half a second slower than they should. Half a second. That tiny delay was the only visible symptom of an attack that could have handed an unknown actor remote access to a significant fraction of the world's servers. And the reason that attack was worth three years of patient effort is the same reason this episode exists. SSH is the lock on the front door. If you want into the house, that is the lock you pick. The fact that the most ambitious supply chain attack in history was, at its heart, an attempt to get a key to sshd, tells you exactly how much weight this one tool carries.

Keeping the Lock Modern

A lock built in nineteen ninety-five could easily have become a liability by now. Cryptography ages. Algorithms that were strong then are weak today, and the tools that keep using them become the soft spot attackers aim for. What is remarkable about OpenSSH is that the same paranoid culture that forked it has spent twenty-five years aggressively throwing old things away, even when it annoys people.

The dangerous version one protocol, the one with the fatal checksum flaw, was deprecated and eventually disabled and removed entirely. Over the years the project has ripped out weak ciphers, broken key types, and aging signature algorithms, often ahead of the rest of the industry, often over the complaints of users who just wanted their old setup to keep working. In the summer of twenty twenty-four, OpenSSH disabled by default an old signature algorithm called DSA, a relic limited to a key size that modern attackers can chew through, and the following year it tore the last of it out completely. The reasoning, from the maintainers, was characteristically blunt. The cost of keeping a weak algorithm alive was not worth it, so it had to go.

And they are not just deleting the past. They are bracing for a future that has not arrived yet. In the autumn of twenty twenty-four, OpenSSH added a new key exchange method designed to resist attacks from quantum computers, machines that do not really exist at useful scale yet but that, if they ever do, could shatter the cryptography the entire internet relies on. The method combines a tested classical algorithm with a new lattice-based one, hedging the bet. The reasoning is that an attacker could be recording your encrypted traffic today, unable to read it, and patiently waiting for a quantum computer to arrive years from now to decrypt the archive. The maintainer leading much of this work is the same Damien Miller who carried the portable version for two decades. The lock keeps getting rebuilt while it is still in use, on every door, without you ever noticing.

The threat is that an adversary records your encrypted session today and waits to decrypt it once a quantum computer exists. The defense has to be deployed before the threat arrives, not after.

Where It Connects

Open a terminal on this machine. There is a very good chance you have already used SSH today without thinking about it, and an almost certain chance the tool is sitting there ready.

When you deploy code to a server, you are using SSH. When a backup script copies files to a remote machine overnight, it almost certainly rides on top of SSH. When you clone a private code repository, when a continuous integration system reaches out to a build server, when a system administrator anywhere on earth logs into a cloud instance to fix something at two in the morning, the connection is wrapped in the protocol a robbed researcher invented in Finland in nineteen ninety-five and a group of obsessives drove across the Canadian border to free. Every one of those connections begins with the same quiet ritual. A key exchange. A host key checked against the known hosts file. An encrypted channel established before a single command is typed.

And here is the thread that ties this episode to the rest of the series. We have spent episode after episode marveling at how much of the world rests on tiny, underfunded, volunteer-maintained software. SSH is the inverse and the proof at once. It is not tiny and it is not neglected. It is maintained, audited, modernized, and defended by people who treat it with the seriousness it deserves. And yet it got there by accident, through a sniffed password and a researcher who refused to just change his and move on, through a company that nearly enclosed it and a community that took it back, through a pragmatic compromise on trust that a purist would never have allowed but that let real people actually use real cryptography for the first time. The leap of faith, it turns out, was not just the host key prompt. It was the whole project. Give it away, trust the commons, and hope.

The lock on the front door of the internet was not handed down by an institution. It was built by one angry researcher, freed by a handful of paranoid programmers, and it has been quietly relocking itself ever since, while the rest of us just type yes and connect.

SSH is already on your machine. Open a terminal and type ssh dash capital V. You will see the OpenSSH version running, the descendant of that nineteen ninety-nine fork. Now look in your home folder for a hidden directory called dot ssh, and inside it a file called known hosts. Open it. Every line is a server you once said yes to, a host key you accepted on faith and your machine has remembered ever since. That is trust on first use, written down in plain sight. Each entry is a small promise your computer made to a machine somewhere, and has quietly kept, every time you have connected since.

That was episode twenty-one of What Did I Just Install.