Personal tools
You are here: Home Writing My HOWTO Zone Using OpenSSH

Using OpenSSH

OpenSSH is gaining momentum. Being a part of most Linux distros, it is likely to supersede SSH Communications in most environments.

This procedure describes how to configure OpenSSH. I assume that both the client and server are running OpenSSH.

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.05a$ ssh-keygen
You must specify a key type (-t).
Usage: ssh-keygen [options]
-b bits Number of bits in the key to create.
-c Change comment in private and public key files.
-e Convert OpenSSH to IETF SECSH key file.
-f filename Filename of the key file.
-i Convert IETF SECSH to OpenSSH key file.
-l Show fingerprint of key file.
-p Change passphrase of private key file.
-q Quiet.
-y Read private key file and print public key.
-t type Specify type of key to create.
-B Show bubblebabble digest of key file.
-C comment Provide new comment.
-N phrase Provide new passphrase.
-P phrase Provide old passphrase.

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, especially in cron scripts, etc. 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-keygen:

ssh-keygen -t dsa -b 1024 -f myKey
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in myKey.
Your public key has been saved in
The key fingerprint is:

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 .ssh directory as follows:

mv myKey* .ssh 

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 ~/.ssh

Identification File

In the preceding discussion, we created a public/private key combination using the DSA algorithm as and myKey, respectively. Unlike SSH Communications, OpenSSH does not provide an easy mechanism for having multiple identities. This requires the user to copy the key file to an identify file name in order to establish his/her identity. These files are named id_dsa and id_rsa (or identity). You will be naming your file id_dsa.

Make sure you are in the .ssh directory and do the following at the prompt:

cp myKey id_dsa

Authorization File

The authorization file $HOME/.ssh/authorized_keys is needed to specify the public keys that are authorized to access your account remotely. You should append your public key ( to this file as follows:

cat >> authorized_keys

Make sure that you type authorized_keys correctly. A common mistake I and my students seem to make is to mistype the name, which is easily mistyped because of the underscore and length.

Enabling SSH Access on a Remote Host

In order to be authenticated on a remote host, it is necessary to have a .ssh 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 at present). This can be done as follows:

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

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.

Important note: The above command is copying the directory (recursively) to the home directory. It is highly recommended that you login using ssh to check whether the directory exists if you are unsure of what is going on before proceeding.


If all goes well, you should be able to ssh from one host to the other 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 .ssh directory are restricted to your eyes only. This means you should have 700 permission on your home directory and .ssh. 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.

Document Actions