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."
I'm sure SSH Communications stands to make more money if they can discredit a free, opensource product.
They are selling a product and they will say that to sell their product. Come on what else would you expect. This is like MS saying Windows is more Secure than Linux even though everybody knows the truth.
Are they implyinng the DOD isn't an Enterprise class network?
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.
In other news, Axe body spray doesn't get you laid, and Red Bull doesn't give you wings.
that "Enterprise class" is management-speak for pay-through-the-nose. There has and always will be a deep suspicion against low-cost or free(as in beer) products. There's plenty of stuff on the market that people can't give away that is sold to schmucks everywhere.
I realise I'm displaying my ignorance here but it should hopefully prove a point. I've used OpenSSH for years and until now I had no idea they didn't develop the protocol or that a commercial variant existed.
Couple that with the sheer number of servers and distributions using OpenSSH and the statements by Byron Rashed seem to have the ring of sour grapes.
Enterprise-class is management speak for "has a pretty GUI that a monkey can use". If one is managing thousands or tens of thousands of accounts, one doesn't want to pay somebody big bucks to do it using Open Source if said open source requires an $80k/yr person to administer it. It's a TCO calculation, nothing more.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Not that I'm defending SSH, but it really depends on what specifically you are speaking of when it comes to comparing the offering of OpenSSH and SSH Communications. The two products are fairly similiar for base installs and function about the same. The problems with OpenSSH come into play in the enterprise when you want to manage the SSH installs globally or integrate the SSH server with other products.
Two examples from my own experience. We attempted integration with RSA and OpenSSH had significant problems that we had to resolve and in the end we could not resolve the final problem which was a session would hang after exiting the shell if the session was authenticated using the RSA PAM module.
The other example is related to distribution and configuration managment. We have started using SSH communications central management center to distribute new versions of Tectia server as well as centrally manage the configuration for Tectia/ssh. This has reduced our management overhead considerably. This is an "enterprise" feature.
--russ
Telltale Games: Bone, Sam and Max
Your informed opinion has no place in a Slashdot discussion.
You've been trolled. The openssh code base has plenty of comments, and it's a joy to read for most C programmers. It's nicely formatted, with plenty of consistency and thought put into the layout.
That's the whole thing about Linux/Unix. SSH isn't meant to have those types of tools. Just like grep shouldn't have a field separator (awk) or a line counter (though it now does:)). My configs are handled by rdist, rsync or cfengine.
Having all this crap built into one thing needlessly complicates things (Optional knee jerk for those who think the additional commands are the complications), and makes things a nightmare later on. Think Microsoft GUIs and the absolutely terrible configuration options when you think about how bad this can become.
Byron Rashed, senior marketing communications manager of SSH Communications Security, claimed that SSH's product is better suited for enterprise-scale business applications than a similar open-source product from OpenSSH.
Since when do we care what a Marketing manager says about anything.
Enjoy,
It's just the normal noises in here.
Often it's "enterprise" because it makes managing your enterpirse easier. Not something home users would care much about, but in a large environtment it's valuable. Like we use Ghost Enterprise Server here for PC work. The way it works is you install a Ghost client on the computers (if they run a supported OS) or boot from a Ghost boot CD/USB key (if they don't) and then the server can start ghost tasks. It can pull and push images to many systems at one all remotely. So if someone screws up a system (which happens in student labs) we can get it back up quickly, if we need to switch a lab over for something (like switch a Windows lab to Linux for a presentation), no problem.
Now it's nothing we couldn't do by hand, of course, and something we could probably hack together from freely available software. However the advantage here is that it's ready to go as is. Given that we do not have the time to mess with this kind of thing, it's worth the money to us.
Now I'm sure some enterprise software is pure fluff, but often the "non-enterprise" solution is woefully short on capabilities. It'll have all the technical stuff it needs, but lack in the ease of configuration, use and management. If you are running one server for yourself, you can tinker with nit pickey shit as much as is required. However when you run 1000 systems that's just not the case. You don't have that kind of time. You need to be able to centrally deploy and manage shit easily.
That's the whole point of things like LDAP (or Microsoft's version of it, Active Directory). Sure, you could keep a local user DB on each computer, and just update it as needed. Works fine, needs no new software. However that gets to be a bitch if you are talking 500 computers and 3000 users. Much better to have a central system. In our case, we pay Sun for a product that synchs our Active Directory to our Sun LDAP database. Could we do it manually? Sure. Could something have been hacked to do it? Ya, but we lack the time, and the personel to do that. Better to just pay Sun for it.
We attempted integration with RSA and OpenSSH had significant problems that we had to resolve and in the end we could not resolve the final problem which was a session would hang after exiting the shell if the session was authenticated using the RSA PAM module.
I had that problem too... we fixed it by turning on PrivilegeSeparation (I know the RSA docs say to turn it off, but ignore that).
In any event, that's a problem with RSA's buggy PAM module, not OpenSSH.
Think Microsoft GUIs and the absolutely terrible configuration options when you think about how bad this can become.
While, personally, I'm alot more comfortable doing things the *nix way (for example, I find httpd.conf to be a much better administrative interface than MS's IIS Manager) Microsoft's MMC based tools are pretty good these days--they cover about 95% of everything your average admin is going to do in the lifetime of the application. They're "good enough" to get the job done, and I think that most people who say otherwise probably haven't used them recently... or are simply more comfortable using different tools to do the job and just aren't willing to sit down and learn the MS way of doing things.
What part of "shall not be infringed" is so hard to understand?
They're not just groups of people, they are legal entities created by the state in a way that makes them unable to do anything but seek profit.
A business corporation that fails to screw over anyone it can in the name of profit can be sued by investors. Since for large corporations, those investors are often other profit-seeking-monster corporations, such suits would be a given if the corporation didn't plunder to within an inch of what the law allows - and even beyond what the law allows, if the penalty is less than the profit.
The modern large for-profit corporation is a Frankenstein's monster constructed of law rather than of corpses; and it's only by changing the law that we can tame these beasts.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Out of every company in the world, what's the last you would expect to not provide a crytographically signed package?
RSA's own PAM modules for RHEL are distributed as an unsigned tarball. Along with the stuff you're telling me above, I don't really have much trust in RSA as a security company (and hence any trust in RSA at all).
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
"They're groups of people. They get together and decide what to do. Usually the controlling body of shareholders says "do wtf you want as long as I make oodles of money"."
You may have heard of a study done where it was shown that people are willing to deliver deadly amount of shocks to subjects if they can remain anonymous. Humans are like that. When relieved of responsibility and guaranteed anonymity they can be incredibly savage and cruel.
Corporations were invented to shirk responsiblity and to diffuse responsibility enough to maintain anonymity. Within the context of corporations human beings act in incredibly vile ways. This is why it's so easy to for a corporation to kill hundreds of people just to save 50 cents on a part.
evil is as evil does