Support for LDAP/SSSD-based SSH Authentication in the PAM SSH Keys

Support for LDAP/SSSD-based SSH Authentication in the PAM SSH Keys

3 votes

avatar

Context:
Currently, the Devolutions Server PAM SSH Keys module expects to interact with local accounts on servers in order to insert or rotate SSH keys by updating the local authorized_keys file.
In our environment, SSH authentication is managed through LDAP/SSSD, where public SSH keys are dynamically provided from an LDAP attribute.
This means that no local authorized_keys file exists on the servers, as SSH keys are fetched directly from the LDAP directory during the login process.

Issue:
The PAM SSH Keys module cannot inject or rotate SSH keys because it relies on the presence of local accounts and local key files.
Additionally, the Scan Configuration function does not detect any accounts, since the module looks only for local accounts to manage.

Feature Request / Proposal:
We would like the PAM SSH Keys module to support environments using LDAP/SSSD for SSH authentication by enabling it to:

  • detect and recognize systems using LDAP/SSSD for SSH key management,
  • interact directly with the LDAP directory to manage SSH public keys stored in LDAP attributes,
  • allow rotation, addition, and removal of SSH keys in such centralized setups.

This enhancement would extend the PAM SSH Keys module’s capabilities to cover modern enterprise environments where SSH key management is centralized via LDAP. Thank you for considering this request

All Comments (5)

avatar

Hi Erdinger,

I agree this is a good idea, we'll add it to our list for a feature roadmap, stay tuned.

Best regards,

Luc Fauvel

avatar

I was actually logging in to make this same feature request! Just to add, people will commonly put the public key in the altSecurityIdentities attribute. I have also seen others create a custom sshPublicKey attribute and use that. Here is some non-paywalled documentation for how to set this up if it helps:

https://rayancrasta.hashnode.dev/linux-ssh-key-password-auth-for-users-stored-in-active-directory

Ideally, it would store the public key in the specified AD attribute and then store the private key with the AD credentials in DVLS.

avatar

Hi @csudderth

Great! Thank you for the info, we'll probably default to the altSecurityIdentities and allow users to configure a different attribute if they desire in this case.

Cheers,

Luc Fauvel

avatar

Hi,

Are you able to provide an estimated delivery time?

thx

avatar

Hi @Erdinger,

I can't currently provide an ETA, but as soon as I can I will be updating this thread. At most it will be in Q1 2026.

Cheers,

Luc Fauvel