OpenSSH is the free version of the SSH suite of tools. Contrary to telnet or rlogin, ssh allows a user to safely connect to a remote system because all traffic (specially a user’s credentials) are encrypted. SSH(Secure Shell) also supports public-key authentication which allows you to connect to a remote server without sending your password over the Internet.

Public-key authentication uses two keys, a private key that only you have, and the public key, which is placed on the server you wish to gain access to, usually by yourself, adding your public key to the ~/.ssh/authorized_keys file. There is a nice introduction to public key authentication with SSH here, and another one here.

That is all very well when you only have a couple of machines you want to log in to, but what happens when you have dozens or more? You have to maintain your public keys on all those systems, ensuring they are kept up to date. God forbid that you loose your private key, or that it becomes compromised: you’d have to quickly change all the authorized_keys files on all machines! Enter LDAP.

Eric Auge has made a patch to OpenSSH which allows the SSH server (sshd) to read the public keys from an LDAP directory. I’ve tested it with OpenLDAP and the patch works like a charm.

After patching the source of portable OpenSSH (I used version 4.1p1) with Eric’s OpenSSH LDAP Public Key Patch corresponding to the OpenSSH version you downloaded, it is a matter of following the good instructions in README.lpk, adjusting your ./configure invocation according to the flavor of the day. After building, installing and restarting the patched OpenSSH, ensure you can still log on to your system.

Now add the LDAP options to your sshd_config file, adjusting the settings to suit your LDAP directory information tree, and restart sshd.

Add the schema file openldap-lpk.schema to your slapd.conf and restart your directory server. Add an object of class ldapPublicKey to your LDAP user entry, ensuring that you also have a posixAccount (sshd constructs the LDAP search filter by and-ing both object classes and the userid of the person logging on), and add one or more sshPublicKey attribute types.

My LDIF now looks like this:

dn: uid=jpm,ou=People,dc=fupps,dc=com
sn: Mens
cn: Jan-Piet Mens
gecos: JP Mens
uidNumber: 400
gidNumber: 400
uid: jpm
homeDirectory: /home/jpm
loginShell: /bin/bash
objectClass: inetOrgPerson
objectClass: person
objectClass: ldapPublicKey
objectClass: posixAccount
sshPublicKey: ssh-rsa CAr9x8... 
sshPublicKey: environment="LDP_USER=jpm" ssh-rsa AAAAB... 

I can now connect to all machines which have an sshd appropriately set up, without needing to distribute my public keys. (In case you are wondering about the environment option in the second public-key: that is for ldp, my LDAP distributed shell profile; have a look at that too!)

Isn’t that insecure? Well, not if you are careful. sshd will only allow you to connect if you already a a “local” user (i.e. if sshd can find your username on the local system). That doesn’t necessarily mean that you have an entry in /etc/passwd; it means that whatever underlying mechanism your systems use to determine whether your username is valid to log on to the machine, they have reported that you are a valid user. These mechanisms could be any combination of PAM (Pluggable Authentication Modules), NSS (Name Server Switch), etc.

So before letting the OpenSSH LDAP Public Key Patch fly on your publicly accessible machines, do ensure you are careful during deployment.

Oh, and before you ask: if the LDAP directory server is unavailable, it will obviously not be able to return public keys. In that case, sshd falls back to the other mechanisms you’ve configured (i.e. password) and/or public-key authentication from ~/.ssh/authorized_keys. This ensures you won’t be locked out in case the directory server goes South.