How do people manage the root user password on machines they deploy automatically? Pretty much any method I’ve encountered so far requires the root user’s password be coded into the deployment system. For example, in RedHat’s Kickstart the kickstart template contains one of these lines (preferably the second of course, though it’s only slightly better than the first):

rootpw secret
rootpw –iscrypted $1$l5LRLmxk5....

Suse’s AutoYaST isn’t very different:

<user><username>root</username>
  <encrypted config:type="boolean">false</encrypted>
  <user_password>secret</user_password>
</user>

Both Kickstart and AutoYast allow me to prompt the person sitting at the console (who’s impatiently waiting for installation to finish) for the password, but that’s useless for automated installs.

One possibility is to generate machine-specific configuration templates on the fly, each containing a different password for root, but that’s really only a workaround.

So, is the current Worst Practice™ to have dozens, hundreds, or thousands of machines left with the same hard-coded password in them? Probably. And how, and how frequently, are these passwords rolled (i.e. changed)? Never?

I’m experimenting with an idea born from working with remctl and Wallet, which would basically mean:

• build the machine (Kickstart, AutoYaST, etc.) with a hard-coded password for root as configured in the appropriate deployment system. This password will be used for a very short time only, until the setup has completed.
• obtain a machine-specific root password at the end of the installation, optionally during each system startup or on-demand.

I’ve got a prototype working, which works pretty nicely. The front-end is simple: one of the last steps during Kickstart installation is to run the rootpw program, which uses a service principal to invoke a remctl service. This program can obviously also be run periodically or on-demand by the root user:

#!/bin/sh

kinit=/usr/bin/kinit
remctl=/usr/bin/remctl
pwserver=hippo.ww.mens.de
keytab="/etc/srv.wallet.keytab"
princ="service/wallet@MENS.DE"    # principal name in $keytab

export KRB5CCNAME="/tmp/pw.cc.$$"

trap 'rm -f $KRB5CCNAME' 0 1 2 15

$kinit -k -t $keytab -p "${princ}" || exit 2

pw=`$remctl $pwserver rootpw get`
if [ $? -eq 0 ]; then
	echo -n "$pw" | passwd --stdin root
	logger -p authpriv.notice -t rootPW "Password changed for 'root'"
fi

The service principal configured as $princ may only “get” a password – this is configured in remctld.conf in the ACL:

rootpw get  /etc/rootpw/rootpw-get princ:service/wallet@MENS.DE
rootpw show /etc/rootpw/rootpw-admin file:/etc/rootpw/admins.acl
rootpw new  /etc/rootpw/rootpw-admin file:/etc/rootpw/admins.acl

If the client (i.e. the machine which is requesting a password) is requesting a password for the first time, the back-end generates a new random password, stores that in an encrypted database, and returns it to the node, where it is set. Subsequent requests (e.g. because the rootpw program is invoked at every system start) will return the same password until the password is renewed by an authorized administrator. (A periodic renewal is also a possibility.)

Authorized system administrators can use the show command to display the clear-text password for a node, and they can force generation of a new random password with the new command.

The back-end machine containing the password database, obviously needs to be well protected.

I have to let this sink in a bit, but I think it’s overall better than what I’ve seen most places. Do you have any thoughts or suggestions?