April 2006 – Daniel’s Blog.

From a post on Ian McDonald’s Blog:
Is it me or is it crazy the pace of point releases at the moment? Do we really need four kernels in three days?

Actually it’s just you, and perhaps a few others, who for some reason still don’t see any point in the 2.6.x.y release of kernels.

We haven’t had 4 new kernels in 3 days. We’ve had 4 small patchsets covering regressions and security flaws. In each case, the patches are less than 100 lines of code, and are considered “simple”. The fact that there are 4 of them represents the high level of effort the stable tree maintainer, and people submitting patches, is putting into the kernel.

I’d much rather have 4 security releases in 3 days, then be told to wait until the next stable kernel. Or have to track down and find the patch myself, only to discover that it doesn’t apply cleanly. I’m capable of doing these things, but there are plenty of people who aren’t, and the 2.6.x.y stable series provides a great infrastructure for the announcement and dissemination of timely security and regression patches.

At the end of the day, the chances are fairly good you’ll never need any of the patches in the stable series. What’s more, the 2.6.x.y patches all get rolled into 2.6.x+1 anyway, so you’ll get them all then. So feel free to ignore these “crazy” “kernel releases”

SSH public key management can be a real pain. Adding or removing a user to your system, and distributing the account details and ssh keys is time consuming. Revoking keys is the bigger issue. Has a user added an ssh public key to the root account? To other people’s accounts?

Enter SSH LPK.

The LDAP Public Key patch for ssh allows you to set up a Public Key Infrastructure (PKI) using LDAP. It consists of an ldap schema and a diff against openssh, which inserts an LDAP lookup for the public key into the authentication path. Combine this with libnss-ldap and pam_mkhomedir, and provisioning a new user on your network is as easy as creating an entry in LDAP and inserting their public key.

The patch also allows group checks. It will check for standard posix group membership in LDAP, and if the user is in the group specified, they are allowed in. There doesn’t seem to be any way to nest groups, but this could be fixed eventually by making it a query rather than an attribute to test.
In terms of security, this is fine. We’re exporting SSH public keys via LDAP, but that’s the whole point of a public key. Perhaps more concerning is exporting UIDs and other account information via LDAP. This could be tied down by creating a CA for infrastructure and requiring that connecting clients have a certificate signed by the CA.
One can enforce LPK public keys only by setting AuthorizedKeysFile to /dev/null. This prevents users from inserting their own ssh public key onto the filesystem and bypassing any revocations you might issue. It also means if the LDAP tree is unavailable, you will fall back to password auth. If you really want to be able to completely revoke a user’s permission to log in, it’s best to disable password authentication as well. Couple this with some pam configuration to only allow admin or root accounts, and perhaps OTP or S/KEY authentication to eliminate root password leakage, and this becomes a fairly tight system.

Resources:

OpenSSH LPK Patch