Personal tools
You are here: Home Writing My HOWTO Zone Using SSH from SSH Communications

Using SSH from SSH Communications

While OpenSSH has become standard on many Linux distributions, many still use the original.

This procedure describes the process for the SSH software from SSH Communications. I also have a procedure for working with OpenSSH (and how to use both SSH Communications and OpenSSH together).

This document also contains instructions on how to connect from Windows. Mac OS X users will need to see my OpenSSH document.

In the ensuing discussion, $HOME refers to your home directory. As user gkt my home directory is /home/gkt.

Getting Started

You should first generate a private/public key pair. This is achieved with the ssh-keygen2. This command can be understood in detail using the -h option.

bash-2.05$ ssh-keygen2 --help 
Usage: ssh-keygen [options] [key1 key2 ...]

Where `options' are:
-b nnn Specify key strength in bits (e.g. 1024)
-t dsa | rsa Choose the key type.
-c comment Provide the comment.
-e file Edit the comment/passphrase of the key.
-p passphrase Provide passphrase.
-P Assume empty passphrase.
-?
-h Print this help text.
-q Suppress the progress indicator.
-1 Convert a SSH 1.x key.
-i file Load and display information on `file'.
-D file Derive the public key from the private key 'file'.
-B number The number base for displaying key information (default 10).
-V Print ssh-keygen version number.
-r file Stir data from file to random pool.
-F file Dump fingerprint of file.

There are a number of options. You'll never really need most of them. There are different key generation schemes, such as RSA and DSA (DSA is the newer scheme and is used by default). When generating the key, you are asked for a passphrase. In general, if you are worried about your key being compromised (e.g. installing on a not-so-secure system), it is important to protect your key with a passphrase. However, there is a key disadvantage to doing so. A major reason that people use ssh is to avoid entering passwords. So if you decide to use a passphrase, you will have to enter a password every time you make ssh connections. Anyway, it is fairly easy. The following shows how you can generate your key (named mykey) using ssh-keygen2:

bash-2.05$ ssh-keygen2 -P mykey 
Generating 1024-bit dsa key pair
1 oOo.oOo.
Key generated.
1024-bit dsa, gkt@www.toolsofcomputing.com, Mon Jan 21 2002 20:49:19 -0600
Private key saved to mykey
Public key saved to mykey.pub

What did we accomplish here? After executing this command, there are two files created in the current working directory. It's important that these files are placed in the .ssh2 directory as follows:

mv mykey* .ssh2 

This directory should also be readable/writable only to yourself. To the world and others, the directory should not have any permissions enabled.

chmod 711 ~ 
chmod 700 ~/.ssh2

Identification File

The identification file $HOME/.ssh2/identification is needed to specify what your private key is. This refers to the private key file, which (as shown above) is named mykey. Here is what the file should look like:

IdKey mykey 

Authorization File

The authorization file $HOME/.ssh2/authorization is needed to specify the public keys that are authorized to access your account remotely. Obviously, you want this to be limited to you, yourself, so it is important not to put anyone's random public keys here. Here is what the file should look like, based on the public/private key we've already generated:

Key mykey.pub 

Note that you can have any number of public keys in this file. This might be necessary if you have generated different keys on different hosts. Keep in mind, however, that you can simply copy the .ssh2 directory (shown below) to the remote host and just use the keys you already have.

Enabling SSH Access on a Remote Host

In order to be authenticated on a remote host, it is necessary to have a .ssh2 directory on each host of interest. In general, this can be done straightforwardly by copying your credentials to the remote host. The best way to do this is to copy the credentials using the scp program. When copying the credentials, it will obviously be necessary to enter a password (since you have no keys on the remote host to begin with). This can be done as follows:

bash$ scp -r .ssh2 remote-host:.ssh2 

where remote-host is the proper hostname of the remote host. You might not need -r; however, when I copy directories from one system to another, I tend to do this habitually.

Testing

If all goes well, you should be able to ssh from one host to another without entering passwords. Needless to say, this  is a great convenience but not one that you should take lightly. The remainder of this discussion focuses on important security matters and should be read before you declare success unilaterally.

  • You can be hacked! This is especially true if you are storing your keys on a system where root access can be obtained easily. This could well be the case for a new Linux or other system you have just set up. Make sure that the people who have superuser (administrative) access are kept to an absolute minimum.

  • You might want to change your keys every so often. The truth of the matter is that one private key (and public key) left around that gets into the wrong hands can expose you in ways you never imagined. While the probability is low (DSA keys are 1024 bits, or 8x longer than 128-bit keys used by other secure protocols) to have your key cracked, you need to take every step to protect your key. Without a passphrase, your key (if captured) is like having diplomatic immunity in every country!

  • Make sure your home directory and the .ssh2 directory are restricted to your eyes only. This means you should have 700 permission on your home directory and .ssh2. If you must have permission to your home directory to allow your public_html or some other directory to be visible, consider using 711 permission. This means your home directory can be searched but not listed, making it difficult for a user to steal your credentials.

  • Be careful if you are using Windows. Windows systems are more prone to security exploits than other platforms, not just due to crappy code (which is common to all operating systems) but due to the nearly ubiquitous desktop presence enjoyed by Windows. This has much to do with the legacy of Unix, which has also been hacked a great deal in its growing years. You need to be cognizant of the fact that Windows systems can be hacked simply by inserting an installation disk and reinstalling the OS, becoming administrator, and then viewing everyone's files. The latest XP has support for an encrypted filesystem but it is hardly in widespread use. Be careful, or be sorry.

