This is kind of related to Password Best Practices but more specific.

Do you use the same root password for all the servers in your organization? For within a class of devices?

  • Change the title please, so the question in the body matches the question in the title :-)
    – Vinko Vrsalovic
    Jul 13 '09 at 18:58
  • Sorry, wasn't quite thinking right at the time :) Thanks for the edit Sam. Jul 13 '09 at 19:43

13 Answers 13


I'd like to say "yes, everywhere", but it's still "no" in some instances. My company is using Password Safe to manage passwords for our Customers, creating "safes" on a customer-by-customer basis. Many Customers have unique randomly-assigned passwords for root, local administrator, devices, etc. Unfortunately, some (either because of work done by prior vendors, or by laziness on our part) may have the same password used in multiple devices or on multiple server computers.

For my personal passwords I've gotten intereted in moving to a utility like Passwordmaker, which takes a "master passphrase" and some other fact (web site name, username, etc) and creates a random password from a secure hash function. As long as you know your "master password" and the "other fact", you can use the software to regerate your password each time you need it (i.e. the password is never stored anywhere, encrypted, plaintext, or otherwise).

I have yet to find a corporate password "vaulting" tool that does everything I want:

  • SSL-based access from browsers as the UI
  • LDAP authentication, permissions to access passwords in the database based on LDAP group membership.
  • Maintains an audit trail of passwords accessed by each user (so I know what to change when someone leaves the company).
  • Configuratable notifications for password expiration based on user (i.e. "Expire every password that 'bob' ever used since we're firing him"), based on date password last set, or based on number of unique users who have accessed the password ("The whole helpdesk, IT department, and janitorial staff have accessed this password-- expire it.")
  • Metadata on each password including party to notify via email in the event of expiration, creation date, last changed date, notes.
  • Optional plug-in system to allow the password system itself to connect to systems and update expired passwords automatically.
  • Ideally runs on a Windows or Linux-based webserver, probably using sqlite as the back-end.

I'd be willing to throw money or development time at such a project, but I've never found anything that comes close or wanted to spend the time to get it off the ground.

  • +1 for PasswordMaker Dec 27 '11 at 18:33
  • We implemented PasswordState where I used to work, not perfect but the best we could find at the time. And satisfies most of your requirements. clickstudios.com.au
    – Trondh
    Sep 25 '13 at 14:37

I use SSH keys, use the same one for all servers, and maintain a good password on my keyfile. Saves a lot of aggravation.

For devices where this wouldn't work, I'd use a password that had a hard-to-guess core, then use the devices dns name, IP, or other common characteristic (such as OS or brand), to make the password unique for the device. This worked especially well for groups of similar devices. Just keep the pattern/mnemonic secret, along with the core, and you have a difficult, unique password that was easy to remember.


different password for every machine, but we keep them all in a pwsafe. PITA to look up, but stops one breach from having us pwnd.

  • +1 This is the way we do it, too.
    – Bill B
    Jul 14 '09 at 1:43

No, never. What I do to help mnemonics is to have a long (12 chars or so) common prefix that is modified by a medium length attribute (6 chars) of each server if they are in the same rack (or whatever you consider a group of servers, which should be determined on a need to access basis (see Ernie's comment and my answer)).

For example, if the server group is composed by mercury (, smtp), mars (, firewall), bacchus (, web), and the common prefix is R%%SDO23jfida, then

- mercury: R%%SDO23jfida11001mersmtp
- mars: R%%SDO23jfida21001marfirewall
- bacchus: R%%SDO23jfida31001bacweb
  • +1 for the good idea. Beat me to it. :) Jul 13 '09 at 19:03
  • 3
    -1 for a bad idea. Should someone within the company require access to one machine, but not all others, it's not hard for that person to figure out the rest of the passwords. Unless you're the only one who would ever need access (you and your boss at least), in which case more power to you.
    – Ernie
    Jul 13 '09 at 19:44
  • That's why the definition a "group of servers" is relevant. If someone within the company could require access to one machine, but not all others, then those servers do not form a group. You should change the prefix per group as well.
    – Vinko Vrsalovic
    Jul 13 '09 at 19:53
  • The reason I think this is a bad idea is because the suffix is related to the machine name and its purpose. If I only had access to the Mars group, then I could easily guess that the suffix for Mercury is 11001mersmtp, because I know what a reverse DNS address looks like.
    – Ernie
    Jul 13 '09 at 20:40
  • The point is to define the group according to needs. If you can foresee that need, you can a) change the prefix per group and b) change the way of suffix building per group
    – Vinko Vrsalovic
    Jul 13 '09 at 21:18

The one used in the organisation where I was working:

Desktop/Local PC Admin password is all the same (but since we're ghosting all our machines, that is the only way to do it, and if someone ever found that password, we can still change our initial ghost image, and update all machines to receive the new image and we'll be fine.

Each servers has different password. Then again we don't deal with too much servers, if I remember correctly about 6 that I had access to (but I'm sure we had more), and instead of making overly complex password, they opted for simple, easy to remember password, adding reasonable |eet5peak to them, and making them really really long (but again, easy to remember) :)

Personally I believe for desktop PCs, you want to keep the root / admin password the same ensuring easy management using Local Admin Account.

For servers, it is best to be different, to ensure if there is a breach, it is contained purely on that server, and does not go any further. Also the password complexity will change depends on the importance of the server (ie. Server that keeps users/pass will be on highest complexity, server that keeps logs will be on lesser complexity, etc).

My 5c


