Slashdot Mirror
SSH Claims Draw Open Source Ire
JDStone writes to tell us eWeek is reporting that claims of OpenSSH not being an 'enterprise-class product' by SSH Communications, the creators of SSH, is being met with a great deal of resistance. Theo de Raadt, of OpenBSD fame and a member of the OpenSSH development team was quoted saying "OpenSSH is built into all Unix and Linux vendor operating systems, and is also built into almost all larger managed network switches, from Cisco through Foundry. It comes on Linksys and D-Link wireless and security routers too."
They claim that it's an enterprise product, another class of software than OpenSSH. They don't seem to have much of an argument for why it's so much different. The only comparison they manage to draw is that OpenSSH doesn't have very good SFTP, which they neglect to back by any comparison to their own. Straw man at best it seems. Anyway, what is so 'enterprise' about it that OpenSSH doesn't have? Seems to me that every 'enterprise' server running a *nix has it, so doesn't that make it enterprise enough?
The only way to tell the difference between a hamster and a gerbil is that the hamster has more white meat.
Of course you can.
That grants you permission to distribute copies. You already have the right to use it. Free Software licenses like the BSD-style licenses aren't EULAs, they only come into play when you want to distribute copies.
Bogtha Bogtha Bogtha
No, an $80k/yr person costs a company a lot more than $80k/yr. Benefits, vacation, holdays, insurance, cost of the space you occupy and utilities you use, etc...
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
I'm sure there's a way to enterprise-manage ssh other than passing keys around. But it doesn't seem to come out-of-the-box with OpenSSH just yet.
Kerberos. It's implementation in OpenSSH is a good example of how they specifically support enterprise admin. Kerberos is fairly poor security wise, using symmetric encryption and hence holding copies of user passwords on the server. It's poor security according to those with high standards, and inferior to PKI according to everybody. But OpenSSH supports it, because Kerberos is the most popular single sign on method used at corporates.
Interestingly, OpenSSH's market share is something like 76% of all SSH servers.
There's a lot of exaggeration and vagueness on both sides of this little
tempest. What suffices for one enterprise may not for another, so it is
certainly silly for ssh.com to claim that OpenSSH is not
"enterprise-class" -- as Theo and others rightly point out, OpenSSH is
used successfully in many large contexts. On the other hand, it is a fact
that Tectia has a number of features OpenSSH lacks, some of which are
particularly relevant to large organizations (which is not the same as
simple widespread use). Here are a few of them:
* PKI support
Tectia can use X.509 certificates for both client and server
authentication. To add a new SSH server or change an existing one's host
key, all you need do is issue a certificate for it. Clients need only
have a copy of a single public key: the issuing CA certificate. No
constantly shifting mess of per-user and per-host known-host files to try
to keep in sync, no spurious "unknown host" or "host key changed messages"
confusing users and teaching them to ignore security warnings. It just
works.
For client authentication, there are no burgeoning copies of
authorized_keys files lying around, unmanaged, needing to be individually
tracked down whenever you want to turn off someone's access: instead, you
can simply revoke the user's certificate. And flexible rules can grant
access based on certificate attributes, like "anyone in the Foo Department
can log into this host."
The distributed-trust problem has been addressed abstractly by systems
like PKI and Kerberos. In a large (or even medium) scale environment, you
want to tie applications such as SSH into these systems, not have each one
use its own ad-hoc mechanism.
Note that both OpenSSH and Tectia support Kerberos. There is some
variation in how well they use it to address the above problems, though,
and I won't get into that here.
* Greater configuration flexibility
With the Tectia SSH server you can:
+ Modify almost all server parameters based on the client hostname and
address, or properties of the requested account (username and group
membership). Thus you can arrange that, accounts in one group permit
password authentication, while those in another group require
public-key -- or that connections coming from your internal network
allow a wide range of ciphers, while those coming from the outside
require a smaller, stronger set. You can accomplish some of this type
of thing with OpenSSH, but generally you have to run multiple
instances of the server on different ports.
+ Exert finer-grained control over what kinds of SSH services you
provide. You can forbid terminal access while still allowing sftp,
for example, by simply rejecting the corresponding SSH protocol
requests (shell and exec channels), rather than resorting to custom
shells or other hacks that have unwanted side effects.
+ Control port forwarding with ACLs that include permit/deny statements
and patterns matching user, target hostname, IP address, etc.
+ Require multiple forms of authentication for access (e.g. password and
public-key).
* SOCKS support for outgoing SSH connections (note this is different from
the OpenSSH -D feature, which Tectia has also).
* "chroot"-ed logins
* integrated support for RADIUS authentication
* Support for Windows-native Kerberos. Although OpenSSH can be built with
Kerberos support on Windows (with Cygwin), it does not
What's wrong is we don't do Linux, for the most part, we do Windows. We also go back and forth, we'll have a Windows lab that needs to become a Linux lab for a weekend, then back to Windows on Monday.
As for OpenLDAP, talk to the Solaris admin, not my jursdiction. However I think you'd have a hard sell convincing the department to replace all the Solaris hardware, espically considering the apps we need are Sparc only in a number of cases. Same thing with replacing the Windows workstations, until you can find Linux versions of all the important apps (I'd say 1 in 20 has a Linux version) that's right out.
Ghost is excellent because it's lower level than an OS. I can have any OS or combination of OSes I like on an image. The management of any of the PC workstations is the same, I just pick the image I want and push it out.
My point isn't that Ghost is the only way to do things, my point is this is the reason someone would pay for the Enterprise version. This is what it does that normal Ghost does not, and it's something that doesn't ahve any readily available equivalant I'm aware of, except for other commercial, enterprise products like it.
I know that the DIY mentality is really popular on Slashdot, my point is that it doesn't always work. I DIY my systems at home, including hardware. I don't care to have an OEM dictate to me what kind of parts I'll have, or what will come installed on my computer. However at work, we buy OEM. Why? Well we lack the time to build systems ourselves, and the time to deal with RMAs on broken parts. RMAs for peicemeal hardware is a pain, usually if something breaks at home I buy a replacement, and then put the replacement part in another box when I finally get it. Can't do that at work so we buy OEM and if something breaks, an e-mail is all it takes to have a replacement part there next day.
Basically I'm just trying to help people see the situations where things like better, easier management really does matter. When you work in a small environment, it's easy to scoff at the waste of money these things are. I mean who the hell would pay $750 for an SSH server when OpenSSH is really pretty easy to set up, all said and done? However when you work in a larger environment, you often discover that the "easy" task is taking up an amazing amount of your time, and automating it would take even more time. It ends up being better to pay for a product that already does it, and that you know works.
This goes double if you don't have programmers on staff. I'm not sure where the misunderstanding that all or even most admins are competent programmers. Actually I find the opposite to be true. Most of the competent admins I know are at best mediocre programmers and most of the competent programmers I know are at best mediocre admins. There are a couple exceptions, but it seems for the most part when you spend your time doing one well, you don't have as much time to be good at doing the other. So if you staff is all support, no programmers, it makes even more sense to use off the shelf solutions. Better to spend $10,000 on a product that works than have 2 of your staff have 3 very unproductive months hacking something together that only sort of works.