replaced python scripting with bash magic
[wiki.git] / 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. Many people only
40 ever type it on their laptop, or on a freshly booted Live CD. Some
41 people feel comfortable typing it on a few private Athena workstations
42 (SIPB office heads are a common choice), but if an attacker has stolen
43 your regular (null instance) password and installed a keylogger on
44 your account, it doesn't matter where you're logging in if it's still
45 your Athena account.
46
47 You can also make things in Moira or AFS owned by your root instance,
48 if you don't want your null instance to be able to mess with mailing
49 lists or lockers. For Moira, make them owned by
50 `KERBEROS:yourname.root@ATHENA.MIT.EDU`. (For legacy Kerberos 4 reasons,
51 Moira and AFS both use a dot instead of a slash to separate the
52 principal and the instance.) For AFS, ask accounts or afsreq to get
53 you a 'pts id', basically an account with the AFS servers, and then
54 you can give bits to yourname.root and start blanching your root
55 instance onto AFS groups.
56
57 To use another instance, just specify it to the kinit command, e.g.,
58 `kinit joeuser/root`.
59
60 ## Handy scripts
61
62 Because you would want to use your null instance tickets most of the
63 time but your root instance tickets occasionally, a couple of people
64 have developed shell scripts to make it easy to switch between them.
65
66  * nelhage has the [krbroot
67    command](http://web.mit.edu/nelhage/Public/krbroot), with which you
68    use syntax like "krbroot ssh linerva" when you want to use your
69    root instance for a command. You can also "krbroot shell".
70
71  * quentin and broder wrote [kdo](http://web.mit.edu/snippets/kerberos/kdo),
72    which is similar in spirit to krbroot, but designed for Mac OS
73    X. It takes advantage of the fact that OS X's Kerberos
74    implementation is better at handling multiple tickets.
75
76  * geofft has [kpagsh](http://web.mit.edu/geofft/Public/bashrc.kpagsh),
77    a way of configuring your .bashrc to prompt you for tickets (null
78    instance by default) if you start a shell and don't have
79    tickets. If you want to switch tickets, you start a new shell, and
80    also a new PAG, which lets you use multiple AFS credentials at
81    once, too. It also modifies your prompt.
82
83 These aliases are also careful to get shorter lifetime tickets that
84 are marked nonforwardable. Some versions of SSH try to forward tickets
85 by default. Since you might let your root instance tickets access many
86 servers, but not trust all of these servers equally, you don't want
87 your tickets to be forwardable. (Thankfully, recent Debian, Ubuntu,
88 and OS X have turned off this default, but it's a good precaution.)
89
90 ## Extra instances
91
92 Another thing you might want is an *extra instance*. Some people use
93 these just like another root instance, with slightly lower
94 security. But a common use is something *less* secure than your null
95 instance. For example, if you're writing a zephyrbot to run on a
96 shared server like `scripts.mit.edu`, the zephyrbot will need Kerberos
97 tickets to subscribe to zephyrs. But you don't want to leave your
98 Kerberos password in a file in your locker, so you can leave your
99 extra instance's password instead.
100
101 ## Getting them
102
103 You need to show up in person to IS&T User Accounts in N42 with a
104 photo ID to obtain new Kerberos identities. For the reasons described
105 above, being in control of your null instance and sending a zephyr or
106 authenticated e-mail with it does not mean that you can go ahead and
107 make changes to your root or extra instance too.  While you're there,
108 be sure to ask for a pts id, if you want to use your tickets with AFS.