February 16, 2019

Why a Distro-Provided OpenSSH is Better than a Third-Party OpenSSH

Slapping on a Brand

  • February 1, 2011
  • By Yvo Van Doorn

When a third-party vendor tells you their custom OpenSSH is better than your Linux distro's OpenSSH, here is why you should be skeptical.

Recently one of our customers sent us marketing materials from one of our competitors. One thing that stuck out was the positioning that their version of a critical system component used in *NIX OpenSSH is better than the vendor-provided OpenSSH (from Red Hat, for example). As a former systems engineer responsible for many *NIX systems, this raises a red flag and here's why.

In the last 10 years the SSH (secure shell) protocol has become the dominant (and sometimes only way) of interacting with *NIX servers. SSH provides users a secure method of accessing *NIX resources remotely, replacing rsh or telnet. OpenSSH is a server and client program that implements the SSH2 protocol and is the de facto program used on many *NIX flavors (i.e. AIX, FreeBSD, Mac OS X, Red Hat, SLES, Ubuntu) and it does it very well.

As mentioned, vendors often distribute a copy of OpenSSH with their OS, such as Red Hat Enterprise Linux. It has been slightly tweaked and optimized to work better under Red Hat Enterprise Linux. Red Hat often updates their version of OpenSSH via system updates as features are stabilized and/or security improvements are made. In fact, since the release of RHEL5, 41 updates have been made to the OpenSSH program.

Our competitor is attempting to sell the idea that using their "custom-branded" version of OpenSSH is a better solution. This is a horrible idea and approach for these reasons:

  • A team of engineers employed by the OS vendor is responsible for making sure your operating system remains secure and stable, while maintaining the version of OpenSSH.
  • The "custom-branded" version does not incorporate the changes made by your vendor to ensure 100% compatibility with the OS.
  • Instead of your OS vendor being responsible for maintenance updates for an essential system component, you are now locked into updates from a third party.
  • A potential exists for conflicts between the vendor and custom versions.

Why go with a solution that doesn't interact fully with your essential vendor-supplied system tool. While that certainly reduces strain on their Quality Assurance (QA) department by forcing customers to use non-vendor approved versions, it puts a heavier burden on the customer. If you had any issues, you couldn't go to your OS vendor for support, since you would not be using their version.

You should always be concerned and on alert when a third-party vendor is touting replacing an essential system tool with their "better" version. It often is their way of creating a shortcut in the development cycle, but it creates a very big gray area when support and/or updates are needed for these tools.

Mr. Van Doorn works for Likewise Software, and contributed the popular Best Practices with sudo on Linux

Most Popular LinuxPlanet Stories