SSS_SSH_AUTHORIZEDKE(1)

📦
version 2.13.1 · 21 versions
, in fedora 43, fedora 44

✨ SSS_SSH_AUTHORIZEDKE(1) ✨

okay bestie, so this is a page from the SSSD manual pages (yep, the manual is literally named SSS_SSH_AUTHORIZEDKE(1), cute caps energy, we love her) 🫶 and she's all about sss_ssh_authorizedkeys. grab a strawberry, let's go 🍓

💖 NAME 💖

sss_ssh_authorizedkeys — get OpenSSH authorized keys ✨

🌸 SYNOPSIS 🌸

sss_ssh_authorizedkeys [options] USER

🦋 DESCRIPTION 🦋

so basically, sss_ssh_authorizedkeys goes and grabs the SSH public keys for the user USER and prints them out in OpenSSH authorized_keys format. like, if you wanna know the exact shape of that format, go peek at the “AUTHORIZED_KEYS FILE FORMAT” section of sshd(8), she explains it way better than I can 💅

and here's the slay part: sshd(8) can be configured to use sss_ssh_authorizedkeys for public key user authentication — but only if it was compiled with support for the “AuthorizedKeysCommand” option. wanna know more? sshd_config(5) has you covered, no cap 👑

so if “AuthorizedKeysCommand” is supported, you can set sshd(8) up to use it by dropping these directives into sshd_config(5):

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

🎀 KEYS FROM CERTIFICATES 🎀

bestie this is the main character section, pay attention 💖

on top of the public SSH keys for user USER, sss_ssh_authorizedkeys can also return public SSH keys that are derived from the public key of a X.509 certificate. yes, really. she's versatile like that 🧚

to turn this on, the “ssh_use_certificate_keys” option has to be set to true (which is the default, so lowkey it's already on for you) in the [ssh] section of sssd.conf. and then: if the user entry contains certificates (see “ldap_user_certificate” in sssd-ldap(5) for the deets) or there's a certificate sitting in an override entry for the user (see sss_override(8) or sssd-ipa(5) for the deets) and that certificate is valid, SSSD will extract the public key from the certificate and convert it into the format that sshd expects. it's giving ✨glow-up✨

besides “ssh_use_certificate_keys”, these options:

  • ca_db
  • p11_child_timeout
  • certificate_verification

can be used to control how the certificates get validated (see sssd.conf(5) for the deets, she's got all of it 📖).

and ngl, the validation is literally the whole benefit of using X.509 certificates instead of SSH keys directly, because like… it gives you better control of the lifetime of the keys. picture this: your ssh client is set up to use the private keys from a Smartcard with the help of a PKCS#11 shared library (see ssh(1) for the deets), and it might be irritating (real) that authentication still works even if the related X.509 certificate on the Smartcard is already expired — because neither ssh nor sshd will look at the certificate at all. not even a glance. 💀

and it has to be noted (important!!) that the derived public SSH key can still be added to the authorized_keys file of the user to bypass the certificate validation, if the sshd configuration permits this. so like, that escape hatch exists. iykyk 🙈

💅 OPTIONS 💅

  • -d, --domain DOMAIN — search for user public keys in SSSD domain DOMAIN. 🔍
  • -?, --help — display the help message and exit. bye bestie, have a nice day ✨

🌈 EXIT STATUS 🌈

if it goes well, an exit value of 0 is returned. if not, 1 is returned. periodt. 💯

⭐ SEE ALSO ⭐

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)

👑 AUTHORS 👑

The SSSD upstream - https://github.com/SSSD/sssd/

and that's the whole page bestie, we ate and left no crumbs 🍓💜 SSSD brought this to you on 07/08/2026, mwah, go be iconic 💅✨

📦 where this page comes from