- OpenSSH for Windows: Is Cygwin Good Enough?
- Using Web Technologies as an SSH Replacement: A Feasibility Study
I think all of us in the IT world are acclimated to the need to work with multiple platforms. Without a doubt, SSH’s ability to accommodate so many platforms, with commercial and Open Source alternatives, is great. That said, there is one platform best handled by the commercial versions: Windows. This is one very important platform, one whose servers tend to be in high numbers. This means a commercial solution can be an expensive option to achieve the goal of cross-platform interoperability.
This article discusses other technical architectures that can reproduce the most basic SSH features across all platforms.
Before that, let me openly discuss why the thought of implementing many Open Source SSH alternatives onto Windows sends me to commercial versions. To be sure, the commercial alternatives have a good security history. I really enjoy the great way SSH Communications has the essential SSH abilities in an easy-to-use software package. The issue is one of cost for many companies. So let’s begin by talking about SSH on Windows.
OpenSSH for Windows: Is Cygwin Good Enough?
The OpenSSH group does not code for Windows. Its website lists several excellent Windows clients, but we’re hunting servers... This has you stumbling about the Internet looking for a version others have created.
This is a security tool, a part of your organization’s security architecture. One-guy, one-off tools are unacceptable if your information is truly confidential and needs security. Don’t try one of these projects unless there are several people and, hopefully, an organization providing support. My last Internet sampling showed too many dated projects, most of which used old versions of OpenSSH and Cygwin.
Dated software can be unsafe software. Don’t install a free software package without looking into the details, such as version risks and intended use. What does Cygwin state about the intended use of its products?
In the past, Cygwin project leaders wrote about shared memory use possibly becoming security issues. Consider this posting at http://www.cygwin.com/ml/cygwin/2005-12/msg00077.html. I really respect Cygwin’s, um, Open discussion of possible issues. This is typical of the group’s honesty and integrity.
What are the challenges faced when attempting to map UNIX security attributes with Windows? Here again, the Cygwin group provides great information in http://www.cygwin.com/cygwin-ug-net/ntsec.html.
The Cygwin group’s stance regarding security is also repeated by the Apache HTTP Server Project group. Many people want to run Apache on Cygwin, itself running on Windows, to provide a UNIX layer that is familiar to UNIX administrators. In response, the Apache HTTP Server Project group states:
"...The Cygwin port may suffer from gaps in security or reliability due to the interaction of the Cygwin compatibility layer with the native Windows API."
The risks are stated plainly when comparing the Cygwin port with the Apache group’s own Win32 port:
"The Win32 port should be considered the more secure of the two at this time."
So let’s have no criticism of any Open Source project if you are hacked when using Cygwin and companion daemons in a security-sensitive context.
Consider the big differences in the security models for Windows and UNIX. Consider file permissions between the two operating systems. Mapping Windows’ many permission privileges into the UNIX 3×3 Factorial of user-group-"other" and read, write, execute/traverse directory is not easily done. Those who insist on using products that do this mapping with highly confidential information have only themselves to blame when hacked. I’m writing this in defense of any Cygwin, Apache, Samba, and other issues you may bring on yourself. Additionally, while no one has confirmed that the use of the shared memory in Cygwin may be a security risk, I look forward to an organization that takes up Corinna Vinschen’s offer of a support contract with Red Hat, to do a full security analysis.
So right now, you’re left needing a method to invoke shared processing across many platforms, potentially moving or gathering files. You need a technology that has deep support from the actual vendor and deep integration with the native security model for the platform, to avoid permission bit logical holes. You also want good memory management—one that doesn’t provide a common "info-kettle" from which others might fetch valuable data. Is there anything that can do this?
There sure is! Let’s go to the web.