Centralized SSH Authentication with SSSD and OpenLDAP

If you're managing multiple Ubuntu servers and want centralized authentication, SSSD with OpenLDAP over LDAPS is the professional standard. Users exist once in your LDAP directory and can SSH into any server you configure — no more managing local accounts on every machine. This guide assumes you already have an OpenLDAP server running and walks through connecting Ubuntu 22.04 clients to it securely over LDAPS.

How It Works

SSSD (System Security Services Daemon) sits between PAM, NSS, and your LDAP directory. When a user tries to SSH in, the system asks SSSD to resolve the identity. SSSD queries OpenLDAP over an encrypted LDAPS connection, retrieves the user's attributes and credentials, and hands the result back to PAM which either grants or denies access. SSSD also caches lookups locally so authentication still works during brief network outages.

Prerequisites

• OpenLDAP server running and accessible on port 636 (LDAPS)
• A CA certificate used to sign your LDAP server's TLS certificate
• A service account (bind DN) in LDAP with read access to your user tree
• Ubuntu 22.04 on the client server you want to configure
• Your LDAP base DN — e.g. dc=example,dc=com

Step 1: Install SSSD and Required Packages

sudo apt update && sudo apt install -y \
    sssd \
    sssd-ldap \
    ldap-utils \
    libnss-sss \
    libpam-sss \
    oddjob-mkhomedir

oddjob-mkhomedir automatically creates a home directory for LDAP users on their first login — without it, SSH will succeed but the user lands in / with no home directory.

Step 2: Install the CA Certificate

Copy your CA certificate to the client server and trust it system-wide. This is what allows SSSD to verify the LDAP server's TLS certificate.

sudo cp ca.crt /usr/local/share/ca-certificates/ldap-ca.crt
sudo update-ca-certificates

Verify it was added:

ls /etc/ssl/certs/ | grep ldap

Step 3: Test LDAPS Connectivity

Before configuring SSSD, confirm the client can actually reach the LDAP server over LDAPS. This saves a lot of debugging time.

ldapsearch -H ldaps://<LDAP_SERVER_IP> \
    -D "cn=binduser,dc=example,dc=com" \
    -w "<BIND_PASSWORD>" \
    -b "dc=example,dc=com" \
    "(objectClass=posixAccount)"

If this returns your LDAP users, connectivity is working. If you get a certificate error, your CA cert is not trusted correctly — go back to Step 2.

Step 4: Configure SSSD

Create the SSSD config file. This is the core of the setup:

sudo vim /etc/sssd/sssd.conf

[sssd]
services = nss, pam
domains = LDAP

[domain/LDAP]
id_provider = ldap
auth_provider = ldap

ldap_uri = ldaps://<LDAP_SERVER_IP>
ldap_search_base = dc=example,dc=com

ldap_default_bind_dn = cn=binduser,dc=example,dc=com
ldap_default_authtok = <BIND_PASSWORD>

ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ldap-ca.pem

ldap_user_object_class = posixAccount
ldap_group_object_class = posixGroup

cache_credentials = true
enumerate = false

A few important settings to understand:

• ldap_tls_reqcert = demand — requires a valid certificate from the LDAP server. Never set this to never in production as it disables certificate verification entirely.
• cache_credentials = true — caches the last successful login so users can still authenticate if the LDAP server is briefly unreachable.
• enumerate = false — disables listing all LDAP users via getent passwd. Recommended for large directories as enumeration can be slow and puts load on the LDAP server.

SSSD requires strict permissions on its config file or it will refuse to start:

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf

Step 5: Enable Automatic Home Directory Creation

Configure PAM to create home directories on first login:

sudo pam-auth-update --enable mkhomedir

Step 6: Start and Enable SSSD

sudo systemctl enable sssd
sudo systemctl start sssd
sudo systemctl status sssd

Look for active (running) in the status output. If SSSD fails to start, check the logs immediately:

sudo journalctl -u sssd -n 50

Step 7: Verify User Lookup

Test that SSSD can resolve an LDAP user without logging in:

id <ldap-username>

You should see the user's UID, GID, and group memberships pulled from LDAP. If this works, SSH login will work.

Step 8: Configure SSH to Allow LDAP Users

By default SSH is already wired through PAM, but confirm these settings are present in /etc/ssh/sshd_config:

UsePAM yes
PasswordAuthentication yes

If you want to restrict SSH access to a specific LDAP group rather than all LDAP users, add this to sshd_config:

AllowGroups <ldap-group-name> sudo

Include sudo or any other local groups you need to preserve access for — otherwise you could lock yourself out.

Restart SSH after any changes:

sudo systemctl restart sshd

Step 9: Test SSH Login

From another machine, SSH in as an LDAP user:

ssh <ldap-username>@<server-ip>

On first login the home directory will be created automatically. Subsequent logins will be fast due to SSSD's credential cache.

Troubleshooting

• SSSD won't start: Almost always a permissions issue on sssd.conf or a syntax error. Check journalctl -u sssd for the exact error.
• Certificate errors: Run ldapsearch manually as in Step 3 to isolate whether it's a connectivity issue or a cert trust issue. Make sure the CA cert path in sssd.conf matches what update-ca-certificates created.
• User not found: Check your ldap_search_base and ldap_user_object_class match your LDAP schema. Run sss_cache -E to clear the SSSD cache and force a fresh lookup.
• SSH works but no home directory: Confirm oddjob-mkhomedir is installed and pam-auth-update --enable mkhomedir was run.
• Locked out after a mistake: Always keep a second terminal session open as root when editing sshd_config or PAM settings. If you get locked out, use your cloud provider's console access to recover.

Scaling to Multiple Servers

The power of this setup is that Steps 1 through 8 are identical on every server you want to onboard. Once you have a working config, create a simple bash script that copies sssd.conf and the CA cert to a new server and runs the setup commands — onboarding a new server becomes a one-minute task.

Conclusion

SSSD with OpenLDAP over LDAPS gives you centralized, secure SSH authentication across your entire server fleet. Users are managed in one place, access can be revoked instantly by disabling a single LDAP account, and the credential cache means a brief LDAP outage won't take down SSH access across your infrastructure. For any environment managing more than two or three servers, this setup pays for itself immediately.