Let me preface this message by saying that the "General Discusion" mailing list archived was filled with 99% spam, so I though I'd post here instead to get some real people. My employer is using SSH to replace rcp, rsh and rlogin in its UNIX products. Our experience so far is that the commercial product is slow(1), and difficult to use in scripts where standard input and output are being used, especially if not attached to a terminal. (1) This could be caused by the type of authentication we are using Also, the support is woefull. One of our guys was on-site at a customer, called SSH up for support and was told that the problem he was having is a "known bug" and there is no way around it at the moment. My question is, what reasons should we go with the commercial product? Reasons given me have been: 1 - support 2 - legal liability 3 - upgrades and patches 4 - more secure All of these seem bunk to me. My company has told me that the reasons they are going with SSH from SSH Communications Security Corp are basing on a whitepaper entitled: SSH Secure Shell vs.Open Source Secure Shell: Deployment Considerations for Enterprises, Financial Institutions, and Government Agencies Instead of trying to explain the bias the artical has, perhaps I'll just quote the opening paragraphs: ================="This paper discusses the differences between SSH Secure Shell, a commercial Secure Shell application developed by the original inventor of the Secure Shell protocol, SSH Communications Security Corp, and an open source application, OpenSSH. Open source applications play an important role in academia, home use, non-profit organizations, and non-commercial applications. In general, open source applications are sufficient when support and downtime do not play a critical role. Commercial applications satisfy the critical business needs of enterprises, government agencies, and financial institutions. Commercial applications provide features that are developed specifically to address customer needs and are supported by a professional organization. Many open source applications lack robust features that are needed in today?s business environments, including quick resolution to support issues." =================Footnote: "? 2003 SSH Communications Security Corp. All rights reserved. ssh is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. The SSH logo, SSH2, and SSH Secure Shell are trademarks of SSH Communications Security Corp and may be registered in certain jurisdictions. All other names and marks are the property of their respective owners." =================[ Full whitepaper available here http://www.infinitylimited.net/code/SSH%20vs%20OpenSSH%20-%20March%202003_FINAL.pdf ] Does anyone have any comments? ====Jacob Hawkes, B. Eng (CSE) jakehawkes2001 at yahoo.com http://www.infinitylimited.net/ __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
All I have to add is that we have quite a few really, really big customers who are using OpenSSH enterprise-wide and won't touch commercial ssh. These customers include commercial, educational, and federal government. I decided several years ago to port OpenSSH rather than commercial ssh for all our architectures due to the effective support I felt the open source community provided to the product. Besides the cost issue, we've found that any problem found (especially in the security arena) has been responded to very promptly and the open discussion regarding features and other bugs have aided debugging efforts significantly. Our customers recognize that and were very positive about OpenSSH rather than commercial ssh. I feel that OpenSSH's activities since my decision was made have validated my decision. Any security bug that has been found has been fixed and released much faster by OpenSSH than SSH Communications. If you're on the CERT list, you can tell. I've never come across a bug in OpenSSH that caused downtime in a released system. let's address the issues one at a time i'd be interested to see what evidence Bob Toxen has for the 4-1 ratio of bugs. Technical support - OpenSSH has an open mailing list and the ability for anyone to review the mail archives for bug reports and general discussion. granted, there is no guarantee of response, but the question is leveled at a much larger audience and generally, the questions that remain unanswered are resolved offline or for an unusual OS (that often companies just refuse to port to anyway). 'll let Ben or Marcus respond to the technical questions and regarding ssh and openssh interoperability. It's not an issue my customers have complained about. I'm pretty sure they all use OpenSSH exclusively. total cost of ownership - I completely disagree with the statement- "When major events occur, internal support for OpenSSH is time-consuming and can be very frustrating". I have found that fixed releases of OpenSSH come out much quicker than I expect. The paragraphs regarding pre-compiled binaries and support are so subjective that it's difficult to answer. Because I build and provide binaries to our customers, and do all the testing and debugging they mention, my customers don't have this problem. The worst thing that's happened to them is not enough entropy. liability - This is the real issue - This is the real balance that customers need to think about regarding commercial vs open source. Any site can get hacked into. Certifications - our customers have had no problem with security audits using OpenSSH. Embedded OpenSSH - Cray offers OpenSSH in an optional package. I provide pre-compiled binaries and support recompiled versions. I release 2-3 times per year and provide fix packages as needed. I've never seen anyone respond to a question with "that's a wierd configuration, we don't support it" in the mail archives. I've often seen "what is it you are trying to do?" and "here's how you do it". These are my opinions, I hope they help rather than confuse. Wendy Palm, Cray Inc. Jake Hawkes wrote:> Let me preface this message by saying that the "General Discusion" mailing list archived was > filled with 99% spam, so I though I'd post here instead to get some real people. > > My employer is using SSH to replace rcp, rsh and rlogin in its UNIX products. > > Our experience so far is that the commercial product is slow(1), and difficult to use in scripts > where standard input and output are being used, especially if not attached to a terminal. > > (1) This could be caused by the type of authentication we are using > > Also, the support is woefull. One of our guys was on-site at a customer, called SSH up for > support and was told that the problem he was having is a "known bug" and there is no way around it > at the moment. > > My question is, what reasons should we go with the commercial product? Reasons given me have > been: > 1 - support > 2 - legal liability > 3 - upgrades and patches > 4 - more secure > > All of these seem bunk to me. > > My company has told me that the reasons they are going with SSH from SSH Communications Security > Corp are basing on a whitepaper entitled: > > SSH Secure Shell vs.Open Source Secure Shell: > Deployment Considerations for Enterprises, Financial Institutions, and Government Agencies > > Instead of trying to explain the bias the artical has, perhaps I'll just quote the opening > paragraphs: > > =================> "This paper discusses the differences between SSH Secure Shell, a commercial Secure Shell > application developed by the original inventor of the Secure Shell protocol, SSH Communications > Security Corp, and an open source application, OpenSSH. > > Open source applications play an important role in academia, home use, non-profit organizations, > and non-commercial applications. In general, open source applications are sufficient when support > and downtime do not play a critical role. > > Commercial applications satisfy the critical business needs of enterprises, government agencies, > and financial institutions. Commercial applications provide features that are developed > specifically to address customer needs and are supported by a professional organization. Many open > source applications lack robust features that are needed in today's business environments, > including quick resolution to support issues." > =================> Footnote: > > "? 2003 SSH Communications Security Corp. All rights reserved. ssh is a registered > trademark of SSH Communications Security Corp in the United States and in certain other > jurisdictions. The SSH logo, SSH2, and SSH Secure Shell are trademarks of SSH Communications > Security Corp and may be registered in certain jurisdictions. All other names and marks are the > property of their respective owners." > =================> [ Full whitepaper available here > http://www.infinitylimited.net/code/SSH%20vs%20OpenSSH%20-%20March%202003_FINAL.pdf ] > > Does anyone have any comments? > > > > ====> Jacob Hawkes, B. Eng (CSE) > jakehawkes2001 at yahoo.com > http://www.infinitylimited.net/ > > __________________________________ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >-- wendy palm Cray Open Software Development, Cray Inc. wendyp at cray.com, 651-605-9154
Hi, On Mon, Nov 24, 2003 at 08:28:13AM -0800, Jake Hawkes wrote:> Does anyone have any comments?A customer of mine uses OpenSSH to manage a large network of AIX machines installed all over the country (replacing the old telnet/rlogin based method). "It just works". (It didn't work at all times, but in those cases I've usually been able to figure out myself why it didn't work, and that was much quicker than the usual commercial hotline support you get - "have you upgraded to the latest version? your problem might automagically disappear if you do!") gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
On Mon, 24 Nov 2003, Jake Hawkes wrote:> Let me preface this message by saying that the "General Discusion" > mailing list archived was filled with 99% spam, so I though I'd post > here instead to get some real people. >Hmm.. real people? <looks around> I've been accused of a lot of things, but being a real person is not one. <grin>> My employer is using SSH to replace rcp, rsh and rlogin in its UNIX > products. > > Our experience so far is that the commercial product is slow(1), and > difficult to use in scripts where standard input and output are being > used, especially if not attached to a terminal. >Would be interesting to know what the problem is and if OpenSSH comes closer to solving it.> (1) This could be caused by the type of authentication we are using > > Also, the support is woefull. One of our guys was on-site at a > customer, called SSH up for support and was told that the problem he > was having is a "known bug" and there is no way around it at the moment. > > My question is, what reasons should we go with the commercial product? > Reasons given me have been: > 1 - support > 2 - legal liabilityThis one has urked me. Everyone keeps claiming, "Oh closed source products are better due to legal liability." However when you ask any commerical company if they will pay for any product destruction or breach to a system. You'll see most of them laugh you out of the room. Not implying we provide any liability, but we don't pretend to do so either.> 3 - upgrades and patches > 4 - more secure >The rest are subject at best.> All of these seem bunk to me. > > My company has told me that the reasons they are going with SSH from > SSH Communications Security Corp are basing on a whitepaper entitled: >"Does your company depend on any Open Source products?" - Linux / OpenBSD / FreeBSD / NetBSD? - GCC? - Snort? - Apache? - Tomcat? If the answer is yes. Then you need to seriously suggest the person making the decision re-evaluate how business is done. Maybe they need to replace any open source product (or freeware) being used with commerical only. I think track record and community involvement speak volumes (Commerical and Open Source. Anyone skimming OpenSSH-UNIX-Dev@ list would see posts from NASA, IBM, Sun, Cray, HP, Redhat, Debian, US Military, universities (students and Systems admin), etc. And others prefer privacy in their questions and contact the team or individual developers. Would be great if half of the groups that contacted me would post here. It is impressive where OpenSSH is used. <shrug> I hate statistical stuff myself and this one is getting dated: http://www.openssh.com/usage/ssh-stats.html (I believe there may be a newer versions somewhere.) It is also nice to know that OpenSSH and the greater OpenBSD team has someone awake 24/7 to review security issues and wake up enough of the OpenSSH team if a security release has to be done. As for technical, <shrug> I've always been a fan of "let the product speak for itself". The more hot air you need to blow the more the company is covering up for their flaws. - Ben
Jake, One company I worked for licensed the code from ssh to make modifications to the source, so that it supported their flavor of unix as they wanted it to. Eventually they moved to openssh. Another place (large hosting company during the height of the .com boom). Made custom modifications, and wouldn't even considered using anything but openssh. Currently I work on a HP-UX 10.26, and the only reasonable option for us is to port it ourselves. That is a whole lot cheaper using openssh, and easier. I'm on rare platform, that hardly anyone uses. Still the people on openssh list have been far more helpfully that any commercial support I have delt with. Besides I can always look at the actually mail archive, and figure out what is going on, or look at the code. It is has also generally be easier and faster than anytime I have tried to go through tech support. Granted in some cases it can be harder, or impossible to get open source through audits and certifications. Though I have only ever seen or heard of those problems was with some high assurance applications (such as US DoD related work, or similar). Darren Cole Software Engineer