We do use the same root password everywhere, although it follows the best practices (randomly generated, actually). It is only needed in the case where we have to physically lay hands on a machine, for instance to do a filesystem check or forensics after a compromise. Like Geoff, ssh is the only remote access protocol, and it is disabled for the root user.


We use a randomly generated, retarded long password on each box and we never save it anywhere. normal user auth is managed through LDAP, as is Sudoers, so the only time we EVER need a password is when network access is not working, in which case it's totally acceptable to just down the server and go single-user, fix the network config, and bring it back up.

  • 1
    So why not just disable the root password altogether? I considered just that as well, and the only situation that a rescue disk/single user could not handle was the case when I wanted to do forensics on a compromised machine. Rebooting would clear the process listing which might have valuable evidence. Jul 14 '09 at 0:50

mercury: R%%SDO23jfida11001mersmtp
mars: R%%SDO23jfida21001marfirewall
bacchus: R%%SDO23jfida31001bacw


I've seen many people do this, but no-one could explain how this is more secure than using the same password. What keeps anyone who sees one of the passwords, from figuring out the others? The only advantage seems to be different hashes, but different salts on different machines solves that as well.

Can someone enlighten me on this?

  • I'm guilty of bad examples, but not of bad comments. I really mean that it's not easily guessable if you are out of the secret. You can even read the base password from a piece of paper, but you won't easily guess the varying part unless you are into the secret. that point is of course the same of having the same password, but the idea is protect it from people who are out of the secret and get a hold of the base password. You can change the prefix and way of generating the suffix. In fact, it's the same basic principle Passwordmaker uses, cited in the current top answer.
    – Vinko Vrsalovic
    Jul 13 '09 at 21:44

Considering that the password is the last line of defence, I'd say that it's not as important as it once was.

However, the last thing you need is some yahoo in your office running amok, which is much more common.

Our password policy is to use a hard-to-guess common prefix, then use a common password for each class of server. This reduces the number of passwords I must remember while protecting other servers from "mistakes". Unlike Vinko however, we do not use any system that integrates anything related to the machine. I would recommend against that, since once anyone within the organisation has access to one password (because they need it), they can figure out the other passwords quite easily.

I log all root logins and let the error filter (logcheck in my case) pass them through to my e-mail, so that I know when someone is trying to crack the root password. Restrictions on where it can be done from, ensure that my e-mail is not filled to overflowing with these logs.

  • You are just changing one set of problems for another. What if a person needs to access only one server of all the servers of a class? I prefer a unique password per machine, than a unique password per group of machines
    – Vinko Vrsalovic
    Jul 13 '09 at 19:56
  • Then the policy can change should that eventuality arise. Right now it doesn't matter. The only root password anyone knows but me and the boss is in a machine class of one. But I most certainly do not use anything even vaguely related to the function of the machine, or its IP for the unique bit of the password.
    – Ernie
    Jul 13 '09 at 20:33
  • Exactly, see my comment above, the policy can and SHOULD change according to needs. There is nothing intrinsically worse on having a suffix based on a characteristic of a machine than having it fixed. Machines have plenty of characteristics which can be specified in various and varying ways
    – Vinko Vrsalovic
    Jul 13 '09 at 21:19

I noticed no one talked about changing passwords frequently. Yes, it is a pain... somewhere, but sooner or later any password would leak out (someone who quits?). I think that any kind of password must be changed after a while, no matter what you use as a rule to build it. Our policy is to guess a totally random password about every year, and then proceed to change it gradually on our devices. The gradual change let us have, ironically, a little more security, since at any given time we don't have the same password everywhere (which is not a good thing).


No. A policiy in my last work was to share a common generated password for devices in the same network and add a separator and some characters related to the IP address or the type of device. For example:


But still is insecure. What I do now is generate a different root password for every server or device.

  • as long as the second part is not easily guessable (ie, just the ip address) then it is insecure, but you can easily make things more complex to make it a reasonable secure password)
    – Vinko Vrsalovic
    Jul 13 '09 at 19:39
  • Nope, the idea is for it not to be obvious
    – Vinko Vrsalovic
    Jul 13 '09 at 21:35
  • Really...? "as long as the second part is not easily guessable [..] then it is insecure". I'd say remove the "not", or replace "insecure" with "secure"... :-)
    – Arjan
    Jul 13 '09 at 21:41
  • Heh, right. Replace insecure for secure! :)
    – Vinko Vrsalovic
    Jul 13 '09 at 22:26

i'm surprised no one mentioned this yet but i would be using ldap with kerberos to create a single login that would use SSH keys to specific devices. This of course assumes that the devices I'm attempting to connect to support LDAP authentication. With LDAP, I can create groups of users that have access to specific devices. Also, all my users are logging in via a centralized kerberos server so logins can only happen locally and I can immediately revoke an account in case it gets compromised for some reason.

If you have passwords or keys on 100+ machines, have fun changing all those passwords or authorized_keys files. I don't have to worry about that.

  • 1
    Yes, there is LDAP and Kerberos, and they work great for regular usage. What about devices that don't support them? What about when you need to do maintenance on a server offline when LDAP and Kerberos aren't available? You still need passwords for those cases. Jul 13 '09 at 23:46

Using the same root password for more than one account or device is a bad idea. This will never hold up in an IT audit since there is no accountability. Once someone has the password, they can access multiple accounts and you can't prove who did or didn't do something. I have sometimes seen people try to bring accountability through logging of IP addresses but this is cumbersome and easy to hack.

To bring accountability and pass SOX, PCI, HIPAA, etc you need to limit access to generic accounts to a single person at a time, track what is then accessed and then change the password when they are done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.