Contents: Introduction Installing the Cygwin distribution Server side configuration Client side configuration cvs Conclusion Resources About the author Rate this article Related content: OpenSSH key management, Part 1 OpenSSH key management, Part 2 Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Alexandre Polozoff (polozoff@us.ibm.com)
Software Services for WebSphere, IBM
01 May 2002

SSH tunneling provides a secure manner to access CVS repositories. Learn how to install the Cygwin open source OpenSSH provides a secure mechanism for WebSphere Application Server developers on the Microsoft Windows platform.

Introduction
Last winter, a colleague and I were working on a series of papers that we had been e-mailing back and forth. This was a cumbersome way of doing things and we really needed to set up a central CVS repository to work from, which both of us could access securely. This problem was compounded by the fact that we are mobile employees, so we have neither offices nor stationery servers of our own. We also needed a way to supply secure access to the server. The server in question, was an old 500 Mhz Pentium III running Windows 2000 that had spare cycles and sat on my DSL line at home. So secure access was an essential requirement to protect our data.

Solving these challenges, without spending a fortune on expensive hardware or software, was the next step. Obviously this meant taking a good long look at available open technologies. This paper on our solution to the problem: Setting up an OpenSSH tunnel using the open source Cygwin package for secure, remote access of a CVS repository.

Installing the Cygwin distribution
The Cygwin distribution needs to be installed on both the client and server. The same base packages should be installed on both and include the following information from the screenshot in Figure 1.

Figure 1. Cygwin setup window

The Cygwin setup (see Figure 1) window provides a list of the various packages that can be installed. First, you want to click on the "View" button in the upper right hand corner until you see the "Full" view that is shown here. Each package that you want to include requires that you click on the yellow highlighted area until the version number appears. Unfortunately in this screen shot I already have the OpenSSH package installed and it is showing the previous version as a candidate for installation. At any rate, you want to keep clicking in this area of the window until the latest version number appears. Additionally, if you click on the box to the right of the version number you will also download the source for that package. A nice thing about the Cygwin install is that any package dependencies are automatically installed too. While you will not need all the Cygwin packages to run OpenSSH here are the ones I recommend to install:

• bash
• bzip2
• crypt
• cygunsrv (important)
• cygutils
• cvs (obviously)
• Cygwin
• inetutils
• man
• openssh

Leave any dependency packages that Cygwin automatically selects.

System environment variables
From the Windows start menu follow these selections:

Start Menu -> Settings -> Control Panel -> System

Click on the Advanced tab.

Click on the button "Environment Variables"

System environment variables are on the LOWER half of the window. Make sure to add/change variable values there, and not in the top half, which only apply to the logged in user.

Once the packages are installed you want to set the following system environment variables. Be sure to set these up as global system environment variables and not as user variables.

CYGWIN=ntsec

By specifying ntsec you are defining that you are using NT security. This allows for Unix commands like chmod and chown to have relevance in the Cygwin environment.

To the PATH system variable add x:\Cygwin\bin so that the OpenSSH package can find the necessary dll files. I also had to reboot after doing this before the services installed properly.

User environment variables
For each user, define their HOME subdirectory to point to their Cygwin home. Mine is D:\Cygwin\home\alex

Server side configuration
Installing the OpenSSH server is fairly simply. Open up the Cygwin bash shell and type the following commands

$ cd /usr/bin

$ ./ssh-host-config

Answer the prompts, keep the default answers unless you have a reason to change them (you probably will not), and make sure that you answer Yes to install as an NT service -- otherwise it will not install as a service and defeat the purpose of having the server configured.

Setting up users
By having defined the CYGWIN system variable to ntsec you are having Cygwin use NT security to manage logins. But, in order for sshd to be able to accept logins you need a passwd file. This is accomplished with the following code:

$ mkpasswd -l > /etc/passwd

$ mkgroup -l > /etc/group

Make sure that anytime you create or delete users that you run these commands again -- otherwise you will be out of synch with Windows. Also, you will need to restart the Cygwin sshd service for it to read in the new passwd file.

