Kerberos access to the filer
Access to the departmental filer is authenticated via the Kerberos protocol. A user cannot access to their home directory and other parts of the file space stored on the filer unless they have first obtained a “Kerberos ticket granting ticket (krbtgt)”. These are temporary cryptographic keys that are only valid for a limited period (currently between 1 and 30 days). You can see information about your krbtgt using the “klist” command. You can request a fresh krbtgt manually using the “kinit” command.
This page provides advice on how to obtain and manage your Kerberos ticket granting ticket on lab-managed Linux machines in the most convenient ways.
Kerberos is a sophisticated system, and there are many ways to do things. This page just describes a few sample uses which we hope should be sufficient for most users. There is also a WiKi page with a lot more technical details for anyone wanting to dig deeper.
If this page doesn't help you, please email sys-admin with details of what you want to do.
When logging into a lab-managed Linux or Windows workstation locally (on its console keyboard), the password is checked by asking the Kerberos system for a ticket granting ticket. If login succeeds, it stores the ticket in the local filesystem, and that can then be used to access the filer for the default period (e.g. 10 hours). Use klist to see what tickets are cached.
Thus straightforward use of login in at the console, working for up to 10 hours before logging out (and shutting down the machine), should "just work".
It does not allow general use of at or cron commands.
Manually getting a ticket (kinit)
If your ticket has expired, or 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. This uses the 'kinit' command directly, or via the local wrapper script 'cl-krenew' e.g. 'cl-krenew --fresh --maxout' which gets a new ticket for as long as possible (e.g. over a week), and arranges for it to be refreshed.
Renewing a ticket (kinit -R)
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. 10 hours.
Automatically renewing tickets (krenew)
If you remain logged in for longer than the initial lifetime of your ticket (the default is a day), you may lose filer access when your ticket expires and you'll have to call kinit again. To avoid this, 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). 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) setup 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.
Delegate a ticket from a Windows machine (PuTTY)
Lab-managed Windows machines also use Kerberos to authenticate the user. Therefore, any user logged into such a machine (in the AD.CL.CAM.AC.UK domain) will already have the Kerberos ticket required to access the filer.
The SSH client PuTTY has supported Kerberos/GSSAPI based authentication and ticket forwarding since version 0.61. Just tick in PuTTY’s configuration category Connection/SSH/Auth/GSSAPI the boxes “Allow GSSAPI authentication” and “Allow GSSAPI credentials delegation”. Details ...
Login via SSH public key authentication
Ssh public-key authentication normally checks your private key against those listed in your ~/.ssh/authorized_keys file. But if this is located in your home directory on the filer, it will not be available at the time of login and therefore public-key authentication will fail. There are several workaround possible.
locally cached AuthorizedKeys file
/etc/ssh/sshd_config can be configured to use a local copy of users' authorized_keys files, allowing login, but not access to their home directory. They can login and run one of the commands above to setup a ticket. As this uses a cached copy of the file, there will be some delay (e.g. an hour) before the new file is available, unless the user runs "cl-update-authorized-keys" on the machine.
A suitable command (change the userid pb22 to your CRSID) to run on a remote machine to setup a ticket on such a server if one is not already available is:
ssh -tx firstname.lastname@example.org 'cl-krenew --ensuretgt'
Note that if ssh X forwarding is enabled (using the command cl-xon of using the -X flag to ssh), it runs xauth to setup a suitable token to allow X access. By default, this tries to write it to the user's home directory, so it may take 20-30s to timeout trying to access $HOME (it is possible to HACK it to use /tmp). As such, either wait a while, or use the -x flag (as above) to disable X forwarding.
ssh slogin-serv: ssh access if no ticket available
If no ticket is available (e.g. if running an old system, or connecting from outside the Lab), first connect to a time sharing system such as slogin-serv.cl.cam.ac.uk, then run kinit to get a ticket, and ssh to the machine.
Unattended operation (cron jobs, scripts, servers)
We are in the process of upgrading our cron servers. If you need to run jobs periodically that access filer then please email sys-admin to request advise on how to achieve this. There are several technicques that can be used depending upon the exact nature of your work. We will attempt to help you find the most approriate solution.