Locking ssh Access to Solaris Accounts
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.
Extra Pepperoni » Take Control of SSH, Draft Excerpt: Public Key Authentication said,
March 24, 2007 at 8:16 pm
[...] UNIX passwords present several problems for administrators. What legitimate users can remember and type (generally considered to be 8 letters and numbers) is a small enough range of possibilities for attackers to try all possibilities. “Account lockout” is a feature of some systems (including Mac OS X Server) to disable accounts after several failed guesses — which often identifies an attack. Unfortunately, this means legitimate users get blocked when their accounts are attacked, and locking legitimate users out of their own accounts is a successful attack (although not as serious as gaining illicit access). System administrators would often prefer to avoid this by not allowing password access at all. On Mac OS X, it’s difficult to set up an account without a password; it’s easier to create a long random password (12+ characters — Keychain Access can do this for you), and never write it down or give it to the account user, requiring public key authentication or some other high security authentication (such as smart cards) instead. On other systems, it’s easy to simply not set UNIX passwords for accounts (although there are complications). [...]