(Copied from an old web page.)
Using SSH to access a shared account
Once the .k5login file has been created for the shared account. Users simply use these two commands to access the shared account.
kinit userid@SLAC.STANFORD.EDU
ssh sharedid@machine.slac.stanford.edu
Automatic update of .k5login files for shared Accounts
Shared accounts will need to be handled differently, rather than using the ~/.ssh/authorized_keys file to control access, you will want to use the ~/.k5login file to list the authorized users of the account. The ~/.ssh/authorized_keys method will still continue to work, but you will have to kinit after login to obtain an AFS token. Maintaining the .k5login by hand will be very awkward as the file must be owned by the shared account and have specific permissions ( 0644 ) in order to work properly. SCCS has created an automated process to allow groups to manage the .k5login file effectively. For each shared account you will need to identify a PTS group that contains all the users that are allowed to log in to the shared account. You will then need to contact unix-admin with both the shared account name and pts group. This will be added to the config file and then an automated process will track the entries in the pts group and update the .k5login file at regular intervals. All known current shared account owners will be contacted by SCCS to provide this information.
Here is typical example, in the past SCCS standard practice has been to set up two pts groups for every shared account. If the account was
foobar
The corresponding pts groups would be
foobar:owner-foobar People that can add/delete users from foobar:foobar and ssh into the account
foobar:foobar People that can ssh into the account
In the new system you would no longer need to maintain ssh keys for the people in foobar:foobar, but simply use the pts command to add/delete them from the group.