Ssh – Central authentication and public key store

If you're using PAM for your authentication stack, you can use pam_krb5 to provide kerberos authentication for your services. Kerberos was designed out-of-the-box to deal with hostile environments, handles authentication-by-proxy, and is already a part of the AD spec. Why struggle with LDAP when you can get Kerberos to do the heavy lifting for you, and get on with life? Yeah, you'll have to do some reading, and yeah, it'll take a bit of time, but I've used Kerb-to-AD authentication for years and have found it to be the easiest, quickest way to get SSO working out of the box when you have Active Directory as the authentication backend.

The main thing you'll run into is that Microsoft decided to be very specific about the default encryption types (they basically made their own), so you'll need to set up your Kerberos clients to have the correct matching encryption types, or the AD servers will continue to reject it. This is thankfully an easy procedure and shouldn't require more than a few edits to krb5.conf.

And now, some links for you to consider...

Microsoft's View of Kerberos

• Kerberos Explained

Meshing Kerberos and Active Directory

• Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability

ssh and Kerberos authentication via PAM

• A snippet from O'Reilly's book on SSH
• IBM has a few words on OpenSSH and Kerberos

Apache and Kerberos

• mod_auth_kerb via SourceForge
• Providing Active Directory authentication via Kerberos protocol in Apache

ProFTP and Kerberos

• ProFTPD module mod_gss also via SourceForge

RFCs of Microsoft's Activities with Kerberos (which you really don't want to read about):

• RFC3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols
• RFC4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows

The passphrase that can be set on the private key is unrelated to the SSH server or the connection to it. Setting a passphrase to the private key is merely a security measure the key owner may take in order to prevent access to his remote shell by a third party in case the private key gets stolen.

Unfortunately, you cannot force users to secure their private keys with passphrases. Sometimes, unprotected private keys are required in order to automate access to the remote SSH server. One good habit I highly recommend for such cases is to advise the users to hash the known_hosts file (stored at ~/.ssh/known_hosts), which keeps information about the remote hosts the user connects to, using the following command:

ssh-keygen -H -f ~/.ssh/known_hosts

This way, even if a third party gained access to an unprotected private key, it would be extremely difficult to find out for which remote hosts this key is valid. Of course, clearing the shell history is mandatory for this technique to be of any value.

Also, another thing you should always bear in mind, is not allow root to login remotely by adding the following in your SSH server's configuration (sshd_config):

PermitRootLogin no

On the other hand, if you want to prevent users from using keys to authenticate, but instead use passwords, you should add the following to your sshd_config:

PasswordAuthentication yes
PubkeyAuthentication no