[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.4 Networked configuration

If you're planning to use Become in a standalone way, you can skip this section.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.4.1 Choosing servers

Become notices that it's meant to send requests to a server if it finds a `become.server' file. This file contains entries of the form

 
host [: port]

If the port is omitted, Become chooses a port by looking at the services database for a service which matches the name by which Become was invoked: normally this will be `become'.

Become sends a request to all of the servers and believes the first valid reply it receives. Since servers ignore requests they believe to be invalid, this enables you to change Become's key without disrupting service (see section Issuing a new key).

If you're using NIS, you should try to ensure that Become servers runs only on NIS servers; the NIS master is probably a good choice.

Become isn't particularly processor-intensive, and doesn't seem to require very much memory.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.4.2 Setting up keys

Communication between Become clients and the server is encrypted to ensure that it's not feasible to gain unauthorised privilege by subverting the network. Become uses the DSA algorithm to ensure authenticity of replies.

Each client machine, and the server, must have a copy of the same key. The key is usually stored in `/etc/become/become.key'. Become's keys are 128 bits long.

The key file can be generated using Catacomb's key program. The commands

 
key -k /etc/become/become.key add -adsa -e"now + 1 year" become
key -k /etc/become/become.key extract -f -secret /etc/become/become.pubkey

will generate a suitable DSA key, and extract the public part. You should install the public key on all of your client computers, writable only by root. The private key should be only on the server, and readable or writable only by root.

You can also use elliptic-curve DSA. The key-generation runes are more complicated in this case. For example,

 
key -k /etc/become/become.key add -aec -Cnist-p256 -e"now + 1 year" \
    become sig=ecdsa hash=sha256

The hash=sha256 is not required, but it's good to have a hash function as strong as your curve. See the manpage for key for more details about generating elliptic curve keys, and for the kinds of curves supported.

If you have multiple servers, they can all have different private keys. You'll need to put all of the public keys in the `/etc/become/become.pubkey' file.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.4.3 Issuing a new key

When you're sending out a new key, you run a risk of disrupting service. The server reads a new key; the clients still have the old one.

We used to recommend running two servers. Now, however, you can generate the new key, install the new public key on the clients in addition to the old one, and then install the new private key on the server. The clients try all valid public keys when attempting to authenticate a response, so this approach will work.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated by Mark Wooding on March, 14 2006 using texi2html 1.76.