On Sun, 15 May 2011, Mark McCullough wrote: > On 2011 May 15, at 18:56, Tracy Reed wrote: > >> The prefix (same on every machine) then an underscore followed by the first >> four letters of the hostname. For the record, I recognize this as a really >> bad >> idea. They are even an e-commerce shop so credit card data is involved. I am >> working on getting this changed but they have been told "never write down >> passwords." so there has been resistence. There are password keeper programs >> which use a master password to encrypt the list of passwords but those work >> better for personal use: If we have to change or add a server root password I >> don't want to have to get everyone to update their personal lists. I am >> leaning >> towards A GPG encrypted file on an internal server somewhere as is my >> standard >> practice although if The Boss, who has no command line skills, wants access >> to >> it also for purely territorial reasons as he has no legitimate reason, that >> may >> be an issue. >> >> I'm sure this is a common problem. What do the rest of you do? > > My old method was to use PasswordSafe, storing passwords for the various > systems, sharing the encrypted file with others on the team. They would then > out of band share the master password (which also changed regularly.) > > My even older method was an encrypted email with the server name and root > password, sent to the whole team. It also held the -1 and -2 passwords in > case a system failed to be changed for some reason. > > I currently take steps to make the root password inconvenient. Any usage of > it requires it to be changed. Anyone who uses it without a change request or > problem ticket gets a nastygram reminding them that the root password is > prohibited for routine usage. (We check su logs, direct login to console > logs, etc.) > > The best way to deal with the root password is to minimize its use. Then > make sure your passwords are randomly generated. The hard thing that most > people forget is a copy of that password should be kept in case of disaster > (you win the lottery, get hit by the bus, etc.)
there are a couple of good commercial tools out there to deal with this. Hitachi ID has their Privilages Password Manager software E-DMZ has an appliance what these do is that they change the password on a regular basis, and have a web based tool (complete with authorization/approval workflow options) that let you 'check out' the password. once your time expires, the tool changes the password again. this gives you a pretty complete audit trail of who had the root password for any box at any given time. This only works well if you don't normally use the root password when working on the machines (i.e. most administration is via sudo, puppet, cfengine, or similar) David Lang _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
