Introduction
This page gives first an overview and then details of using ssh to communicate with Computer Laboratory systems. For an overview of external access see Remote Access to Lab Systems.
Overview
Internet traffic is neither private nor secure. Data sent from one system to another across the internet can be forged and is subject to intrusion and alteration. To make this more difficult the data can be encrypted and connections between machines can be authenticated using cryptography. This is the purpose of ssh. In order to be able to use ssh properly it is necessary to have some understanding of how it works. This is not as complicated as it may at first seem.
Throughout this page we use the term ssh as a generic name for the client program implementing the SSH protocol. On Linux machines the program is most likely OpenSSH and on Windows machines it is typically PuTTY.
Encryption
Ssh encrypts data passed between hosts using a session key. This is a large number known only to the two hosts in question. The session key is different for each session and is agreed upon at the start of the session using a mathematical protocol which it is believed does not expose the number to anyone intercepting this exchange between the hosts. The session key is then used to encrypt the subsequent data passed between the two hosts. This entire process is almost transparent to the user of the ssh program.
The net result of this is that the information transferred over the ssh connection cannot be intercepted and altered. It is still vulnerable at least two different ways though: Firstly, the machine from which the connection is initiated could have been compromised and could be revealing the communications where they enter and/or leave the encrypted stream. Thus for example, a user's password for logging in to the remote host could be revealed by a program 'watching' keypresses. Secondly the remote host could in fact be a different machine - one controlled by the attacker - which is masquerading as the remote host the user thinks they are communicating with. That machine could then relay traffic to and from the real remote host and the user would be none the wiser. This is known as a 'man in the middle' attack.
For these reasons ssh provides host and user authentication facilities, as well as encryption.
Host authentication
Host authentication is accomplished using a private/public key pair for each host to which ssh connections can be made. Once the above session key has been established, the remote host uses its private host key to digitally sign the session key. It then sends the signature along with its public key to the ssh program which verifies the signature and then checks to see if the host's public key exists in the list of known hosts. If it does not then it generates a warning to the effect that the remote host is not known, or has had its key changed. Along with the warning the ssh program will print a fingerprint of the host's public key. This gives the user the opportunity to verify that the public key is indeed that of the remote host he or she is attempting to establish a connection to. The host key can be checked by looking it up in a database or by verifying over the telephone or via some other relatively secure channel.
User authentication
In addition to authenticating the remote host, ssh can assist in authenticating users. This is done in a similar way to host authentication, using a private/public key pair for the user. Before accepting an ssh connection from a remote user, a host can verify that the user is in posession of a private key without the user revealing the key itself. This is done by ssh using the user's private key to digitally sign the session key. The signature is then passed to the remote host and verified against a copy of the user's public key. Thus, having made their public key available to a given host, a user can authenticate themselves from anywhere on the Internet where they have a copy of the corresponding private key.
Obviously the veracity of the authentication depends entirely on the private key being kept secret: if the private key falls into the wrong hands then authentication is compromised. So private keys should in turn be secured and the means to do this is by protecting them with a passphrase. This is a secret which is known only to the owner of the private key. Before ssh can use the private key to authenticate the user with a host it must decrypt it using the passphrase entered by the user.
Note that in the above, the user's Unix password is no longer required for login. Although ssh can be configured to use the Unix password for authentication this mode is specifically disabled for ssh access to Computer Lab machines.
ssh-agent
Entering passphrases each time a new session is established can become tedious so there are various ssh-agent programs which cache decrypted private keys for subsequent use. This increases the exposure of the keys but only in a limited way that in most situations is an acceptable risk. The agent program on Linux systems is called ssh-agent. There is a program called Pageant that is part of the PuTTY suite for Windows. Details on the use of agent programs are given below.
Multiple user key pairs
Since private keys can be compromised, it is a good idea to have one key pair for each system from which ssh connections are made. In the event that a compromise is suspected the key can be replaced with minimal disruption.
Note that private keys should all have significantly different passphrases. If they do not then the purpose of using multiple private keys is defeated.
To minimise the exposure of the private key it is best to generate it on the machine from which it will be used. Then the associated public key can be transferred to the remote host and installed there. When a public key is registered for use in authentication, the set of IP addresses from which that key is valid can be specified. This should be the most restrictive list possible: ideally just the address of a single host.
Summary
The ssh program encrypts communications to and from a remote host. It also authenticates hosts by checking the hosts' public key against a list of known hosts' keys, and authenticates users to the remote host using the user's private key. Users can have multiple private keys, each, say, for connecting from different external sites.
Making ssh connections
Connecting from Linux/Unix machines with OpenSSH
This section details how to establish a connection from a Unix or Linux machine using OpenSSH to the Computer Lab slogin.cl.cam.ac.uk machines.
Is ssh installed?
The easiest way to find out is to try to run the ssh command. Try
ssh -V
You should be presented with the SSH program and version, perhaps something like
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
If ssh is not installed you will need to get someone to install it or install it yourself. This is not difficult, but the details are beyond the scope of this document.
Obtaining host keys
On any Lab managed Linux machine there is a file /etc/ssh/ssh_known_hosts2 containing the public keys for all Lab hosts. You will probably only need the host keys for slogin.cl.cam.ac.uk machines. These can be obtained with the command
which will produce a file known-hosts containing the public keys.grep slogin /etc/ssh/ssh_known_hosts2 >known_hosts
Next you must place the public keys so obtained into the file ~/.ssh/known_hosts (i.e. the file known_hosts in the .ssh subdirectory of your home directory) on the host from which you are making a connection to the Lab. You can achieve this transfer by almost any means: you can e-mail them, ftp them, transfer them by http or floppy disk or copy-and-paste them from one terminal window to another (if, say, you were logged in using one-time passwords). All that is important is that no-one intercepts and alters them in transit.
Fingerprinting host keys
Alternatively you can take a copy (on paper or otherwise) of the key fingerprints rather than the host keys themselves. Then on making the first connection to a remote host (see Running ssh below) you can check the fingerprint of the key before accepting the connection. If you accept then ssh will add the host's key to your known_hosts file automatically.
The following command on any Lab Un*x or Linux machine will give the key fingerprints of the slogin.cl.cam.ac.uk machines:
/usr/opt/etc/ssh-keyfinger slogin
The fingerprints are
1024 18:02:66:f6:e5:a0:ce:56:8a:be:5e:52:d4:48:77:d2 root@nidd.cl.cam.ac.uk 1024 a9:23:ea:6d:d2:cf:c5:f0:70:88:c2:b7:76:2d:ad:35 root@nidd.cl.cam.ac.uk 1024 68:35:a2:58:57:12:7a:d0:38:82:a4:5c:38:6d:e4:26 root@shep.cl.cam.ac.uk 1024 3c:2e:45:2e:bd:66:28:f9:c2:4c:3f:bc:6b:dd:f6:75 root@shep.cl.cam.ac.uk 1024 0f:4b:3b:78:20:b2:91:65:51:6d:36:17:82:09:6a:7d root@shep.cl.cam.ac.uk 1024 c1:c4:07:cf:cf:62:10:c5:1b:9d:e6:40:bc:74:40:c6 root@shep.cl.cam.ac.uk
Note that you should trust the above fingerprints only in so far as you trust the integrity of the computer you are using to view this page and the intervening network connection(s). It is quite possible for web pages like this one to be 'spoofed'.
Creating user keys
First, you must decide upon and memorise a passphrase for your new key. From the ssh-keygen manual page:
Good passphrases are 10-30 characters long, are not simple sentences or otherwise easily guessable (English prose has only 1-2 bits of entropy per character, and provides very bad passphrases), and contain a mix of upper and lowercase letters, numbers, and non- alphanumeric characters.
Now, on the machine from whcih you are making a connection to the remote host, use ssh-keygen to generate a key pair:
ssh-keygen -t rsa
You will be prompted to enter the name of the file in which to save the key. You can probably accept the default (~/.ssh/id_rsa) if this is the first key you have generated in this home directory. The public key will be stored in the file with same name in the same directory but with the extension .pub appended.
Next you will be prompted to enter the passphrase. You must do this twice because it is entered blind (i.e. without echo of the typed characters.)
Transferring and setting up public keys
Having created your key pair you must now transfer the public key to your Lab Unix home directory. Again, it is a public key you are transferring so it can be sent by any means, as long as it cannot be altered easily by a third party.
Once transferred to your Lab Unix filespace, you must add it to the file ~/.ssh/authorized_keys. The format of this file can be quite complex, but typically it consists of lines beginning
from="host.name.ac.uk" ssh-rsa (long string of key text)
This means that you are enabling ssh connections from the machine host.name.ac.uk using the given key.
A quick way to add a host key to this file is to type (noting back-quotes)
echo 'from="host.name.ac.uk"' `cat id_rsa.pub` >>~/.ssh/authorized_keys
where host.name.ac.uk is the full domain name of the host you want to connect from and id_rsa.pub is the name of the file containing your public key, which you have somehow transferred into your Lab Unix filespace from where it was generated (presumably on host.name.ac.uk.)
The from= can include wildcards and IP addresses as well as host names. It can also inlcude more than one address/name by separating them with commas. This is particularly useful if you are connecting from a number of different machines where your home directory is common. It is also useful if you are connecting from a network where dynamic hostnames and IP addresses are in use. For example, an ISP providing a cable service. In this case you will need to use a wildcard * in the hostname. E.g. from="*.isp.domain.com".
Running ssh
The ssh command is typically
This connects you to one of the Lab slogin machines using the user-id user from where you will be able to issue a further ssh command to any Unix machine within the Lab.ssh user@slogin.cl.cam.ac.uk
If you have not added the host keys for all of the slogin machines to your ~/.ssh/ssh_known_hosts file then you should be warned about connecting with a message like:
The authenticity of host 'slogin.cl.cam.ac.uk (128.232.0.73)' can't be established. RSA key fingerprint is 3c:2e:45:2e:bd:66:28:f9:c2:4c:3f:bc:6b:dd:f6:75. Are you sure you want to continue connecting (yes/no)?
In this case you should check that the fingerprint is in fact that of one of the slogin keys before accepting.
It is also possible that you get a message like this:
No RSA host key is known for slogin.cl.cam.ac.uk and you have requested strict checking. Host key verification failed.
and you are not offered the chance to accept the key on the basis of the fingerprint.
In this case you can run the command again, but with the option -oStrictHostKeyChecking=ask:
ssh -oStrictHostKeyChecking=ask user@slogin.cl.cam.ac.uk
and you will be offered the chance to accept the host key after checking the fingerprint.
If you have other problems, then check the output of ssh with the -v option:
ssh -v user@slogin.cl.cam.ac.uk
This will produce a fairly detailed set of diagnostics and comments about what is happening, from which you may be able to determine what is the problem. If you cannot find the solution yourself then e-mail sys-admin@cl.cam.ac.uk with the above output and a clear description of what you have done (i.e. from which machine you are trying to connect, and which keys you have set up and enabled.)
Using ssh-agent
Normally you need to type the passphrase every time you use your private key to establish a session. This is tedious and the ssh-agent program is a means to avoid having to it more than once per login. Ssh-agent works by decrypting the private key once and caching it in memory. Subsequently, programs can authenticate using the decrypted key by connecting to ssh-agent via a socket on the local machine. (The socket is owned and exclusively readable by the user.)
On most modern Un*x/Linux installations, ssh-agent is already running, albeit with an empty cache. To find out whether ssh-agent is running, enter the command echo $SSH_AUTH_SOCK This should give you something like /tmp/ssh-XXOGradz/agent.15762 if ssh-agent is running, otherwise it should just produce a blank line.
If ssh-agent isn't running, then the easiest way to start it is to type eval `ssh-agent` (note back-quotes).
Once ssh-agent is running, you can use the ssh-add program to add keys to the cache. If you have only one private key in ~/.ssh/id_rsa then just typing ssh-add will prompt you for your passphrase:
$ ssh-add Enter passphrase for ~/.ssh/id_rsa: Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
From now on ssh will get your private key from the ssh-agent cache without requiring you to enter the passphrase.
Connecting with PuTTY
This section details how to establish a connection from a Windows machine using PuTTY to the Computer Lab slogin machines.
Creating user keys with puttygen
First, you must decide upon and memorise a passphrase for your new key. From the ssh-keygen manual page:
Good passphrases are 10-30 characters long, are not simple sentences or otherwise easily guessable (English prose has only 1-2 bits of entropy per character, and provides very bad passphrases), and contain a mix of upper and lowercase letters, numbers, and non- alphanumeric characters.
Next, run PuttyGen to get the window
Once this process is complete the key will be generated
Now you can paste the public key into a local file for later transfer, or directly into another terminal window onto the remote system, to install it in your ~/.ssh/authorized_keys file on your Computer Lab account. See Transferring and setting up public keys above.
Next, enter your chosen passphrase to secure the private key:
Click the Save private key button. Save the private key locally, somewhere others cannot read it.
Running pageant
Start the pageant program.
Click the Add Key button and select your private key file. You will be prompted to enter the passphrase.
Once you have done this the key will be shown in the list. Now you can click the Close button.
The pageant icon will show in the bottom right hand corner of your screen.
PuTTY will now be able to use your private key for authentication.
If you want to add another key you can double-click the icon to bring upo the pageant main window again.
Running PuTTY
Putty does not provide a means to load the registry with known hosts prior to establishing a connection, so you will need a list of host key fingerprints. These can be obtained as described above in the section Fingerprinting Keys.
Run the PuTTY program to get the window shown below.
In the box labelled Host Name (or IP address), type in the host you are connecting to (which will normally be slogin.cl.cam.ac.uk.)
Click the Open button at the bottom right to start the connection. If this is the first time you have connected to the host that replies you will see a box like this:
At this point you must check the host fingerprint against the list you obtained earlier. If the fingerprint is correct, press 'Yes'. Otherwise press 'Cancel' and alert sys-admin that the host key has changed.
Next you will be prompted to enter you user name on the remote system.
Finally you should be logged in.
Connecting without pageant
Pageant is not very secure. It is should not be used on a machine which allows multiple users, or any machine which is publicly accessible because there is a risk that someone could access the program's in-memory copy of the decrypted private key.
In these cases PuTTY can be used without running pageant, but the private key must be loaded before the connection is established. So after entering the remote host name, select the Connection->SSH->Auth branch of the configuration category tree in the left-hand panel of the PuTTY window:
Press the Browse button and select your private key file:
Having set putty up this way you can save the session by clicking on the Session tab in the Category panel on the left, typing a name, slogin say, in the Saved Sessions text box and pressing the Save button. Then next time you want to establish the session, you need only run PuTTY and double-click the session name which will appear thereafter in the Saved Sessions list.