NFS access using sec=krb5
This page is to help users of managed Lab Unix machines with "sec=krb5" (rather than sec=sys which uses the client supplied user info to authenticate and authorise) access to the central Lab filer. This uses Kerberos tickets, normally automatically obtained when logging on at the workstation console, to authenticate user NFS access to the filer (e.g. elmer). This is a complex system, and in most cases 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.
Do nothing: simple Linux workstation use
When logging on to a workstation's console, 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 it can 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.
'kinit -R', 'krenew' or 'cl-krenew': one off use extension (e.g. up to a day)
A very simple one off extension is to run a command such as 'kinit -R', 'krenew' or 'cl-krenew' to extend it by up to a further 'renew' interval, e.g. 10 hours.
'kinit' or 'cl-krenew -f': get a new ticket (e.g. up to a week)
If the ticket has expired, a new ticket needs to be obtained. 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 (a.g. over a week), and arranges for it to be refreshed.
'krenew -K', 'cl-krenew --maxout', 'krb5-ticket-watcher', 'krb5-auth-dialog': Automatic ticket refresh
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'.
ssh -K: ssh access with available ticket
To login from a (recent) Linux machine with an available ticket to another (recent) Linux machine within the Lab, use the -K flag to ssh or the local wrapper script cl-xon which should add the flag automatically.
(Quest) PuTTY: ssh access from a Windows workstation
Windows also uses Kerberos to authenticate the user. If a suitable GSSAPI capable ssh client (e.g. Quest's PuTTY) is used, it can authenticate the user using GSSAPI, and thus not need access to the user's $HOME.
It should also be able to forward the ticket to the Linux machine, but it appears that Quest's 0.60_1q.129 PuTTY does not do this in our environment, even if "Delegate credentials" is ticked. Instead, login using GSSAPI (or otherwise) and run "cl-krenew --maxout; cd $USER && exec bash -l" (needs the user's AD password) to get a "std" session. Subsequent logins (using GSSAPI or ssh user key) should work normally while the ticket remains valid.
local AuthorizedKeysFile: locally cached ssh user key
/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:
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 -tx email@example.com 'cl-krenew --ensuretgt'
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.