Computer Laboratory

OpenSSH clients

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

   ssh -V

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

   kinit [Javascript required] 

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

   klist

which will give you a list of keys including one which will look like [Javascript required] which is your Ticket Granting Ticket (tgt) and is the key to making a connection. e.g. on Ubuntu 14.04LTS it looks like

Ticket cache: FILE:/tmp/krb5cc_178
Default principal: [Javascript required]

Valid starting     Expires            Service principal
02/12/15 11:33:50  07/12/15 11:33:50  [Javascript required]
        renew until 24/12/15 11:33:50

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

   ssh -KX [Javascript required]

where K causes your Ticket Granting Ticket (tgt) to be forwarded to the host you are connecting to, ane 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.

Kerberos authentication requires you to request a connection to the canonical name of the machine, rather than to an alias for the service it is providing. If a connection is refused and the host name has a PTR record in the DNS pointing at the canonical name, use that. e.g.

greta:~: host -t ptr slogin.cl.cam.ac.uk
login.cl.cam.ac.uk is an alias for slogin-serv.cl.cam.ac.uk.
slogin-serv.cl.cam.ac.uk domain name pointer ssh-remote-1.cl.cam.ac.uk.
slogin-serv.cl.cam.ac.uk domain name pointer ssh-remote-2.cl.cam.ac.uk.
greta:~: host -t ptr ssh-remote-1.cl.cam.ac.uk.
ssh-remote-1.cl.cam.ac.uk domain name pointer svr-ssh-1.cl.cam.ac.uk.
greta:~: host -t ptr ssh-remote-2.cl.cam.ac.uk.
ssh-remote-2.cl.cam.ac.uk domain name pointer sandy.cl.cam.ac.uk.
greta:~: host -t ptr svr-ssh-1.cl.cam.ac.uk
svr-ssh-1.cl.cam.ac.uk has no PTR record
greta:~: host -t ptr sandy.cl.cam.ac.uk
sandy.cl.cam.ac.uk has no PTR record
greta:~: 

shows that to connect to the slogin service, try svr-ssh-1.cl.cam.ac.uk or sandy.cl.cam.ac.uk.

If you experience difficulties then please try to connect adding a debug key (-v) to the command

  echo `date` `hostname` `who am i`
  ssh -vKX [Javascript required]

and email the commands typed and all output to [Javascript required]. The first line above provides us with some useful information in case we need to look at server logs to diagnose the problem. Also look at sections on ssh-agent and Agent forwarding which can be useful when connecting to machines in the CL that do not support Kerberos based login.

Key based access

Note that if you are not completely confident that you understand what a public/private key pair is, or which part of the pair is used on the client and which part on the server for user and for host authentication then you are likely to run into difficulties in what follows, so please read the introduction and e-mail [Javascript required] if that still does not make things clear.

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.)

Running ssh

The ssh command is typically

  ssh [Javascript required]

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 (128.232.0.73)' 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:

  ssh -oStrictHostKeyChecking=ask [Javascript required]

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 [Javascript required]

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 [Javascript required] 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 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.

Agent forwarding

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.