Next: Starting Shishid, Previous: Configuring Shisa, Up: Administration Manual [Contents][Index]
There is a command line interface to the Shisa library, aptly named shisa. You will use this tool to add, remove, and change information stored in the database about realms, principals, and keys. The tool can also be used to “dump” all information in the database, for backup or debugging purposes. (Currently the output format cannot be read by any tool, but functionality to do this will be added in the future, possibly as a read-only file-based Shisa database backend.)
The reference manual (see Parameters for shisa) explains all parameters, but here we will give you a walk-through of the typical uses of the tool.
Installing Shishi usually creates a realm with two principals: one ticket granting ticket for the realm, and one host key for the server. This is what you typically need to get started, but it doesn’t serve our purposes, so we start by removing the principals and the realm. To do that, we need to figure out the name of the realm. The ‘--list’ or ‘--dump’ parameters can be used for this. (Most “long” parameters, like ‘--dump’, have shorter names as well, in this case ‘-d’, Parameters for shisa).
jas@latte:~$ shisa -d
latte
krbtgt/latte
Account is enabled.
Current key version 0 (0x0).
Key 0 (0x0).
Etype aes256-cts-hmac-sha1-96 (0x12, 18).
Salt lattekrbtgt/latte.
host/latte
Account is enabled.
Current key version 0 (0x0).
Key 0 (0x0).
Etype aes256-cts-hmac-sha1-96 (0x12, 18).
Salt lattehost/latte.
jas@latte:~$
The realm names are printed at column 0, the principal names are indented with one ‘TAB’ character (aka ‘\t’ or ASCII 0x09 Horizontal Tabulation), and the information about each principal is indented with two ‘TAB’ characters. The above output means that there is one realm ‘latte’ with two principals: ‘krbtgt/latte’ (which is used to authenticate Kerberos ticket requests) and ‘host/latte’ (used to authenticate host-based applications like Telnet). They were created during ‘make install’ on a host called ‘latte’.
If the installation did not create a default database for you, you might get an error similar to the following output.
jas@latte:~$ shisa -d shisa: Cannot initialize `file' database backend. Location `/usr/local/var/shishi' and options `N/A'. shisa: Initialization failed: Shisa database could not be opened. jas@latte:~$
This indicates that the database does not exist. For a file database, you can create it simply by creating the directory, as follows. Note the access permission change with ‘chmod’. Typically the ‘root’ user would own the files, but as these examples demonstrate, setting up a Kerberos server does not require root access. Indeed, it may be prudent to run all Shishi applications as a special non-‘root’ user, and have all Shishi related files owned by that user, so that any security vulnerabilities do not lead to a system compromise. (However, if the user database is ever stolen, system compromises of other systems may be inoccured, should you use, e.g., a kerberized Telnet.)
jas@latte:~$ mkdir /usr/local/var/shishi jas@latte:~$ chmod go-rwx /usr/local/var/shishi
Back to the first example, where you have a realm ‘latte’ with some principals. We want to remove the realm to demonstrate how you create the realm from scratch. (Of course, you can have more than one realm in the database, but for this example we assume you want to set up a realm named the same as Shishi guessed you would name it, so the existing realm need to be removed first.) The ‘--remove’ (short form ‘-r’) parameter is used for this purpose, as follows.
jas@latte:~$ shisa -r latte host/latte Removing principal `host/latte@latte'... Removing principal `host/latte@latte'...done jas@latte:~$ shisa -r latte krbtgt/latte Removing principal `krbtgt/latte@latte'... Removing principal `krbtgt/latte@latte'...done jas@latte:~$ shisa -r latte Removing realm `latte'... Removing realm `latte'...done jas@latte:~$
You may be asking yourself “What if the realm has many more principals?”. If you fear manual labor (or a small ‘sed’ script, recall the format of ‘--list’?), don’t worry, there is a ‘--force’ (short form ‘-f’) flag. Use it with care. Here is a faster way to do the above:
jas@latte:~$ shisa -r latte -f Removing principal `krbtgt/latte@latte'... Removing principal `krbtgt/latte@latte'...done Removing principal `host/latte@latte'... Removing principal `host/latte@latte'...done Removing realm `latte'... Removing realm `latte'...done jas@latte:~$
You should now have a working, but empty, Shisa database. Let’s set
up the realm manually, step by step. The first step is to decide on
a name for your realm. The full story is explained elsewhere
(see Realm and Principal Naming), but the short story is to take
your DNS domain name and translate it to upper case. For
example, if your organization uses example.org it is a good
idea to use EXAMPLE.ORG as the name of your Kerberos realm.
We’ll use EXAMPLE.ORG as the realm name in these examples.
Let’s create the realm.
jas@latte:~$ shisa -a EXAMPLE.ORG Adding realm `EXAMPLE.ORG'... Adding realm `EXAMPLE.ORG'...done jas@latte:~$
Currently, there are no properties associated with entire realms. In the future, it may be possible to set a default realm-wide password expiry policy or similar. Each realm normally has one principal that is used for authenticating against the “ticket granting service” on the Kerberos server with a ticket instead of using the password. This is used by the user when she acquire a ticket for a server. The principal must look like ‘krbtgt/REALM’ (see Name of the TGS). Let’s create it.
jas@latte:~$ shisa -a EXAMPLE.ORG krbtgt/EXAMPLE.ORG Adding principal `krbtgt/EXAMPLE.ORG@EXAMPLE.ORG'... Adding principal `krbtgt/EXAMPLE.ORG@EXAMPLE.ORG'...done jas@latte:~$
Now that wasn’t difficult, although not very satisfying either. What does adding a principal mean? The name is created, obviously, but it also means setting a few values in the database. Let’s view the entry to find out which values.
jas@latte:~$ shisa -d
EXAMPLE.ORG
krbtgt/EXAMPLE.ORG
Account is enabled.
Current key version 0 (0x0).
Key 0 (0x0).
Etype aes256-cts-hmac-sha1-96 (0x12, 18).
Salt EXAMPLE.ORGkrbtgt/EXAMPLE.ORG.
jas@latte:~$
To use host based security services like SSH or Telnet with Kerberos, each host must have a key shared between the host and the KDC. The key is typically stored in /usr/local/etc/shishi/shishi.keys. We assume your server is called ‘mail.example.org’ and we create the principal. To illustrate a new parameter, we also set the specific algorithm to use by using the ‘--encryption-type’ (short form ‘-E’) parameter.
jas@latte:~$ shisa -a EXAMPLE.ORG host/mail.example.org -E des3 Adding principal `host/mail.example.org@EXAMPLE.ORG'... Adding principal `host/mail.example.org@EXAMPLE.ORG'...done jas@latte:~$
To export the key, there is another Shisa parameter ‘--keys’ that will print the key in a format that is recognized by Shishi. Let’s use it to print the host key.
jas@latte:~$ shisa -d --keys EXAMPLE.ORG host/mail.example.org
EXAMPLE.ORG
host/mail.example.org
Account is enabled.
Current key version 0 (0x0).
Key 0 (0x0).
Etype des3-cbc-sha1-kd (0x10, 16).
-----BEGIN SHISHI KEY-----
Keytype: 16 (des3-cbc-sha1-kd)
Principal: host/mail.example.org
Realm: EXAMPLE.ORG
iQdA8hxdvOUHZNliZJv7noM02rXHV8gq
-----END SHISHI KEY-----
Salt EXAMPLE.ORGhost/mail.example.org.
jas@latte:~$
So to set up the host, simply redirect output to the host key file.
jas@latte:~$ shisa -d --keys EXAMPLE.ORG \
host/mail.example.org >> /usr/local/etc/shishi/shishi.keys
jas@latte:~$
The next logical step is to create a principal for some user, so you can use your password to get a Ticket Granting Ticket via the Authentication Service (AS) from the KDC, and then use the Ticket Granting Service (TGS) from the KDC to get a ticket for a specific host, and then send that ticket to the host to authenticate yourself. Creating this end-user principle is slightly different from the earlier steps, because you want the key to be derived from a password instead of being a random key. The ‘--password’ parameter indicate this. This make the tool ask you for the password.
jas@latte:~$ shisa -a EXAMPLE.ORG simon --password Password for `simon@EXAMPLE.ORG': Adding principal `simon@EXAMPLE.ORG'... Adding principal `simon@EXAMPLE.ORG'...done jas@latte:~$
The only special thing about this principal now is that it has a
password field set in the database.
jas@latte:~$ shisa -d EXAMPLE.ORG simon --keys
EXAMPLE.ORG
simon
Account is enabled.
Current key version 0 (0x0).
Key 0 (0x0).
Etype aes256-cts-hmac-sha1-96 (0x12, 18).
-----BEGIN SHISHI KEY-----
Keytype: 18 (aes256-cts-hmac-sha1-96)
Principal: simon
Realm: EXAMPLE.ORG
Ja7ciNtrAI3gtodLaVDQ5zhcH58ffk0kS5tGAM7ILvM=
-----END SHISHI KEY-----
Salt EXAMPLE.ORGsimon.
Password foo.
jas@latte:~$
You should now be ready to start the KDC, which is explained in the next section (see Starting Shishid), and get tickets as explained earlier (see User Manual).
Next: Starting Shishid, Previous: Configuring Shisa, Up: Administration Manual [Contents][Index]