Computer Laboratory

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.

Kerberos-based access

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

kinit crsid@AD.CL.CAM.AC.UK

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:

cl-krenew --fresh --maxout

You can check your Kerberos tickets using klist; on Ubuntu 14.04LTS, this 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 still have a valid ticket, you can use any of the commands kinit -R, krenew or cl-krenew 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 cl-krenew --maxout 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 ssh 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

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.

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.

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 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 file known_hosts in the .ssh subdirectory 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. 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. If this is the first key you have generated in this home directory, you can simply accept the default option (~/.ssh/id_rsa). The public key will be stored in a file with the same name in the same directory, but with the extension .pub.

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="" ssh-rsa (long string of key text)

A quick way to add a host key to this file is to type

  echo 'from=""' $(cat >> ~/.ssh/authorized_keys
  chmod go= ~/.ssh/authorized_keys

where is the name of the file containing your public key.

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 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 ",*" rather than "*". 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, 'from="*"'.

Don't forget to run the script /usr/groups/admin/cmds/ 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.

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.

Update slogin servers

Ssh public-key authentication normally checks your private key against those listed in your ~/.ssh/authorized_keys file. 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 slogin-serv machines using the command cl-onserver --fixsshcache.

Using ssh-agent

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

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 , 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-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 the ssh 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 ~/.ssh/authorized_keys 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.