Double check that the passwd file contains each user's home directory. Otherwise OpenSSH will complain that it is not able to switch to the user's home directory when they try to run any commands through the OpenSSH tunnel. It's more of an annoyance than anything else.

Note: The mkpasswd command inserts the user Guest into the passwd file. I deleted this on the off chance it is a security problem.

Fire up the OpenSSH server
That is pretty much it. Look in the Windows Services control panel icon and make sure the "Cygwin sshd" service is started and is configured to start Automatically. If the Cygwin sshd service is not started, start the service manually.

Figure 2. Windows 2000 services control panel

One problem I had during the installation was that the Cygwin sshd service could not find the Cygwin dll files it needed. This was because the PATH variable, even though I had updated it, had somehow not taken effect. Rebooting the machine solved that problem.

Client side configuration
The OpenSSH client configuration is also straightforward. Make sure that you have defined users on the server prior to having people set up OpenSSH clients on their machines, otherwise they will not be able to log in.

System environment variables
On the client machine add the following system environment variable:

CVS_RSH = ssh

Note: There is a whole explanation why the variable is called CVS_RSH and not CVS_SSH and searching www.google.com will satisfy the curiosity of those people. Notwithstanding, this variable is defining that all CVS commands will be run via the OpenSSH tunnel.

You should also set the user's environment variable HOME for your local user.

Passphrase
While you probably do not need to be in your home directory to run the ssh-user-config command in the next section, I just found it comforting. Answer Yes to each and every prompt and then for the passphrase you have a decision you need to make (ssh-user-config generates a number of files in the ~/.ssh directory for the user you are logged in as ).

(alex) (Thu Jan 31 10:24:32  2002) (~/.ssh)

--> ls -l

total 9

-rw-r--r--    1 alex     None          339 Jan 30 16:06 authorized_keys

-rw-r--r--    1 alex     None          840 Jan 30 16:07 authorized_keys2

-rw-r--r--    1 alex     None          668 Jan 30 16:07 id_dsa


-rw-r--r--    1 alex     None          610 Jan 30 16:07 id_dsa.pub

-rw-r--r--    1 alex     None          883 Jan 30 16:06 id_rsa


-rw-r--r--    1 alex     None          230 Jan 30 16:06 id_rsa.pub

-rw-r--r--    1 alex     None          535 Jan 30 16:06 identity


-rw-r--r--    1 alex     None          339 Jan 30 16:06 identity.pub

-rw-r--r--    1 alex     None          247 Jan 30 16:07 known_hosts

These are basically pairs of private/public keys. The public keys have the .pub extension whereas the private keys (in bold) are the same file names without the .pub extension. You need to make sure that you keep your private keys safe otherwise with your private key and your passphrase anyone could masquerade as you through the OpenSSH tunnel to the server.

The known_hosts file is generated after you connect for the first time to an OpenSSH server. ssh will download the server's public key the first time you connect through the OpenSSH tunnel. This way, on subsequent connects, the OpenSSH tunnel can ensure that the server you are connected to is indeed the same server and not someone else masquerading as that server. If you ever change the private/public key pairs on the server then all the clients will have to download the public key again before they can connect to your server.

This is where a security question arises. During the passphrase prompts if you do not enter a passphrase then the OpenSSH server will use only the certificate files to validate the user. This is handy because you can tunnel pretty seamlessly through the server. You need to make a judgment call on whether users accessing your server require a passphrase for access.

So why did I generate all the other private/public key pairs? I don't know -- but I figured it's easier to do it one time than to do it over and over again.

Configuring the OpenSSH client
Open up the Cygwin bash shell and type the following commands:

$ cd
$ /usr/bin/ssh-user-config

Answer Yes (completely typed out) at Yes/No prompts and enter the passphrase (if you are using one) when prompted. You will generate all the possible private/public key pairs this way. Once that is done you need to move some files to the OpenSSH server.

Learning some basic ssh commands
ssh commands follow this command line syntax:

ssh hostname -l username command-line-string