Windows Setup

I assume that you have downloaded the Windows client from SSH Communications. There should be a file in this FTP directory for the Windows client. Download and install the program. Make sure you don't change the locations of any of the installed files, at least if you want my instructions to make sense. This procedure assumes you are using Windows NT, 2000, or XP (basically, any version of Windows that isn't essentially DOS). I do not endorse the use of Windows 95, 98, or Millenium for any serious work. This procedure also assumes that you have created a proper account for yourself. You should not be running as the Administrator user. Thank you!

Knowing where stuff is

In Windowsland, where all evil things occur, files tend to be sprinkled all over the place. Worse, you have to type these exorbitantly long paths with spaces in between the names (yuck!) just to get to anything. Program binaries are always copied to some subdirectory of c:\Program Files, while user settings appear in c:\Documents and Settings\username. So, the most important thing to know about is where files are installed and user settings are made, respectively. For ssh from SSH Communications, the installation directory is C:\Program Files\SSH Communications Security\SSH Secure Shell. Here is what you'll find in this directory (similar to the following output):

04/06/2001  02:45 PM            30,096 keymap22.map 
11/13/2001 02:37 AM 16,377 license-non-commercial.txt
11/13/2001 02:36 AM 15,881 license.txt
04/06/2001 06:08 PM 3,015 Output.map
11/13/2001 02:20 AM 1,036,288 scp2.exe
11/13/2001 02:20 AM 1,052,672 sftp2.exe
11/13/2001 02:16 AM 708,608 ssh-keygen2.exe
11/13/2001 02:03 AM 987,136 ssh2.exe
05/29/2001 10:03 AM 1,998 ssh2_config
11/13/2001 01:29 AM 2,842,624 SshClient.exe

Make sure your PATH variable is set correctly; otherwise, you'll not be able to execute these command line versions easily. To set your path in Windows 2000 or XP:

  • go to System control panel
  • select Advanced tab
  • click Environment Variables
  • under User variables click New button
  • type variable name, PATH, if not defined already.
  • type C:\Program Files\SSH Communications Security\SSH Secure Shell. If the variable is already defined, simply add this to the beginning or the end of the list. In Windows, path components are separated by back-slash. Each path is separated by a semi-colon.

Then you should be able to run all of the .exe files from the command line, regardless of what directory you are in. Note that recent versions of SSH Communications seem to set the PATH correctly. Knowing what to do, however, will allow you to fix any problems.

Generate your key and install it properly

As before, generate your public/private key using ssh-keygen2. You might want to do this in the user settings directory, which is C:\Documents and Settings\gkt\Application Data\SSH. Obviously, you will need to change gkt to your user name on Windows. Important Note: The Application Data directory is a hidden directory (another very stupid Windows thing). If you don't see it, just go to the user settings directory and try to CD into it anyway! You can actually make the directory visible using the attrib command, but I do not recommend it unless it really bothers you. If this directory does not exist, you'll have to create it.

I recommend going to C:\Documents and Settings. Verify that the Application Data dir is present. If not, create it using mkdir "Application Data" Then cd to that directory and create a subdirectory named SSH. If you are working at the command line, as in Unix, the cd command will allow you to change directory. Because Windows is so great, you'll have to type all those evil backslashes. Why can't Microsoft make a good command shell? It's because they are so busy innovating (in case you were wondering whether this is a rhetorical question or not.)

Once there, run ssh-keygen2. As with the Unix version, you can specify the name to be used as a prefix for the key file(s) generated. You need not run this command, technically speaking, since you could just copy the files from your Unix server. In fact, you should copy the files identification, myKey, and myKey.pub to C:\Documents and Settings\gkt\Application Data\SSH, again being mindful that your username must appear where you see gkt.

Again, if you go the route of generating a new key on your Windows client, you'll need to make sure that the public key (file ending in .pub) is copied to the remote server, and an appropriate entry is made in the authorization file. It is important, as described for the Unix setup, that an appropriate entry is made in the identification file on the client side. In short, you need to know something about how public-key encryption works. Once you do, a lot of this becomes more intuitive and turns out to be quite the time saver!

Document Actions