doc/root-instance.mdwn

   1 [[!meta title="Root and Extra Instances"]]
   2
   3 This page explains why you want a *root instance*
   4 `joeuser/root@ATHENA.MIT.EDU` and an *extra instance*
   5 `joeuser/extra@ATHENA.MIT.EDU`, how to get them, and how to use them
   6 well.
   7
   8 ## Background
   9
  10 There are three parts of a Kerberos name: a *principal*, an optional
  11 *instance*, and a *realm*. The principal is typically your username
  12 (for Kerberos identities belonging to a user), and the realm, at MIT,
  13 is usually ATHENA.MIT.EDU. (Other realms you may see are
  14 CSAIL.MIT.EDU, ZONE.MIT.EDU, CS.CMU.EDU, etc.) For the Kerberos
  15 identity you typically regard as your own, the one that you use to log
  16 in to Athena with your regular password, the instance is null
  17 (empty). However, you can ask for additional instances, usually a
  18 "root" or "extra" instance. You can use them in places where you
  19 wouldn't want to use your regular Athena password. You usually write a
  20 non-null instance as, e.g., `joeuser/root@ATHENA.MIT.EDU`.
  21
  22 The entire triplet is also often referred to as a principal or
  23 instance, depending on context: "There are two Kerberos principals
  24 that can log in to this server, namely, my extra instance and my root
  25 instance. My null instance can't log in."
  26
  27 ## Typical use
  28
  29 Root instances are often used when logging in to servers that have
  30 some security import. Most students regularly log in to Athena cluster
  31 workstations and quickstations and often type their password on other
  32 people's laptops to SSH or get to webmail. This puts the password at
  33 huge risk for theft. Athena passwords [have been stolen from clusters
  34 in the past](http://tech.mit.edu/V125/PDF/N20.pdf), so it's not the
  35 wisest idea to let servers that you're asking hundreds of people to
  36 log into and use be controlled by a password you're typing everywhere.
  37
  38 So you get a root instance, and only type the root instance password
  39 on computers you trust and only when you need to.  You should only
  40 type your password on a computer that you trust, such a private laptop
  41 or workstation.  If you have access to physical hardware that you
  42 trust, but not a trusted installation, you can use a printed LiveCD,
  43 or a one-time LiveUSB as created by hardware that you trust.
  44
  45 You can also make things in Moira or AFS owned by your root instance,
  46 if you don't want your null instance to be able to mess with mailing
  47 lists or lockers. For Moira, make them owned by
  48 `KERBEROS:yourname/root@ATHENA.MIT.EDU`. For AFS, ask accounts or
  49 afsreq to get you a 'pts id', basically an account with the AFS
  50 servers, and then you can give bits to yourname.root and start
  51 blanching your root instance onto AFS groups.
  52
  53 To use another instance, just specify it to the kinit command, e.g.,
  54 `kinit joeuser/root`.
  55
  56 ## Handy scripts
  57
  58 Because you would want to use your null instance tickets most of the
  59 time but your root instance tickets occasionally, a couple of people
  60 have developed shell scripts to make it easy to switch between them.
  61
  62  * nelhage has the [krbroot
  63    command](http://web.mit.edu/nelhage/Public/krbroot), with which you
  64    use syntax like "krbroot ssh linerva" when you want to use your
  65    root instance for a command. You can also "krbroot shell". adehnert [extended it](https://www.dehnerts.com/gitweb/?p=user/alex/software/my-snippets.git;a=blob;f=krbroot;hb=HEAD) to add a `krbroot screen` subcommand, use `ATHENA_USER`, and support arbitrary principals.
  66
  67  * quentin and broder wrote [kdo](http://web.mit.edu/snippets/kerberos/kdo),
  68    which is similar in spirit to krbroot, but designed for Mac OS
  69    X. It takes advantage of the fact that OS X's Kerberos
  70    implementation is better at handling multiple tickets.
  71
  72  * geofft has [kpagsh](http://web.mit.edu/geofft/Public/bashrc.kpagsh),
  73    a way of configuring your .bashrc to prompt you for tickets (null
  74    instance by default) if you start a shell and don't have
  75    tickets. If you want to switch tickets, you start a new shell, and
  76    also a new PAG, which lets you use multiple AFS credentials at
  77    once, too. It also modifies your prompt.
  78
  79 These aliases are also careful to get shorter lifetime tickets that
  80 are marked nonforwardable. Some versions of SSH try to forward tickets
  81 by default. Since you might let your root instance tickets access many
  82 servers, but not trust all of these servers equally, you don't want
  83 your tickets to be forwardable. (Thankfully, recent Debian, Ubuntu,
  84 and OS X have turned off this default, but it's a good precaution.)
  85
  86 ## Extra instances
  87
  88 Another thing you might want is an *extra instance*. Some people use
  89 these just like another root instance, with slightly lower
  90 security. But a common use is something *less* secure than your null
  91 instance. For example, if you're writing a zephyrbot to run on a
  92 shared server like `scripts.mit.edu`, the zephyrbot will need Kerberos
  93 tickets to subscribe to zephyrs. But you don't want to leave your
  94 Kerberos password in a file in your locker, so you can leave your
  95 extra instance's password instead.
  96
  97 ## Getting them
  98
  99 You need to show up in person to [IS&T User
 100 Accounts](http://ist.mit.edu/support/accounts) in
 101 [E17](http://whereis.mit.edu/?go=E17) during business hours with a
 102 photo ID to obtain new Kerberos identities. For the reasons described
 103 above, being in control of your null instance and sending a zephyr or
 104 authenticated e-mail with it does not mean that you can go ahead and
 105 make changes to your root or extra instance too.  While you're there,
 106 be sure to ask for a pts id, if you want to use your tickets with AFS.
 107
 108 ## Upgrading cryptographic strength
 109
 110 You should change your root instance’s password with a command like this, to upgrade your key from critically weak DES encryption algorithm to strong AES encryption:
 111
 112     kadmin -p andersk/root -q 'cpw -e aes256-cts:normal -e aes128-cts:normal andersk/root'
 113
 114 (Note: This previously made your password incompatible with a [handful of services](http://debathena.mit.edu/trac/ticket/529) that you should not have been using with your root instance in the first place, but these services have now been fixed.)  You can confirm the change with
 115
 116     kadmin -p andersk/root -q 'getprinc andersk/root'
 117
 118 which should list a line like
 119
 120     Key: vno 4, aes256-cts-hmac-sha1-96, no salt
 121
 122 If you change your password again, you will need to specify your desired enctypes with the -e option; otherwise, they will be reset to the defaults.