OpenSSH's Cinderella story
Not having spoken to Mr. Ylönen, I know nothing about his precise motivations at the time, but the practical upshot of SSH is that it provides the world with an encrypted alternative to telnet. This was -- and is -- without question a Very Useful Thing Indeed.
However, over time, the license that governs the SSH source -- for SSH is available not just as precompiled binary, but also in source form -- has turned increasingly restrictive. Indeed, it's now well outside the bounds of a useful open-source license.
While this sort of move is irrefutably a developer's prerogative, it has also served to vex quite a few people who've become dependent on SSH.
You see, categorizing telnet as a "security risk" is not unlike referring to Ayers Rock as "big": a true statement, but one that doesn't quite grasp the crux of the matter. Those who had already started using SSH certainly weren't going to stop, and, for whatever reasons, they were unwilling to pay the fees that Mr Ylönen's company, SSH.com, charges for commercial-use licenses to SSH.
But this story has a happy ending, since these very restrictions in SSH.com's licenses sparked a development effort that not only resulted in genuinely open-source SSH software, but looks to be a crucial ingredient in future network security.
Among those less-than-gruntled about the SSH.com license were the developers of OpenBSD, an open-source BSD-based operating system well-known for its ruthlessly single-minded focus on security.
OpenBSD's developers needed SSH software -- both client and server -- that they could continue to use as well as distribute under a BSD-style license as they do the rest of their OS.
OpenSSH's official history details the sequence of events far more exhaustively than is necessary here. In synopsis, OpenSSH's developers went back to the last unencumbered version of SSH1 and started from there. They applied their own versions of all the fixes that had been made since the release of the unencumbered version, and then they set about improving the software according to their own biases.
One of the reasons OpenBSD is regarded highly is because its developers perform diligent source-code reviews of the software included in the distribution. As a result, OpenBSD boasts an impressive track record of discovering and fixing security problems, often well before they achieve widespread notoriety.
The initial version of OpenSSH was released in late 1999 and became a runaway success. According to a brief interview with OpenBSD project leader Theo de Raadt in the Linux Weekly News, the OpenSSH site saw more than 250,000 visits between April and June.
Pretty impressive for what many would decry as an esoteric piece of Unix software. This interest was thanks in no small part to the efforts of a small group that took OpenSSH and made it portable to other Unix-like OSes, including Linux.
But OpenSSH 1.2.2, as the first release was called, was limited since it only supported the SSH1 protocol. SSH2, the next-generation version of the SSH protocol that contains a number of improvements, has always been under a restrictive license, so it wasn't possible to backtrack to an older version of SSH2 and begin a new offshoot the way the OpenSSH project had done with SSH1.
Undeterred, OpenSSH's developers proceeded to write their own version of SSH2, resulting in OpenSSH 2.0's release in May of this year. OpenSSH is the first and, thus far, the only unencumbered open-source implementation of SSH1 and SSH2.
The main challenge facing SSH today is interoperability. At present, neither SSH1 nor SSH2 is recognized by any standards organization.
SSH2 is, however, in the draft stage of the Internet Engineering Task Force's RFC (Request For Comment) process.
Now, not being an expert on IETF standardization velocity, I can't say whether this effort is proceeding -- apace or at all. The Web page hasn't been modified in a year, and the draft effort began in February 1997.
We can only hope that SSH2 moves from draft to standard sooner rather than later, since changes are still being made to SSH2. According to OpenBSD's de Raadt, incompatibilities among SSH2 implementations are showing up very often at the moment because of SSH2's exile in standards limbo. (Given this state of affairs, however, observers might argue it's actually in standards purgatory.)
As I mentioned above, telnet is an incredibly insecure mode of communication. It's only slightly evolved from taking a serial cable and connecting your computer to the thing with which you want to communicate.
Telnet works just like that same serial connection, except telnet runs over TCP, which means that you can't see if a third party has alligator clips on your line the way you could by inspecting the serial cable.
So if you're logging into some device via telnet, your user name and password are all sent over the network in the clear, and the telnet protocol itself is far from immune to other TCP-based trickery.
Telnet is just plain Bad.
The computing world would, in fact, be a significantly better place if telnet were replaced with SSH. This holds true not only for environments such as corporate intranets and university campus networks but also for the many network-connected devices -- several zillion and counting -- that allow themselves to be configured via telnet.
I certainly don't like the idea of, for example, router configuration happening via telnet. OpenBSD's de Raadt concurs: "We wrote OpenSSH hoping that vendors would put it onto everything from routers, to managed switches, to file server boxes, to fire-walling gateways."
OpenSSH's tale teaches us about the benefits of restrictive source-code licenses.
If SSH.com had not restricted the licenses for SSH1 and 2, the developers working on OpenSSH today might never have gotten worked up enough to start their efforts. The immediate positive feedback they received for their troubles provided the momentum to add the SSH2 functionality, thus turning the project from one of source-code liberation to outright innovation.
Now that OpenSSH is available, we can but hope that all those telnet-centrics out there will get a clue and use it to include SSH implementations in their products.
The moral of this tale? Next time you encounter a piece of software whose license is too restrictive for your tastes, don't get mad; do what the OpenSSH project did and get even!
This is the first of a series of biweekly columns by ZDNet News' Stephan Somogyi. By day he's in charge of forestry (a k a director of strategic development) at an early-stage startup. By night (this column was finished well after 11 p.m.), he is a veteran journalist whose writing has appeared in The Economist, Wired, I.D. and Macworld, among others.