SSH on Unix
On Unix, there are two 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. The expectation is that most users will be able to use the kerberos authentication method and that the need to set up and maintain ssh key pairs will be minimal.
A Kerberos ticket is a piece of cryptographic data that you can obtain from the department’s Kerberos server using your Kerberos password, and which allows you to log into other machines or access the filer without having to type your password each time. Our Kerberos tickets are valid for up to 30 days.
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. If you are using a Lab-managed machine, you will get a ticket-granting ticket (tgt) from the Kerberos system at each successful login. This ticket is then stored in the local filesystem and can be used to access the filer for the default period (e.g. 10 hours).
If your ticket has expired, or if you logged in via any means that does not automatically give you a ticket (ssh public key authentication, OTPW), you need to manually obtain a new ticket before you can access the filer. Run
to get a new ticket. The command will prompt your for your CL account password.
If you are logged in using Kerberos, the login process uses a per-session ticket, which it deletes when the session ends.
To create a ticket which remains available after the session ends, unset the
KRB5CCNAME when running kinit, or use the local
cl-krenew wrapper, e.g. one of the following:
KRB5CCNAME= kinit cl-krenew --fresh --maxout
You can check your Kerberos tickets using
klist; on Ubuntu 14.04LTS, this looks like:
If you still have a valid ticket, you can use any of the commands
to extend its lifetime by up to a further 'renew' interval, e.g. 5 days.
Automatically renewing tickets (krenew)
If you remain logged in for longer than the initial lifetime of your ticket (the default is 5 days), you may lose filer access when your ticket expires and you'll have to call kinit again. To avoid this, many systems, such as slogin machines, automatically refresh all tickets every day.
If using a machine which does not have the
cl-anacron-krenew-all package installed,
either install it, or use a tool that automatically renews your ticket and
prompts you for your password when necessary.
krenew -K 60 or
will keep renewing it as long as possible, but these both work only if the ticket is still valid.
To keep the ticket refreshed even if the machine reboots (on those machines which do not clear /tmp), set up a cron job with the line such as
@reboot cl-krenew --cronboot.
Delegate a ticket from a Linux machine to another (ssh -K)
To login from a Linux machine with an available ticket to another
Linux machine within the Lab, use the
-K flag to
or the local wrapper script
cl-xon, which should add the flag automatically.
This not only allows
ssh to use the existing ticket for authentication,
but also copies the ticket onto the destination machine, such that it is immediately
available there for access to the filer.
To open a connection to a host, you should then use something like
ssh -KX firstname.lastname@example.org
where K causes your ticket-granting ticket (tgt) to be forwarded to the host you are connecting to, and X sets up X forwarding back to your client. Make sure you use the canonical name of the host, rather than an alias for the service it is providing.
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.
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
grep -h slogin /etc/ssh/ssh_known_* >known_hosts
which will produce a file
known_hosts containing the
Next you must place the file
known_hosts in the
of your home directory (
~/.ssh/known_hosts) on the host from which you are making a
connection to the Lab.
Creating user keys
First, you must create a memorable passphrase for your new key.
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
ssh-keygen -t rsa
You will be prompted to enter the name of the file in which to save the key. If
this is the first key you have generated in this home directory, you can simply accept the default option (
public key will be stored in a file with the same name in the same
directory, but with the extension
You will then be prompted to enter your 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. Once transferred to your Lab Unix filespace, you must add it to the file
~/.ssh/authorized_keys. The format of this file typically consists of lines beginning with:
from="host.name.ac.uk" ssh-rsa (long string of key text)
A quick way to add a host key to this file is to type
echo 'from="host.name.ac.uk"' $(cat id_rsa.pub) >> ~/.ssh/authorized_keys chmod go= ~/.ssh/authorized_keys
the name of the file containing your public key.
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).
from= restriction indicates the hosts from which your public key can be used. For security purposes, the best practice is to keep the list as restrictive as possible: ideally, just the IP address or full domain name of a single host. However, if you are connecting from multiple machines or have a dynamic IP address, you may need to include a wildcard to indicate a range of hosts. For connections from machine in the Lab, this may be "
so that any machine may be used.
Laptops and similar mobile devices may be connected from several places, e.g. in the lab, in college and at home. The list of possible locations should be put in as a comma separated list. To prevent any security breaches, it is advisable to restrict the locations as much as possible, e.g. using "
*.cam.ac.uk". When travelling, the location may be unknown in advance, so you can append another line (using the same key) with a single global wild card,
Don't forget to run the script
after changing the
authorized_keys file to check that it is acceptable.
A cron job runs the checker script to look for "unacceptable" lines, sending warning emails to the user, and if the problem is not fixed, it renames the file, causing ssh user key authentication to stop working.
The ssh command is typically
This connects you to one of the Lab
slogin-serv machines using
user from where you will be able to issue a further
ssh command to any Unix machine within the Lab.
Update slogin servers
Ssh public-key authentication normally checks your private key against those listed in your
If you are using a Time Sharing System which uses a local cached copy of the
authorized_keys file, the local cached copy may take a while to be updated unless
cl-update-authorized-keys is run to update the local copy to
allow immediate testing. Alternatively, a script can be run to update the
machines using the command
Normally, you need to type the passphrase every time you use your private
key to establish a session. This can get fairly tedious, so in order to avoid having to type your passphrase more than once per login, you can use the
Ssh-agent works by decrypting the private key once and caching
it in memory. Subsequently, programs can authenticate using the decrypted key by
ssh-agent via a socket on the local machine.
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
Once ssh-agent is running, you can use the
program to add keys to the cache. If you have only one private key in
~/.ssh/id_rsa , just typing
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-clients running on
other hosts via a mechanism called 'agent forwarding.'
Essentially, this is 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. By default, agent
forwarding is disabled, but it can be switched on by adding the
-A option to
command line. 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. The
public key must be listed in
with the names of all the hosts from where it will be used, even if
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.