Get IT Done: Add secure shell support to Windows with OpenSSH

Find out how OpenSSH works in Windows.

If you want to remotely access your Windows 2000 server, you can do so several different ways, including making quick command-line connections using Telnet. The problem with Telnet is that it’s a very unsecure connection, easily monitored and attacked by hackers. Linux and UNIX administrators have long enjoyed the benefits of secure remote command-line connections using Secure Shell (SSH). Now you can bring this simplicity and safety to your Windows 2000 server by using OpenSSH. In this Daily Drill Down, I’ll show you how it works.

What’s OpenSSH for Windows?
Network Simplicity created OpenSSH for Windows as a freeware Windows port of SSH. Network Simplicity shut down its support of OpenSSH for Windows in November 2002, but it was such a useful product that Michael Johnson, a student at Claremont McKenna College, took up the source code for OpenSSH and continued working on it. Network Simplicity’s last version of OpenSSH for Windows was 3.4-3. At the time of this article, Michael’s current version is 3.5p1-3, although he’s currently working on version 3.6.

Although you may doubt the security of a product created by a college student, OpenSSH for Windows 3.5p1-3 builds on the freely available OpenSSH code supplied by Network Simplicity and others. You can obtain original source code directly from the OpenSSH Web site and Cygwin, but the work is already done for you by Michael and it all works well.

Acquiring OpenSSH for Windows
You can download OpenSSH from the Clermont McKenna College Web site. The file you need,, is about 3 MB long, so it will download very quickly. After the download completes, you’ll find that the OpenSSH for Windows version 3.5p1-3 is enclosed in a ZIP file. The ZIP file contains two files: setupssh35-20030324.exe, the Setup program for OpenSSH, and setupssh35-20030324.exe.asc, which is just a checkfile.

Editor’s note
The author currently uses a filename/date naming structure for his downloads. Therefore, you can check to make sure you have the latest release of OpenSSH by checking the name of the download file against the one you previously downloaded.

Pre-flight checks
Before you install OpenSSH for Windows, you should be aware that the server side component is only intended to run on Windows NT, Windows 2000, and Windows XP. There are cases documented on the Internet in which people have been able to make the server-side component work under Windows 98 and Windows ME, but such operation isn’t supported.

Another point to consider before you begin is that the OpenSSH software is designed to use the same port as CYGWIN. If your server has CYGWIN installed and you try to run it along side of OpenSSH, then OpenSSH will attempt to use the existing CYGWIN environment instead of the environment that it is intended to use. The end result is chaos, mass destruction, and all kinds of other nasty side effects. To put it bluntly, you really don’t want to use OpenSSH on a machine that’s already running CYGWIN.

While writing this article, I installed OpenSSH on several machines. I found that on a couple of Windows XP Professional machines, I received a message stating that CYGWIN was already installed on the machine. In each case, the message was incorrect. When such a message is displayed, you’ll see a registry location displayed that supposedly hosts the CYGWIN software. If you don’t recall ever installing CYGWIN on the machine and the specified registry location doesn’t exist, then it’s a pretty safe bet that the error message was incorrect.

Installing OpenSSH for Windows
You begin the setup process by running setupssh35-20030324.exe. The first thing you’ll see is a Welcome screen, which explains that the software is available as freeware. This screen also mentions that if you have previously installed another version of OpenSSH on Windows, you must cancel the Setup wizard, make a backup of your configuration files, uninstall the old version, and then install the current version.

If you click next, you’ll see the License Agreement, which contains the full OpenSSH license. Read it and click I Agree to continue.

Once you get past the informational screens, you’ll be asked whether you want to install the client components or the server components, as seen in Figure A. For the purposes of this article, I’ll be installing both. If you want, you can install only the server components on your server and the client component only on your administration workstation.

Figure A
You can install server and/or client components on your server.

After selecting which modules to install, you’ll see the Start Menu Folder screen. Here you’ll specify the Start Menu folder where Setup will copy the OpenSSH icons. Click Next to go on.

