The first difficulty people run into is related to the two implementations of the SSH or OpenSSH standard.

Firstly there is OpenSSH (http://www.openssh.org) a free implementation. This is the version I will be discussing in this page.

Then there is the SSH Communications Security Corp (http://www.ssh.com) implementation that some people have installed. This is free for non-commercial use, but frankly is not as nice as the OpenSSH version.

To discover what version you are using type ssh -V at the command line. If you see
   OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
you are using the OpenSSH implementation (version 3.4p1 -- which is important, as I will discuss below). If you see
   ssh: SSH Secure Shell 2.4.0 (non-commercial version) on sparc-sun-solaris2.7
you are using the SSH Communications Security Corp (AKA commercial) release. If your output doesn't match this exactly, don't panic, you hopefully can work out which implementation you are using.

Try to use the OpenSSH version. Nearly 60% (at the time of writing, and growing) of internet hosts using Secure Shell, used this derivative (see the usage statistics listed on the OpenSSH web page). If you are using the most common variant, then you have a better chance of being consistent when you access new machine.

ONLY use version 3.4p1 or higher of OpenSSH. If a host you are on uses an older version, point your sysop to http://www.openssh.org/security.html and also the warnings about the vulnerability in zlib 1.1.3 (http://www.zlib.org/advisory-2002-03-11.txt).

ALWAYS try to use SSH protocol 2! Note that protocol 1 lacks a strong mechanism for ensuring the integrity of the connection. (So there!) If you follow the instructions I give below, you will be using protocol 2. This comment is directed at those who want to mess about with what is happening.

If your sysop does not publish the hostkey of their machine hassle them so you can be sure you are connecting to the right place!

For the Impatient: (Actually) Generating a key

It is fairly easy to do:

Filename: I usually give the key file a different name than the default.

This makes knowing WHERE the key to be used easier. For example I have generated a key for use from the Liverpool machines and one for use from Adelaide. Not surprisingly they are called:

Passphrase: You will be asked for a passphrase. As Alan said in his FAQ:

"The pass-phrase is just that... pick a phrase that is memorable to you. Put in a miss-spelling and/or replace a letter by a digit to enhance security."

Remember that this passphrase is all that is stopping someone logging into your account. DO NOT chose it to be the same as your regular password!

Remember that these files should be stored in your ~/.ssh directory. If I talk about a file from now I will be assuming that you are starting in the the ~/.ssh directories, NOT your home (~) directory.

So now you have generated your SSH keys (keys plural -- because there are both public and private keys, but that comes later...) what do we do with them? Read on...

General Comments

There is some confusion on when you need to generate a key. If you are just going to be logging into a machine occasionally you do not need to generate a key.

If you have already generated a key (following the suggestions in Alan's FAQ) delete those keys, on every machine where you copied them, NOW!

Keys in Secure Shell allow you an easy way of identifying yourself, so you don't need to type your password in every time you log into a machine. Think about this for a moment and you will hopefully see the danger. If you don't manage your keys properly, anyone who has access to them can log into your accounts. This is why I strongly suggest you delete the keys that you might have previously generated.

What is the point of generating a key if you don't actually use it?

For the Impatient: Authorising a key

Before a key can be used to access a account, you need to let SSH on that account know which keys it will accept.

With these simple steps you have set up your remote account so that (hopefully) you can use your key for access. Now we need to get the local host to send the keys when you log in.

General Comments

When you generated your key (above) two keys were created. Firstly there is your private key (it is the one NOT ending in .pub). This is the key that allows you to identify yourself and log into other machines. Keep this key safe. Make sure that the permissions are such that no-one else can see the file (chmod og-rwx <file>). If someone else has this key, and your passphrase, they have full access to your accounts...

The other key created is the public key (it's the one finishing in .pub). This is the file that you copy to the machines that you want to log in to using SSH and your key. Remember that you don't need to use keys to log into a machine using SSH, so only copy this to machines that you want to access regularly. I also recommend not using the same key to access machines on different networks. Whilst it is very difficult (think time frames of the order of 10^6 years on a 1GHz Pentium) to get extract the private key from the information in the public key, it is not impossible. If someone obtained your public key on system A, notionally they could use it to access system B. I use the same key coming FROM all the Liverpool University machines, but different keys to come FROM Adelaide. It might be unnecessarily paranoid, but that is what I do.

For the impatient: Using keychain

Add the following to the top of your .bash_profile: (including the "${HOSTNAME}")

The NEXT time you log into a machine that has bash as it's shell, you will be asked for your password. However, see Issues below for a variant of this.

Keychain: keychain is available for download. The version that I used for writing this is 2.0.2.

In practice this means you start the ssh-agent as the first program when you log in, and then subsequently any time you run ssh (or scp or sftp) the authentication of your login will be handled by the agent, meaning if feels like you are using rsh (or rcp), BUT it is still encrypted. This is quite nice.

1. Use ssh -A (for the OpenSSH software) as all password requests will be sent back to your original ssh-agent for verification, so you can do iasc7 -> t3e -> trumpton -> dylan without worrying about passwords. (See below for my current way of automating this)

2. The line in your bash profile will be run on EVERY machine that has bash -- i.e. a new keychain and a new password request EVERY time you log into a machine on the Liverpool network. So...I have

if [ -z "`set|grep -E '(SSH|SSH2)_CLIENT'`" ]; then
  keychain --clear ~/.ssh/Liverpool_id_dsa
  . ~/.keychain/${HOSTNAME}-sh
fi

in my ~/.bash_profile instead. Thus keychain will only be run if there is no SSH_CLIENT environment variable set. SSH sets this when you log in _via_ ssh, so keychain will be run when you log into a machine either from the console, or from telnet, but not when you log in via ssh. This fixes the problems of circular logins that I mentioned previously.

The following is from my .bashrc. I set up $SSH to point to either ssh or ssh -A (depending on the version of ssh that is running). Then I set up the machines I connect to, and finally the aliases to connect to them. I separate the hosts and the aliases so it makes scp easier to use, i.e. I can type

(bash allows TAB completion of "${tru" so I don't have to even get the spelling correct!!!)

Here are the lines............

# Connect to remote hosts.
if [ -n "`ssh -V 2>&1|grep 'OpenSSH'`" ]; then 
  SSH="ssh -A"
else
  SSH="ssh"
fi

# These are the hosts I will be connecting to.
export sune='johndoe@su[snip]...'
export iasc7='johndoe@ia[snip]...'
export dylan='johndoe@dy[snip]...'
export trumpton='johndoe@trum[snip]...'

# These are the aliases making the connection easier.
alias sune='${SSH} ${sune}'
alias iasc7='${SSH} ${iasc7}'
alias dylan='${SSH} ${dylan}'
alias trumpton='${SSH} ${trumpton}'