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
~/.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.
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
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:
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.
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
~/.ssh/authorized_keys. This ensures you won’t be locked
out in case the directory server goes South.