Next, Setup copies all of the necessary files. When the installation process completes, you’ll see a warning message stating that prior to using OpenSSH, you must edit the C:\Program Files\OpenSSH\etc\passwd file. Otherwise, you won’t be able to log in through the SSH server. The message goes on to say that you can find editing instructions in either the README.TXT or in the QUICKSTART.TXT files. You can also learn more about key pair based authentication by reading the KEY_AUTHENTICATION.TXT file.

When the SETUP.EXE program runs, a few things happen in the background. First, SETUP.EXE runs a program in the background called SSH-KEYGEN. This program creates the host keys needed for server operations. In addition, the installation program will use a program called Cygrunsrv to create a service called OpenSSHd. This service controls the OpenSSH server component.

Once the installation process completes, you must reboot the system. You'll never actually see a message prompting you for a reboot, but OpenSSH won’t work right unless you do so. If you attempt to work with OpenSSH without rebooting the server first, authentication will either fail completely or the connection may drop immediately after authentication. However, before you reboot your server, don’t forget the warning you saw during Setup that told you to modify your passwords.

Creating passwords
The PASSWD file is located in the ETC sub folder, just as is the case in a UNIX environment. You can modify the file by using the MKPASSWD or the MKGROUP programs, located in the \Program Files\OpenSSH\BIN folder. Unfortunately, both of these utilities are command-line based and need a little explaining.

The simpler of the two utilities is the MKGROUP utility. The MKGROUP utility is used to add Windows groups to the PASSWD file. You may use the utility to add either local groups or domain groups. The syntax differs only slightly, depending on which you’re adding. The –L switch is used to designate local groups, while the –D switch designates domain groups.

Unfortunately, the MKGROUP utility doesn’t allow you to specify which groups that you want to add to the PASSWD file. Therefore, if you want to grant SSH access on a group basis, you’ll have to use the MKGROUP utility to add all of the available groups to the PASSWD file, and then edit the file to remove the groups that you don’t want.

Before I show you the syntax, there is something important that you need to know. The commands I’m about to show you are literal. They are not abbreviations for longer commands. I spent three hours trying to figure out how the MKGROUP command worked because I incorrectly assumed that the >> ..etcgroup portion of the command was an abbreviation for C:\Program Files\OpenSSH\etc\group. What happens, though, is that C:\Program Files\OpenSSH is imbedded in the registry as the installation location. Therefore, the MKGROUP and the MKPASSWD commands both pull this location from the registry and require you only to specify the \etc folder and the filename (group for MKGROUP or passwd for MKPASSWD). The >> .. portion of the command is also mandatory and represents a literal expression.

To add groups, navigate to the \Program Files\OpenSSH\BIN folder and enter one of the following two commands:
MKGROUP –L >> ..etcgroup
MKGROUP –D >> ..etcgroup

There’s no reason that you can’t add domain and local groups to the group file. If you do, however, remember that there will be some duplicate groups, and you’ll have to use a text editor such as Notepad to open the file and delete the duplicates. Of course, there will probably be other groups that you will want to delete anyway so that you don’t give SSH access to your entire organization.

Adding users with the MKPASSWD command is just as tricky as adding groups with the MKGROUP command. To use the MKPASSWD command, you must open a Command Prompt window and navigate to C:\Program Files\OpenSSH\BIN. Next, enter the MKPASSWD command followed by several switches. First you must specify either –L or –D to indicate either local or domain. Next, you must specify the –U switch to indicate that you are working with a user object.

What happens next depends on whether you’ve selected a local user or a domain user. If you’ve entered a local user or a user from the primary domain, you’ll enter a username. If, however, you’re adding a user from a trusted domain, you’ll enter the user name followed by the domain name. The command is completed by entering:
>> ..\etc\passwd

Once again, this is a literal expression, not an abbreviation for the full path. Below are some literal examples of how to use the command:

Local User:
MKPASSWD –L –U username >> ..\etc\passwd

Domain User:
MKPASSWD –D –U username >> ..\etc\passwd

