Today's tip is brought to you by the letters SUNW.

As we migrate from encrypted passwords to public keys for ssh access, one of the problems we have is how to make sure an account is disabled across many machines (we're not up to authenticating against a central LDAP or AD directory yet).

Given the variations in home directory location, eccentricities of escaping commands over ssh connections (dsh makes it even worse), difficulty in recognizing public key strings, and level of paranoia appropriate when closing an account, it's very difficult to be certain a person's access has been entirely cut off (especially if they had legitimate access to elevate privilege).

There are simply a lot of files in a lot of different places to check and edit, and no way to know you've found them all without spending some quality time with each host, when we want something quick and complete.

On Solaris (but not on RHEL4), if the password field in /etc/shadow is set to *LK*, the account is not accessible via OpenSSH and public keys, although it is via local su. Just to keep things interesting, OpenSSH prompts for a password, even though it knows the account is locked! If the password field is '*', '!', or a real encrypted password prefixed with '!' (a standard way of temporarily disabling a password), ssh access is permitted with a valid public key.

That doesn't guarantee the user didn't bury their public key in someone else's authorized_keys file, but doing this to other individuals would be clearly malicious and actionable, and doing it to the system accounts is more reasonable to check; better is to have a policy of simply replacing their authorized_keys files from known-good copies whenever there's a change.

Update 2007/05/11: In Mac OS X Server, you can uncheck "access account" in Workgroup Manager, but still log in with a public key.

Under OpenSSH on Solaris, authorized_keys (and the .ssh directory) can be owned by root, handy for centralized account management, but under RHEL4 they must be owned by the user.