If you've used our Red Hat machines or other Unix boxes, you might expect to be able to do the following things: * Stay logged in for days at a time * Log in to a bunch of computers via ssh without a password * Create "cron jobs" that run at regular intervals without intervention The Kerberos and AFS-based authentication and file service on our Debian boxes increase the security with which your files are protected, but make the above things more difficult. In particular, you might notice: * Losing access to your home directory after 10 hours * Having to type your password every time you SSH, or logging in without a password and then not being able to access any files * Having cron jobs fail when they try to access your home directory These are all symptoms of not having the cryptographic credentials (Kerberos "tickets" and AFS "tokens") which regulate access to services like your AFS home directory. The good news is that there are workarounds for these problems which should allow you to: * Stay logged in for up to 14 days * SSH between Kerberos-supporting machines without a password * Give cron jobs access to selected files, by setting them up specially. More details for each point follow. * Long jobs and logins Tickets and tokens are established when you log in, and normally expire after 10 hours, for security reasons (an attacker who stole them could access all your files until they expire). However, our accounts should all now support renewing tickets. Sort of like library books, tickets can be renewed for a series of 10-hour periods, as long as you don't miss a renewal, up to a maximum period of 14 days. If you're using the KDE desktop, which is the now the default, a program named "kredentials" will run automatically to renew your tickets as needed; you can tell it's running by a little dog icon on your system tray. The author of "kredentials" also says that it can be run under Gnome using the kdetrayproxy program. In other environments, you can renew your tickets manually by giving the command "renew -R" (the "-R", standing for "renew", is important). Of course, if you want to say be gone overnight, you need something to renew tickets when you're not around. For instance I like to open an xterm running just a loop like (in a bash-like shell): while true; do renew -R; clear; klist -f; sleep 3600; done For long running batch jobs (of the sort you might run with "nohup" or "screen"), there is also a program named "longjob", for which see its man page. Note though that this still imposes a 14-day limit. Of course, if you're considering running a more-than-14-day job accessing files in AFS you should also know that the AFS servers have yet to stay up continuously for any 14-day period in the last month for which I have logs. I believe that a plain "renew", without the "-R", will restart the 14 day session. If that doesn't work, try "kdestroy; renew". * Single sign-on and SSH The public-key-based authentication you may be used to from other Unix systems doesn't work right with AFS because the SSH key isn't sufficient to grant you the privilege of using your files on the remote machine. However, the same effect can be achieved between machines both running Kerberos and appropriate SSH software via a technique called "ticket passing". (More properly "delegation", because it actually works by making you a new ticket on the remote machine, but based on your credentials on the machine you're coming from). After fixing some configuration problems, this should now work without any extra steps between our CSAIL Debian boxes and others like login.csail. (Unlike with SSH public keys, you don't have to generate a key because it's turned on by default, and you don't have to run an "agent" program like ssh-agent because your tickets are stored in plaintext in /tmp on every computer you log in to). It should also interoperate with other Kerberos domains like Athena, though this may require more configuration. Unfortunately it doesn't work from non-Kerberos machines, or even from meoptiplex, the latter because it doesn't have an appropriately modified SSH program. Two other quick hints related to X forwarding and SSH. First, X forwarding will only be enabled by default between CSAIL machines if you give the full name of the computer while connecting; say "ssh yam.csail.mit.edu" rather than "ssh yam". Second, if you have public key authentication enabled, and you try to log into a Debian machine, X forwarding will be broken even if you get credentials after logging in by running "renew", since the SSH daemon needs to be able to write to your home directory at connection establishment to make X forwarding work. You might disable access to your agent by locally messing up the SSH_AUTH_SOCK environment variable, but this has the side effect of breaking agent forwarding later. A better solution, though a bit to type, is to give ssh the option "-o PreferredAuthentications=keyboard-interactive". * Cron jobs Even if cron jobs run with your UID on a machine, they won't have your credentials, and so normally won't be able to non-public files on AFS. If you need a cron job to be able to read or write files in AFS, you need to create a special alternative identity for the cron job, and give that fake identity the appropriate permissions. With an appropriate keytab file and the right commands (see for instance ~saff/public/afs-cron-wrapper) your cron job can assume the identity for the duration of the run and do its work. To create the identity and get the corresponding keytab file, ask TiG at help@csail. More specifically, you should create a copy of afs-cron-wrapper with each instance of "saff" replaced by your username, and each line of your cron job should be prefixed by the full path to that copy. For example, here is one part of my crontab file (which updates the crontab file itself from a local copy that I may have edited during the previous 24 hours): 20 4 * * * /afs/csail/u/m/mernst/bin/share/afs-cron-wrapper crontab $HOME/bin/share/crontab Note that the cron job runs as user "mernst.cron". Therefore, I gave that user access (via running "fs setacl" from the shell, once) to any files that I want cron jobs to be able to access. More on cron jobs Cron jobs: Ask TIG for an individual crontab accounts. The files will be in /afs/csail.mit.edu/group/tig/keytabs/$USER/$USER.keytab, readable and deletable by $USER. These should be stored in a secure (local) file system on the machine where your cron jobs will run, and should be readable only by $USER. I'm assuming it's stored in /etc in the example below. The name of the principal is $USER/cron@CSAIL.MIT.EDU, which in AFS is called $USER.cron. Your cron job needs to call a script of the following form: #!/usr/bin/pagsh # Note, using `pagsh' above is important; do not change. { KRB5CCNAME=/tmp/krb5cc_cron_${USER} export KRB5CCNAME kinit -k -t /etc/${USER}.keytab ${USER}/cron@CSAIL.MIT.EDU aklog kdestroy } # Now running under the UNIX user ${USER} but AFS user ${USER}.cron # rest of your cron job here One way to do this is just to make the crontab command be of the form /afs/csail/u/m/mernst/bin/share/afs-cron-wrapper COMMAND AFS LS: Hello everyone, and welcome to Item #31 (in a series of 94) on "how to have fun with AFS". I knocked together a variation on /bin/ls -l for AFS, that maps AFS owner modes and ACLs into an approximate UNIX file mode. No precise documentation yet, but basically: - the "other" mode bits are derived from the union of "system:anyuser" and "system:authuser" principals (todo: make this configurable); - "system:administrators" are ignored; - the "group" identity is an arbitrary secondary user named in the ACL, if any. (Most often there is only one). Otherwise "none" (and the "other" mode bits are inherited, purely for decoration). - AFS "rwildka" -> UNIX "rwx" mode bits mapping is like this: For directories: r = {r} w = {widk} x = {l} For files: r = {r} w = {wk} x = [unix S_IXUSR bit] - certain kinds of undisplayable information cause the '+' sign to be appended to the mode bits: negative ACLs, >1 secondary users in ACL, etc. In this case, 'fs la' should be consulted. I should probably make the extra functionality optional rather than on by default; however this tool is intended only for interactive use (not scripts), so it should be easy to alias around it. I would like to address chmod in a similar way at some point, and especially umask, since currently all of our permissions are locked-down in a particularly group-unfriendly way and I think this is a bad default. Please find a binary at ~adonovan/bin/Linux-i686/ls. Let me know if it's useful to you; bug reports welcome. More on cron jobs