Using the server with the OpenSSH client
Once you’ve got your users and groups configured, it’s time to test your server. The best way of doing so is to install the OpenSSH client software on another machine, then use that software to connect with your OpenSSH Server. There are three primary utilities that can be used for attaching to the server: SSH, SCP, and SFTP.

The SSH utility is a client program that’s designed to allow a user to log in to a remote machine and execute commands. This utility is designed to replace the UNIX commands RLOGIN and RSH. Unfortunately, it easily would be possible to write an entire article on the SSH command because the command is so complex. Because of space limitations, I will just show you how to use the SSH command to establish a connection to the server.

Begin by opening a Command Prompt window and navigating to the C:\Program Files\OpenSSH\BIN folder. Next, enter the SSH command followed by the user name, the @ symbol, and the server name. For example, if you were trying to attach the Administrator to a server named Bart, you’d enter this command:
SSH Administrator@bart

If this is the first time that you’ve attached the machine to the specified server and you haven’t already made the client aware of the server’s RSA key fingerprint, then you’ll see a message indicating that the server’s authenticity can’t be verified. You’ll then see the server’s RSA fingerprint ID, and will be asked if you want to attach anyway. If you choose to connect, the RSA fingerprint will be added to the list of known hosts. You will then be prompted for the user’s password. After entering the password, you’re authenticated into the system. Below, you can see a sample of what the process looks like:
D:\Program Files\OpenSSH\bin>ssh user15@bart
The authenticity of host 'bart (' can't be established.
RSA key fingerprint is d6:3f:ce:eb:ba:65:61:b7:9f:97:e3:1a:5d:bc:00:8b.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'bart,' (RSA) to the list of known hosts.
user15@bart's password:

SCP is a secure copy program. It can be used to copy files between the local machine and a remote host, or between two remote hosts. SCP uses SSH for the data transfers, and therefore relies on the same authentication and the same security techniques. You can copy a file to a remote host by using the following command:
SCP source_file user@server_name:destination/path/filename

Likewise, you can copy a file from a remote host to a local host with this command:
SCP user@server_name:source/path/filename local_file_name

These commands are not literal. Instead, words like path, filename, and server name refer to the actual names of those objects. A literal example of the command might look something like this:
SCP user1@bart:source/test.txt test.txt

SFTP is a secure version of the FTP protocol. Like SCP, SFTP is also based on SSH and, therefore, uses SSH authentication and security. The biggest difference between SFTP and SCP is that while SCP expects you to specify the filename and path to be used, SFTP is interactive. In fact, you can launch an SFTP session with a server by simply entering this command:
SFTP user@server_name

For example, you might enter SFTP user1@bart.

Potential security risks
As I mentioned earlier, OpenSSH is based on many of the same technologies as CYGWIN. Unfortunately, CYGWIN relies on shared memory spaces on the server that are completely unprotected. This unprotected memory space represents a major security hole, since someone could theoretically alter the contents of the shared memory space in a way that grants them an unauthorized access level or in a way that crashes the server.

Obviously, it sounds a bit strange to talk about security holes caused by a product that’s designed to make your server more secure. According to the README.TXT file that comes with it, OpenSSH is secure as long as only trusted users are allowed to use it. The only way that the insecure memory area can be accessed is by someone who connected to the server through an OpenSSH session. Therefore, if you allow only users that you trust to use OpenSSH, then this theoretically shouldn’t be a problem.

Network Simplicity recommends allowing only administrators, not end users, to use OpenSSH. They also suggest that OpenSSH shouldn’t be used in environments in which security is a top priority. The README.TXT file goes on to say however, that the only questionable part of the OpenSSH product is the CYGWIN subsystem. OpenSSH itself is supposedly secure and Network Simplicity claims that it will prevent unwanted users from logging in.

Safe and secure (?)
During the course of testing and writing about OpenSSH, I ran into numerous problems with the software. Although I never experienced any fatal errors, I found many of the commands to be extremely confusing, and ran into problems with the installation software telling me that a machine had CYGWIN installed when it really didn’t. However, if you need to make secure connections to your Windows 2000 server and want to use the Secure Shell to do so, OpenSSH is the way to go.

Editor's Picks