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):
Suse’s AutoYaST isn’t very different:
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?
- 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
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:
The service principal configured as
$princ may only “get” a password – this is configured
remctld.conf in the 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?