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
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