Note: The first time you access an OpenSSH server you will be prompted to get the server's RSA key. Do this so that you automatically verify the server you are connecting to is truly the same server.

Therefore to access my server, polozoff.userv.ibm.com, with my username, alex, and list out the root subdirectory I type the following command line:

ssh polozoff.userv.ibm.com -l alex ls /

Since this is the first time I am accessing the OpenSSH server I am prompted for my password. Type that in and the output of the ls / command is displayed.

An interesting ssh command for debugging purposes is to use the double -v as such:

ssh -v -v polozoff.userv.ibm.com -l alex ls /

which outputs a tremendous amount of interesting trace information of the ssh session.

Using the ssh commands you just learned
Now that you've run some basic ssh commands you need to move some of the public key files you generated to the server so that it can authenticate you properly. From the Cygwin bash shell type the following commands:

$ cd
$ ssh hostname -l username mkdir .ssh
$ ssh hostname -l username chmod og-w .ssh
$ scp ~/.ssh/authorized_keys2 username@hostname:.ssh/authorized_keys2

The actual example of what I typed to run the same commands on hostname=polozoff.userv.ibm.com and username=alex

$ cd
$ ssh polozoff.userv.ibm.com -l alex mkdir .ssh
$ ssh polozoff.userv.ibm.com -l alex chmod og-w .ssh
$ scp ~/.ssh/authorized_keys2 alex@polozoff.userv.ibm.com:.ssh/authorized_keys2

Make sure to type the last command in correctly, otherwise nothing will work properly. The last command securely copies the authorized_keys2 file to the OpenSSH server. Now, when you execute any ssh commands you should not be queried for your password. Instead, if you defined a passphrase, you will be queried for the passphrase. If you entered a blank passphrase then the server will use the public key files to verify your identification without any user interaction.

One thing to note, do not use the authorized_keys file. There are reports of security problems with this file. You will notice that the authorized_keys file is identical to the identity.pub file. They are one and the same.

Accessing the same OpenSSH server from multiple client machines
If you will be accessing the OpenSSH tunnel from more than one client machine, then you should take care to run through all the same steps except for the final scp secure copy. This is because you need to append the text from the authorized_keys2 file instead of overwriting the existing file. Each key you append to the file on the OpenSSH server will allow ssh tunneling to occur from that client machine. In order to do this securely and remotely execute the following commands from a Cygwin bash shell use this code:

$ cd
$ scp ~/.ssh/authorized_keys2 username@hostname:.ssh/newkey
$ ssh hostname -l username cat ~/.ssh/newkey >> ~/.ssh/authorized_keys2

Using CVS
Now that the OpenSSH tunnel is set up you can run any CVS commands across the tunnel and it will seem like you are using a local CVS repository. While this isn't a paper on configuring CVS you need to make sure the following environment variables are set correctly:

CVS_RSH=ssh 
CVSROOT=:ext:alex@polozoff.userv.ibm.com:/usr/local/cvsRepository

The CVS_RSH variable I discussed earlier on tells CVS that all the CVS commands are to use the ssh tunnel you have set up. The CVSROOT variable is dependent on your particular CVS installation but I have included mine as an example of what to use.

Adding VI
Normally when doing CVS commits it pops into vi to enter text for a comment. Install the Cygwin VIM package and then in /bin type:

$ ln -s vim.exe vi

Conclusion
Once again, open source technology has proven its usefulness for solving a problem at absolutely no cost. OpenSSH tunneling is also fairly easy to configure and with the use of private/public key pairs and passphrase verification is an extremely secure environment to work in. While waiting for the Linux migration to finally occur, you can start to reap the benefits of the open technologies available now. Support and use of open source technologies today ensures the eventual transition off of proprietary operating systems will go smoothly and have little impact. And isn't that the point of all of this?

Resources

• The Cygwin Web site has helpful information.
  
  
• In Daniel Robbins two-part article, you'll learn how RSA and DSA authentication work, and see how to set up passwordless authentication the right way.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Tivoli >