Setting up the key database

As described earlier, shared keys are stored in a keys file, which is set up and maintained by the cr1 administrator. Whenever you administer the keys file, the key management daemon must be running.

Shared keys are stored in keys files on both the client and server machines. The cr1 administrator of the client must enter a key to be shared by the local and remote systems. The cr1 administrator of the server machine must enter the same key into its key database. The database entry and the syntax of the command used to create the entry differ on the client and server machines; however, the entry always includes the names of the two principals in the exchange and, of course, the shared key. The key must be entered into both the client and server databases locally; there is no service available to propagate cr1 keys on the network.

Typically, authentication is done at the system level. Authorization of individual users is managed locally. If there is a need to deny a user access to a service on a machine, the user is denied access locally, through the standard permissions mechanism.

Although we recommend restricting access through cr1 at the system level, access by individual users can be controlled through cr1, as well. Shared keys can be entered into the key database for individual users. If access is controlled through cr1 at the user level, users can enter and maintain their own keys, in the same way that they maintain their own login passwords in /etc/shadow (see shadow(4)).

The interface to the keys file is the cryptkey (see cryptkey(1bnu)) command. The cryptkey command allows privileged and non-privileged users to add, delete, or modify a key shared by two principals in a cr1 authentication exchange. A non-privileged user must be the local principal for whom the key is being added, deleted, or modified. The privileged user is the owner of the keys file. A privileged user can create, delete, or modify keys for any user on the local system.

The cryptkey command has the following syntax:

cryptkey [-a | -c | -d] [local_principal] remote_principal

For further information on the options, see cryptkey(1bnu).

If cryptkey is entered without options, the -c option is assumed and an existing key shared by the principals is modified.

When the command is entered to add or change a key, the user is prompted to enter a new key; the key can be any alphanumeric string between zero and eight characters in length.

When a non-privileged user is deleting an old key, that user is prompted to enter the old key. When changing a key, a non-privileged user is prompted to enter the old key, followed by the new key.

As with passwords, an administrator may need to change keys for users who do not remember their old keys or remove keys belonging to users who no longer have access to the system. Therefore a privileged user is not required to supply the old key when changing or deleting a key.

Assume you want to create a shared key for adam on your system named eden and for tom on a remote host named utopia. You want to enter ``serpent'' as the key. On the client, you must do the following:

1. Enter:
   
   cryptkey -a adam utopia!tom

   The system then prompts you to enter a key.

2. In response to the prompt, type:
   
   serpent

   The system then prompts you to enter the key a second time.

3. Enter serpent a second time.

   If the first and second entries match, the key is added to the database. If they fail to match, the operation quits.

1. Access the server and enter:
   
   cryptkey -a tom eden!adam

   Again, the system prompts you to enter a key.

2. Enter the same key that was added to the client's database. Type:
   
   serpent

   The system then prompts you to enter the key a second time.

3. Enter the key a second time.

   When you enter the key a second time, and the first and second entries match, the key is added to the server's key database.