Using LDAP for SSH key authentication

I stumbled across openssh-ldap-publickey while looking for a way to keep SSH public keys in LDAP instead of scattering them across individual authorized_keys files. For the kind of directory-centric environment I was running at the time, that idea made immediate sense.

One directory, one identity record, and one place to update a user’s SSH key.

Why this was appealing

If you already centralize identity in LDAP, local authorized_keys files start to feel like the odd thing out. They live on each host, drift over time, and are easy to forget about.

Putting the public key in LDAP means:

• the user record owns the key
• key rotation happens at the directory layer
• access can follow the same identity model as the rest of the environment

That was the appeal for me. It was less about novelty and more about keeping the auth story consistent.

The helper tooling

The project doing the actual work here was openssh-ldap-publickey. It provides a wrapper that OpenSSH can call to retrieve a user’s SSH public key from LDAP during login.

On Arch Linux at the time, the relevant dependency chain looked like this:

community/perl-net-ldap-server 0.43-3 [installed]
  Perl extension for LDAP server side protocol handling

aur/pear-net-ldap2 2.2.0-3 [installed] (1) (0.41)
  Object oriented interface for searching and manipulating LDAP-entries

aur/pear-net-ldap3 1.0.4-2 [installed] (1) (0.41)
  Object oriented interface for searching and manipulating LDAP-entries

I also created an Arch PKGBUILD at the time to make installation less annoying.

The LDAP schema side

Before anything else, the openssh-lpk-openldap.schema schema needs to be loaded into OpenLDAP. That adds the ldapPublicKey object class and the sshPublicKey attribute.

Once that exists, a normal People record can store one or more SSH public keys directly in LDAP.

The OpenSSH side

Inside sshd_config I had two possible directions:

1. keep the normal local key file and LDAP together
2. rely only on LDAP

That looked like this:

• use authorized_keys and LDAP together: AuthorizedKeysFile .ssh/authorized_keys
• use only LDAP: AuthorizedKeysFile /dev/null

Then add the helper command:

AuthorizedKeysCommand /usr/local/bin/openssh-ldap-publickey
AuthorizedKeysCommandUser nobody

That tells sshd to ask the helper for keys at login time.

What the user record looked like

A typical LDAP People record can now carry:

• objectClass: ldapPublicKey
• sshPublicKey: ssh-ed25519 ...

At that point the directory becomes the source of truth for SSH key auth.

Why this is still interesting even if I would not build it this way now

The reason I still think this post is worth keeping is that the design idea is solid. It is one more example of how far you can push a directory-backed identity model if you really want to centralize everything.

Would I build it this exact way now? Probably not.

Modern environments have better answers available:

• SSO-backed access platforms
• short-lived SSH certificates
• infrastructure automation pushing keys directly
• identity-aware access brokers

But if you are already running a legacy OpenLDAP environment and want SSH keys in the same place as the rest of your identity data, this still explains the shape of the solution.

Comments

Questions, corrections, and follow-ups live in GitHub Discussions.