Companies mull commercial vs. freeware SSH

It’s a battle going on across many large corporations: should they manage remote servers via Open Secure Shell freeware or commercial SSH products?

It’s a battle going on across many large corporations: should they manage remote servers via Open Secure Shell freeware or commercial SSH products?

It’s a truth-or-consequences situation that pits OpenSSH freeware proponents against those who argue freeware carries hidden costs, such as a higher administrative burden. SSH is a common tool typically used by network administrators to remotely communicate with hardware devices. Experts caution the answer depends on each corporation’s situation, but what matters is carefully tabulating the pros and cons.

“You have to do this evaluation for every open source product you bring in,” says Burton Group analyst Gary Hein. One risk of freeware is simply the possibility the freeware group might split in a major rift, he noted. Sometimes there’s already a corporate policy against open source freeware tools – the federal government is debating having one – because of deep suspicions freeware might have Trojans or simply lack a clear process of open source accountability when problems are discovered.

In a recent Burton Group report, “Open Source Software: Risks and Rewards,” the consultancy outlines basic legal and technology questions that users should ask, plus some vendor strategies for open source. The report points to the Free Software Foundation and Open Source Initiative as two organizations defending open-source principles.

Open source freeware is clearly alive and kicking in corporations, with Linux leading the way. The Burton report notes there’s a Web site that tracks open source code, SourceForge at www.sourceforge.net, which lists 66,650 projects with more than 675,000 registered users. In addition to Linux and Apache, the MySQL database is available for free use, as is Jboss, a Java 2 Platform Enterprise Edition-like Java Application Server.

But for most organizations, the time may arrive when the IT department asks: Can we get by on freeware?

That debate is roiling the IT department at Comcast Cable Communications in Denver, says Chad Monteith, a senior systems administrator. The IT department has been in charge of about 50 Unix servers, primarily Sun and HP, that came with one version or another of SSH freeware built directly into the servers.

Comcast also has added commercial SSH code from VanDyke Software and SSH Communications Security to some of the servers over the years. These servers have ended up being managed using either SSH open source freeware or commercial client software by designated systems administrators.

The problem is, Comcast’s IT department is reorganizing so that fewer systems administrators will manage more servers. And in assessing what type of client/server SSH software is being used on the 50 servers, the IT department is discovering there are incompatibilities between vendors’ SSH implementations and the freeware.

“We do use a lot of open source in our development and operations,” notes Monteith, emphasizing he isn’t against using open source freeware per se. “But the breaking point here is we have five different SSH ‘builds,’ and all these weird issues, such as this client can’t communicate with this freeware.”

He says he’s in favor of having the IT department select one version of SSH – and he is leaning toward selecting one common commercial SSH software package to end the compatibility problems.

“The biggest argument against freeware is that it costs us in staff time to manage it,” Monteith says. He notes that just figuring out why there are the interoperability problems is taking up a lot of staff time.

“If it were just three people managing five servers that would be one thing, but if it’s 50 servers and four people, that’s another,” he adds.

Burton Group’s Hein says this goes to the heart of the debate. “With OpenSSH there’s no such thing as a free lunch. You’re going to pay for an employee to do the work of service and support. This is the major obstacle to open source,” he says.

While the OpenSSH freeware from the OpenBSD Group gets high marks from users, the companies that specialize in commercial SSH software say their products bring more to the table than simple SSH support between client and server.

SSH Communications Security, for example, recently began shipping its first security-management product, called SSH Tectia Manager, that includes a database for tracking changes to SSH configurations, auditing capabilities, policy updates to servers and centralized management for deploying the agent software. VanDyke Software also has a range of commercial SSH products.

This extensive management capability is not available even in the well-respected OpenSSH freeware, notes SSH Communications CEO George Adams.

Another difference in using commercial SSH code relates to security patching. All software could have vulnerabilities waiting to be discovered, but when they are, the vulnerabilities found in open source freeware might not be the same ones as those in commercial products because of intrinsic differences in them.

Whether using SSH freeware or commercial products, an important fact about SSH to keep in mind is that SSH 1.0 has been determined to be a flawed security protocol. SSH 2.0, expected to be finalized by the IETF this spring, has been widely used for several years and is the preferred mode for SSH.

Stephanie Schiebert, senior engineer at SSH Communications, says Version 1.0 is widely known to use a flawed process of data-integrity cyclic redundancy checks that are subject to modification in transit. That means data using SSH 1.0 can be intercepted and changed. “It’s fairly easy to do,” says Schiebert, noting that CERT in its security advisory 253-09 back in 2001 warned against SSH 1.0.

Because router vendors such as Cisco keep including SSH 1.0 as a default “it makes it harder to get rid of it,” Schiebert says. “A lot of people don’t understand the need to upgrade.”

Like VanDyke, SSH Communications has been pressed by customers to include SSH 1.0 in some of its products because it lives on in network equipment. The security firm has included SSH 1.0 in some of its client SSH software, but refrained from including it in its server software products. “It’s important that administrators not have SSH 1.0 on the server,” she notes, because it’s simply a poor security practice.