Server password management is obsolete
16th of October 2007
When setting up new systems for a client recently, I've realized how I've instinctively avoided the quagmire that is password management on servers -- and maybe you can, too!
I'm not concerned with administrative and policy-related reasons to keep managing password access information, I'll only describe technical means to avoid this issue altogether. If those are not enough in your environment and you think they ought to be, maybe you could apply for a job at Fry-IT!
For remote access SSH public keys are by far superior to passwords, as they allow much more fine-grained access management, in a more secure manner. Multiple keys can be added to one account and any of them removed at any time, without influencing the rest. Compare this to the situation that must arise when a key system administrator leaves the company and the remaining users have to all get used to a new password (this would be a genuinely good reason to change the password, unlike time expiry mechanisms that just make people stick the password-du-jour to their monitor on a Post-It note). The improved security comes from the fact SSH access is no longer exploitable via blind brute force attacks on passwords of various system accounts, of which I could at some point count up to 20,000 per month per machine on a particularly exposed network, since password login shouldn't be available at all, when using SSH public keys properly. It is still possible to connect to a series of machines in sequence, without copying the private part of the SSH key outside the machine physically controlled by the key's owner, via careful SSH agent forwarding, which comes handy for scp or rsync between remote servers. Also X authentication forwarding is a great way to get remote X applications to display on system administrator's local desktop. This comes handy e.g. when debugging network issues (Wireshark).
When accessing the system locally, the system administrator either has the option to use SSH (via key, again) to set any password he or she likes, or, if the system is badly broken and this is not possible, to reboot the system, which probably doesn't hurt too much anymore (it's usually what needs to be done at such point). Then it's straightforward to set arbitrary root password by first appending init=/bin/bash to the kernel command line, and also changing the usual ro option in favour of rw, to be able to write to the root filesystem. This is needed for updating the password, so the passwd utility can write changes to disk. A sync and reboot later (this time with default kernel command line) and a fresh physical password to the current administrator's liking is set. No need to document it, all users who could log in remotely before can still log in via their SSH public keys now and any system administrator who genuinely needs to physically access the system without previous SSH session to update the password can repeat the trick with a root shell instead of the standard /sbin/init process above.
Comment
http://isc.sans.org/diary.html?storyid=3529
SSH scanners are getting smarter... so you can either ban them on the firewall after 10 failed attempts, or you can just make sure none of the attempts could ever succeed by not allowing password login to any of the accounts in the first place. The latter sounds much more secure to me and it's what I propose.
Post-It notes are at least hard to read unless you sit next to it. Out system administrator at a company I worked for back in 2000 came into the technical department and wrote the new root password (same password for multiple boxes) on the big whiteboard. For any rogue visitor you don't have to be a genius to guess that rof69Xzo is a password and not the pub we're going to on Friday.
That was really bad! Another pet peeve of mine is when people use notoriously unsecure passwords. Of course, they can still use a crap passphrase for their SSH key, but unless the attacker gets hold of their key file somehow, they can't even attempt a brute force. Plus it's psychologically more acceptable to require people to use distinct and secure passphrases for their personal SSH key, than for a dozen accounts whose credentials may change all the time.