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."
Unfortunately, Theo de Raadt chose to counter his claims with "installed base" numbers, which do absolutely nothing to discredit their statements. Of course, the article doesn't have any of those statements either.
You are in a maze of twisted little posts, all alike.
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.
THE PRESS RELEASE FROM http://www.ssh.com/
On May 10, 2005, The New York Times published an article concerning a breach at Cisco System, in which an intruder seized programming instructions for many of the computers that control the flow of Internet traffic. The attention was focused on a 16-year-old in Uppsala, Sweden, who was charged in March with breaking into university computers in his hometown. The crucial element in the attack that provided access at Cisco and elsewhere was the intruder's use of a vulnerable version of Secure Shell software.
Should organizations using Secure Shell become worried? Is this something that could also happen in your network?
SSH1 vs. SSH2
There are two versions of the Secure Shell protocol. The current version, Secure Shell version 2 (SSH2) introduced by SSH Communications Security in 1998 provides several security improvements compared to the original Secure Shell version 1 (SSH1). SSH Communications Security considers SecSh v1 vulnerable and does not recommend its use. The first step in eliminating vulnerabilities in your Secure Shell environment would be to upgrade all SSH1 to SSH2.
Security Maintenance Challenge
But it is not just environments running old SSH1 protocol versions that may be vulnerable against known exploits that can result in similar incidents like the one mentioned in The New York Times article.
For example, several vulnerabilities have been discovered over recent years in the widely used open-source implementation of Secure Shell protocol, OpenSSH.
Keeping OpenSSH environments secure requires constantly updating the environment with latest security patches. However, updating OpenSSH servers involves an extremely laborious and time-consuming process of source-code compilation, testing, installation, and configuration. In large-scale environments this leads to a heavy administrative burden and increased costs. As a result, during the times of constrained IT budgets many organizations have been forced to neglect frequent security patches and software updates making them vulnerable.
Even if organizations are willing to go through the costly process of manually maintaining the software on a regular basis, lack of centralized management can still present a risk. The New York Times writes:
"Government investigators and other computer experts watched helplessly while monitoring the activity, unable to secure some systems as quickly as others were found compromised."
Given the increased use of automation and sophistication of attacks, the window of opportunity for reacting to new security threats is becoming smaller. Therefore, centralized, real-time management of security systems is a critical building block in comprehensive enterprise security.
Solution - SSH Tectia
SSH Communications Security, the original developer of the Secure Shell protocol, provides end-to-end communications security solutions specifically for the enterprise. Its SSH Tectia solution has been developed to overcome the security and manageability issues of large-scale Secure Shell environments.
By standardizing on SSH Tectia throughout heterogeneous enterprise networks, including Windows, Unix, Linux, and IBM mainframes, organizations can cost-effectively implement secure practices for maintaining and using Secure Shell.
The key features and benefits of SSH Tectia for ensuring secure operation include:
Centralized Secure Shell software management enabling real-time updates to a large number of hosts and reducing the window of opportunity for exploits.
Centralized Secure Shell monitoring allowing fast identification of system anomalies.
Enterprise-class support and maintenance services including 24x7 support option enabling fast problem resolution.
FIPS 140-2 certification of cryptographic libraries serving as a proof of reliable implementation of cryptographic functions.
The enterprise-proven Secure Shell code of SSH Tectia is based on the 10 years to in-depth experience of the original development team of secure shell, and based fully on the secure, industry-proven SSH2 protocol.
You are in a maze of twisted little posts, all alike.
You can tell the difference between news and Public Relations fairly easily these days. Either can look at a controversy like "SSH is enterprise-class software" (whatever that means, exactly). PR publishes a story about how one party claims it isn't, and another party irately claims it is, without telling the story of whether, in fact (or even in reliable opinion), it is or not. Actual news reporters investigate what "enterprise-class software" is, compare SSH to that, and tell the story of the software. Even including the opinions of experts, and inexpert stakeholders in the debate.
We know that eWeek, like most IT press, is PR. But it's instructive to compare eWeek's obvious PR to "mainstream media", which is now mostly just PR. Real reporting keeps the "fairness and balance" in the process of determining the real story. Then tells the real story, with evidence and witnesses to back it up. PR, and most MSM, just spouts endless hourse of newscycle reiteration of "sources" promoting their versions of the story.
--
make install -not war
(Sites that will trap you in an infinite redirect loop if you refuse their cookies are intolerable. I'm reprinting article in the clear here to protest this behavior.)
SSH Claims for New Secure Shell Draw Open-Source Ire
By Steven J. Vaughan-Nichols
September 27, 2005
SSH Communications Security Corp., a provider of enterprise security solutions and end-to-end communications security and the original developer of the Secure Shell protocol, announced this week the availability of Version 5.0 of its SSH Tectia client/server solution and SSH Tectia Manager 2.0.
Secure Shell programs provide a transport-level protocol for administrators and remote users to securely log into remote servers for management, work and FTP (file transfer protocol) transfers. It's most often used for remote administration purposes.
The SSH Tectia is available on Windows, Unix, Linux and IBM mainframe z/OS environments. SSH Tectia can be centrally managed with SSH Tectia Manager.
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.
"OpenSSH is not an enterprise-class product that is needed for the demands of a large-scale deployment. We do not compare OpenSSH to our SSH Tectia solution, since it's far from the same," Rashed said.
However, OpenSSH is very popular and is commonly deployed in almost all BSD, Unix and Linux systems. More than 87 percent of Internet-facing servers were using OpenSSH, according to an OpenSSH Internet scan in September 2004.
Rashed acknowledged this but added, "Many vendors use it because it is free and they can use it without a license, so the number of users for remote access is quite large, but it does not provide very good SFTP or application connectivity usage."
In any case, "OpenSSH certainly has its place, and we are not competing with them. We truly have a different class of product that is more suitable for business-critical applications" that customers ask about, said Rashed.
These comments raised the ire of Theo de Raadt, leader of the OpenBSD operating system and a member of the OpenSSH development team.
"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," said de Raadt.
"It is just the most commonly installed security software used anywhere in the world," he said. According to OpenSSH's numbers, the SSH product line is on less than 7 percent of servers, and most of that comes from SSH-1.5, with 5.38 percent.
"It is only when you get to their SSH-1.99 and SSH-2.0 versions, at 0.32 percent and 1.22 percent of the market, that you are talking about modern SSH commercial versions," said De Raadt.
Rashed contends that business customers are now looking for Secure Shell programs with support and liability protection "due to compliance regulations and security audits." Specifically, "we have heard lots about SOX 404 [Sarbanes-Oxley], CA SB 1386 [California Information Practice Act], HIPAA [Health Insurance Portability and Accountability Act] and others along with internal audits that are driving customers to SSH Tectia," Rashed said.
"Liability is also an issue that companies are worried about. Open-source software usually does not have any indemnity insurances associated with them."
This misses "the point that the two are not exclusive. You can go to any number of OS vendors [like Red Hat or Novell] and pay for accountability and support for an OS that includes OpenSSH," countered Mark Cox, a Red Hat Inc. consulting engineer and founding member of the OpenSSL group.
FOSS programs generally don't have to connect to a 'license server' or have a paid-for 'license key' entered in a magic config file or dialog box. There is also not normally a hologram or fancy piece of paper that must be presented upon request.
Why are you so afraid of cookies? Just mark the file read-only or immutable (via chattr). You get the benefit of the cookie while your browser is open, but close the browser and re-open it and your previous sessions cookies are all gone.
Don't blame me, I voted for Kodos
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
Thats funny. I just looked at the source myself, and I saw plenty of comments. Not only that, but it was the furthest thing I could imagine from "spaghetti code". Very modular with a clean API.
/* Initializes the buffer structure. */ - clearly not what we want. Looking down we see buffer_append(). That sounds promising. But we can't expect people modifying the code to actually take the time to read and understand it, can we? So lets look at the comment to make certain sure. /* Appends data to the buffer, expanding it if necessary. */ I'm not sure, but I THINK that might just do what we wanted.
But since this is slashdot I think concrete examples are in order. Lets say we want to find out about the buffer routines, where do we go? Oh, buffer.c. I wonder what is in that file?
Well, look at that! Its the buffer management API! WOW! Who would have thought it!
So, we want to add some data to an existing buffer. What function should we use? buffer_init() no...comment says
WOW that was SO hard, not helped one bit by all that blatant spaghetti code and total lack of comments!
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.
Enterprise-class is management speak for "has a pretty GUI that a monkey can use".
Contrary to popular belief, Enterprise Class means 'supportable' in a large (enterprise) environment. Fancy going round 10,000 desktop PCs worldwide, applying 1 critical product patch personally? Or would you prefer to use some sort of 'enterprise-class' patch management software? Perhaps you'll be around to reset all those stalled PCs in that lights-out datacenter in the middle of nowhere, where you need to provide 48 hours notice just to enter the facility - or would you prefer to login to Sun boxes on the hardware console via an 'enterprise-class' LOM device?
Key-generation: there are TONS of ways to generate a key. All of them will give you a key in the end, but the process leading up to it can be done in different, and varying secure ways. Faster ones will use a Pseudo-RNG (insecure), while slower ones will use network events (semi-real-random, and far more secure), or something like mouse movements. Really, you can't compare the two.
File copying: again, it's MOSTLY a function of the encryption algorithm. If you're using a simpler, and less-secure algorithm, you'll get faster transfers, and less CPU utilisation doing those transfers.
It's this kind of thing that Microsoft uses when comparing, for example, IIS and Apache. Their comparisons using HTTPS were done with different hash and encryption algorithms, which make up a HUGE portion of the resource utilisation.
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".
... that's because the individuals don't bring their souls into their finances. Spending power can change the world. Look at the Fair Trade movement (http://www.fairtrade.org.uk/) ... heck don't just look, do something about it.
People hide within the group and don't care if they have Nike shares and Nike abuses child labour (an example from the 90's). The people say "great, more money for me"; then when it becomes public they say "oh shame on Nike".
What is possibly worse is that we, as consumers, say "your doing great" by buying the mega-corps products. There are few markets where there isn't a _more_ ethical alternative.
If the corporations, the groups of people are soul-less
Why do people keep saying that FOSS products don't have licenses?
I suppose because I can use most FOSS products without a license. The GPL is a license relating to copying the code, it has nothing to do with usage. I can use it any way that I want, the license specifically states that you don't have to accept it to use the software.
Do you have ESP?
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.