There are two alternative ways to set up ssh connection to the department. The first is to use Kerberos credentials and is the preferred route for most users. The second is to use an ssh key pair and is described in the second and more detailed part of this page.
The expectation is that most users will be able to use the kerberos authentication method to connect to machines from their private machines and within the department and that the need to set up and maintain ssh key pairs will be minimal.
This page describes how to use OpenSSH clients under Unix and Linux to connect to Computer Lab systems from 'outside.' This includes from so-called alien machines in the al.cl.cam.ac.uk domain.
Is ssh installed?
The easiest way to find out is to try to run the ssh command. Try
You should be presented with the SSH program and version, perhaps something like
OpenSSH_6.6.1p1 Ubuntu-2Ubuntu2.3, OpenSSL 1.0.1f 6 Jan 2014
If ssh is not installed (which is very unusual these days) you will need to get someone to install it for you, or install it yourself. This is not especially difficult if you are used to compiling and installing programs on Unix/Linux, but the details are beyond the scope of this document.
Kerberos based access
To use the Kerberos based authentication of an ssh session you need to ensure that your client machine can connect to the Computer Laboratory Kerberos servers. All machines connected to University networks should be able to connect to them (if you are not on a University network then you need to open a VPN first). To check your connectivity you can try to create a ticket using
note the capitalisation is important and you should substitute your crsid (user id) in the above identifier. The command will prompt your for your password which is your CL account password (not Raven).
If that succeeds then you will now have a Kerberos key which you can check using
If you cannot connect to the Kerberos server directly and get a ticket then first start up a VPN and try again.
To open a connection to a host you should then use something like
where K causes your Ticket Granting Ticket (tgt) to be forwarded to the host you are connecting to, X sets up X forwarding back to your client. It is best to add the crsid before the host name as you are likely to be using a different host name on a private laptop so just get in the habit of using that form.
If you experience difficulties then please try to connect adding a debug key (-v) to the command
Key based access
Certain subsequent sections of this document assume familiarity with the structure of ssh sessions and the use of keys for host and user verification. See an overview of ssh for example.
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 the slogin machines, normally just the slogin-serv.cl.cam.ac.uk ones. These can be obtained with the command
grep -h slogin /etc/ssh/ssh_known_* >known_hosts
which will produce a file known-hosts containing the public keys.
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.
For information on how to find the Fingerprint of host keys see Fingerprinting host keys.
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 which 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 public key 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 (or copy/paste and edit from here)
echo 'from="host.name.ac.uk"' $(cat id_rsa.pub) >> ~/.ssh/authorized_keys chmod go= ~/.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 home directory 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 include 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".
The chmod command is sometimes necessary because the ssh server will not use the contents of ~/.ssh/authorized_keys if the file is writable by anyone other than the user attempting the connection (even if it is writable only by a group of which the owner is the sole member.)
The ssh command is typically
This connects you to one of the Lab slogin-serv 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.
If you have not added the host keys for all of the slogin machines, in this case slogin-serv, to your ~/.ssh/ssh_known_hosts file then you should be warned about connecting with a message like:
The authenticity of host 'slogin-serv.cl.cam.ac.uk (184.108.40.206)' can't be established. RSA key fingerprint is c1:c4:07:cf:cf:62:10:c5:1b:9d:e6:40:bc:74:40:c6. 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 key fingerprints you previously copied 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:
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:
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 runs for the duration of any X windows login session. 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)
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.
The ssh-agent cache can be made available to ssh-slients running on other hosts via a mechanism called agent forwarding. Essentially this is just a matter of the ssh-agent making the keys available to client programs over a socket connection which the ssh clients forward to the remote hosts they are connecting to. By default, agent forwarding is disabled, but by adding the -A option to the ssh command line it can be switched on. In this way it is possible for one private key to be used from multiple sites whilst only being decrypted once at the start of the session (so the passphrase is only typed once when ssh-add is run for the first time.) Of course the public key must be listed in ~/.ssh/authorized_keys with the names of all the hosts from where it will be used (even of those hosts never see the private key itself.)
Note that agent forwarding should only be used to connect to sites where you trust the people with root privilege: anyone with root privileges on the site you are connecting to can use the forwarded agent socket to authenticate other connections 'as you' using any of the private keys in the cache.