SSSD, PAM, NSS und Kerberos-Domänen

In grossen IT-Umgebungen ist ein zentraler Verzeichnisdienst unverzichtbar, um Benutzeridentitäten und Berechtigungen konsistent und zentral verwalten zu können – besonders in heterogenen Netzen mit Windows-, Unix- und Linux-Systemen. Während Microsofts Active Directory (AD) auf Windows-Servern den dominierenden Standard darstellt, setzen viele Linux-Distributionen heute auf den System Security Services Daemon (SSSD) aus dem FreeIPA-Projekt, um sich komfortabel und sicher in AD-Domänen einzubinden. Darüber hinaus ermöglicht SSSD auch, Daten aus anderen LDAP-Infrastrukturen (etwa einem reinen OpenLDAP-Server) parallel zu beziehen.

Zentrale Verzeichnisdienste

Ein Verzeichnisdienst (Directory Service) bietet eine zentrale Anlaufstelle für:

  • Benutzerkonten (User Objects),

  • Gruppen und

  • Rollen sowie

  • Authentifizierungs- und Autorisierungsdaten.

In Windows-Netzwerken liefert Active Directory (AD) diese Funktionalität von Haus aus: Jeder Domain Controller ist gleichzeitig ein Kerberos-KDC (Key Distribution Center) und ein LDAP-Server. Unter Linux-Systemen liegen Benutzer- und Gruppeninformationen traditionell in lokalen Dateien wie /etc/passwd, /etc/group oder /etc/shadow. Ohne zentrale Synchronisation würde also jede Änderung an einem Benutzerkonto auf jedem System einzeln vorgenommen werden müssen – ein Alptraum in grossen Umgebungen. Unter Linux ermöglichen verschiedene Module wie NSS, PAM und SSD, Daten wie Benutzer, Gruppen, Passwortverifikation usw. aus zentralen Verzeichnisdiensten zu beziehen, indem man passende Bibliotheken installiert und nur wenige Konfigurationsdateien anpasst.

NSS

NSS (Name Service Switch) ist ein Framework, über das Anwendungen und das Betriebssystem Benutzernamen, Gruppen, Hostnamen, Netzwerkdienste und mehr abfragen können. Es ermöglicht beispielsweise auch, einem Nutzernamen wie „alice“ die zugehörige, im Unix-typischen Format vorliegende User-ID (UID) zuzuordnen. Standardmässig liest NSS seine Daten aus lokalen Dateien (z. B. /etc/passwd, /etc/group). In /etc/nsswitch.conf steht für jede „Map“ (z. B. passwd, group, hosts) eine Zeile, die angibt, welche Quelle(n) abgefragt werden sollen. Die Datei wird in der Regel nicht (mehr) manuell editiert, sondern durch Tools wie authselect angepasst.

/etc/nsswitch.conf einer AD-joined Maschine
passwd:     files sss systemd
group:      files sss systemd
netgroup:   sss files
automount:  sss files
services:   sss files
# sudoers:    files sss  # if FreeIPA joined

shadow:     files
hosts:      files dns myhostname

aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files

Durch Zeilen wie passwd: files sss systemd wird dem System mitgeteilt, zuerst in lokalen Dateien nach Benutzerinformationen zu suchen und, wenn dort keine Übereinstimmung gefunden wird, die Anfrage an SSSD (libnss_sss.so) weiterzuleiten. SSSD wiederum kennt je nach Konfiguration die Remote-Verzeichnisdienste (AD-Provider, LDAP-Provider).

Dabei werden Gruppen zusammengeführt, allerdings nur, wenn GroupName und GID übereinstimmen (siehe https://sourceware.org/glibc/wiki/Proposals/GroupMerging).

PAM

PAM (Pluggable Authentication Modules) kümmert sich um alles rund um die Authentifizierung: von der Passwortprüfung bis hin zur Entscheidung, ob eine Anmeldung überhaupt erlaubt wird. Anhand von Dateien in /etc/pam.d/ (z. B. /etc/pam.d/system-auth oder /etc/pam.d/sshd) legt man fest, in welcher Reihenfolge und mit welchen Modulen die Authentifizierung abläuft.

Beim Einsatz von SSSD muss PAM so konfiguriert sein, dass SSSD (mit pam_sss.so) die Passwörter gegen AD oder LDAP validieren darf. In modernen Distributionen erledigt ein Tool wie authselect (früher: authconfig) das Einbinden des SSSD-PAM-Moduls automatisch. Beispiel:

/etc/pam.d/system-auth
# Generated by authselect on Thu Jun  5 09:21:24 2025
# Do not modify this file manually.

# type      control                                      module-path module-arguments
auth        required                                     pam_env.so
auth        required                                     pam_faildelay.so delay=2000000
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        sufficient                                   pam_sss.so forward_pass
auth        required                                     pam_deny.so

account     required                                     pam_unix.so
account     sufficient                                   pam_localuser.so
account     sufficient                                   pam_usertype.so issystem
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required                                     pam_permit.so

password    requisite                                    pam_pwquality.so local_users_only
password    sufficient                                   pam_unix.so sha512 shadow nullok use_authtok
password    [success=1 default=ignore]                   pam_localuser.so
password    sufficient                                   pam_sss.so use_authtok
password    required                                     pam_deny.so

session     optional                                     pam_keyinit.so revoke
session     required                                     pam_limits.so
-session    optional                                     pam_systemd.so
session     optional                                     pam_oddjob_mkhomedir.so
session     [success=1 default=ignore]                   pam_succeed_if.so service in crond quiet use_uid
session     required                                     pam_unix.so
session     optional                                     pam_sss.so

Die erste Spalte „service“ wird durch den Dateinamen in /etc/pam.d/ festgelegt (und ist daher hier nicht aufgeführt). Die Beginnt „type“ mit einem Minus („-„), wird PAM das Logging unterbinden und einfach fortfahren, falls das Modul nicht installiert ist und daher nicht gefunden werden kann.

Bedeutung von required:

  • Ein Modul mit dem Flag required muss erfolgreich durchlaufen werden. Wenn das Modul erfolgreich ist, wird sofort mit dem nächsten Modul in derselben Stufe weitergemacht. Wenn das Modul fehlschlägt, wird zwar sofort zum nächsten Modul gesprungen, aber PAM merkt sich, dass ein Fehler aufgetreten ist.

  • Erst nach allen Modulen dieser Stufe entscheidet PAM: Wenn irgendein required-Modul fehlgeschlagen ist, geben alle Control-Flags zusammen am Ende ein Gesamt-Failure zurück – sprich: der gesamte Authentifizierungsversuch schlägt fehl. Auch wenn ein späteres Modul vielleicht Erfolg hat, bleibt der frühere Fehler erhalten, weil required keine Möglichkeit bietet, einen Fehler zu ignorieren.

Bedeutung von requisite:

  • Funktional sehr ähnlich zu required, mit dem Unterschied, dass es im Falle eines Fehlers sofort das gesamte PAM-Verfahren abbricht und ein Fehler zurückgegeben wird; es werden keine späteren Module in derselben Stufe mehr ausgeführt. Wird typischerweise bei Passwortrichtlinien verwendet.

Bedeutung von sufficient:

  • PAM prüft zunächst, ob bis zu diesem Zeitpunkt kein required- oder requisite-Modul vorher versagt hat. Wenn es keinen vorangegangenen Fehler gab, gibt PAM sofort Erfolg für die gesamte Stufe zurück und überspringt alle nachfolgenden Module in dieser Stufe. Gäbe es hingegen schon einen required-Fehler, wird das bereits als endgültiger Fehler im Hinterkopf behalten, und das sufficient-Modul wird quasi ignoriert (es ändert nichts am bereits vorhandenen Fehlerzustand).

  • Beispiel: Wenn kein vorangehender „harter“ Fehler geschehen ist und auth  sufficient  pam_unix.so nullok (lokale Unix-Passwortdatenbank) erfolgreich authentifiziert, dann sind wir fertig und überspringen andere Module.

Bedeutung von optional:

  • Ein optional-Modul kann nur dann eine Authentifizierung beeinflussen, wenn alle anderen Module in dieser Stufe entweder gar nicht angewendet wurden oder neutral sind (z. B. keine sufficient-Erfolge, keine required-Fehler). Wird meist zur Protokollierung, Key-Init oder Aufräumarbeiten, die nicht blockieren dürfen, verwendet.

  • Beispiel: session  optional  pam_oddjob_mkhomedir.so - selbst wenn das beim Erstellen eines Home-Verzeichnisses fehlschägt, soll das normale Login-Verhalten nicht direkt abgebrochen werden, solange keine anderen Module versagen.

Schaut man sich den ersten „auth“-Block an, ergibt sich also:

  • pam_env.so (required): Lädt Umgebungsvariablen. Ein Fehler wird intern notiert, aber es geht trotzdem weiter zum nächsten Modul.

  • pam_faildelay.so (required): Setzt eine Verzögerung bei Fehlschlägen. Auch hier wird ein möglicher Fehler nur notiert, und die Verarbeitung springt zum nächsten Modul.

  • pam_usertype.so isregular ([default=1 ignore=ignore success=ok]): Wenn der Nutzer ein regulärer User ist (Erfolg), wird das nächste Modul übersprungen; ansonsten wird das Ergebnis ignoriert und normal weitergemacht.

  • pam_localuser.so ([default=1 ignore=ignore success=ok]): Wenn der Nutzer lokal bekannt ist (Erfolg), wird das nächste Modul übersprungen; ansonsten ignoriert und weiter.

  • pam_unix.so nullok (sufficient): Verwendet die lokale /etc/shadow-Authentifizierung. Schlägt sie an dieser Stelle an und es gab bislang keine required-Fehler, endet die Auth-Stufe sofort. Bei Fehlschlag geht es weiter.

  • pam_usertype.so isregular ([default=1 ignore=ignore success=ok]): Gleiche Logik wie zuvor: Bei Erfolg wird das nächste Modul übersprungen, bei Fehler ignoriert und weiter.

  • pam_sss.so forward_pass (sufficient): Authentifiziert ggf. über SSSD/LDAP. Erfolg führt (sofern kein vorheriger „required“-Fehler) sofort zum positiven Stufenende; sonst wird weitergeprüft.

  • pam_deny.so (required): Wird nur erreicht, wenn keine der sufficient-Methoden erfolgreich war. Gibt immer einen Fehler zurück, markiert das Auth-Ergebnis als endgültig fehlgeschlagen und verhindert so den Login.

SSSD

SSSD (System Security Services Daemon) ist eine Client-Software aus dem Fedora/FreeIPA-Umfeld, das sich zum Ziel gesetzt hat, Linux-Systeme unkompliziert an verschiedene Identity-Backends (AD, LDAP, FreeIPA, IPA, 389-DS usw.) anzubinden. SSSD bündelt NSS und PAM in einem Daemon, der nicht nur Daten aus AD oder LDAP bezieht, sondern sie zusätzlich lokal cached, um Performance, Offline-Fähigkeit und Redundanz zu verbessern. Dabei übernimmt SSSD folgende Aufgaben:

  • NSS-Provider (libnss_sss.so): Sichert, dass getent passwd ..., getent group ... etc. Anfragen an das Remote-Verzeichnis (z.B. AD) richten, sobald lokal keine Daten gefunden werden.

  • PAM-Provider (pam_sss.so): Leitet Authentifizierungs- und Passwort-Änderungs-Anfragen an das Remote-KDC/LDAP weiter.

  • Caching: SSSD speichert Benutzer-, Gruppen- und Passwort-Hashes (nicht Klartext!) lokal im Cache, um Leistung und Offline-Fähigkeit zu verbessern. Melden sich Benutzer an, deren Daten bereits im Cache vorhanden sind, genügt der lokale Cache.

  • Offline-Login: Fällt die Netzwerkverbindung zum Verzeichnisdienst aus, können sich Benutzer, die sich mindestens einmal erfolgreich angemeldet haben, weiter anmelden — ohne spürbare Timeouts.

  • Multi-Domain und Multi-Provider: In einer einzigen SSSD-Konfiguration (Datei /etc/sssd/sssd.conf) lassen sich mehrere Domains/Erscheinungsbäume parallel ansprechen — z. B. ein AD-Domain, ein reines OpenLDAP-Schema und sogar ein IPA-Server. Jeder „Domain-Abschnitt“ in der sssd.conf kann unterschiedliche Provider (AD, LDAP, IPA, etc.) verwenden.

  • Sicherheit (TLS, SASL/GSSAPI): Zur Verschlüsselung und Authentifizierung beim LDAP-Binding beherrscht SSSD StartTLS, LDAPS und SASL/GSSAPI (Kerberos). Letzteres ist der Standard im AD-Universum, weil hier Kerberos-Tickets für Integrity und Confidentiality sorgen.

  • ID-Mapping: Der AD-Provider von SSSD kann Numerische IDs (UID/GID) automatisch aus der Windows-SID („Security Identifier“) errechnen, wenn keine POSIX-Attribute (uidNumber, gidNumber) im AD angelegt sind. Das senkt den administrativen Aufwand, vorausgesetzt, man will im AD keine POSIX-Attribute manuell pflegen.

SSSD 2.9+ (ab RHEL 9) beherrscht nun auch SAML/OIDC (weniger relevant für reine AD/LDAP-Setups, aber erwähnenswert).

Historisch: NIS

NIS (Network Information Service, früher „YP“ für Yellow Pages) ist ein altes Verfahren, um unter Unix-Systemen zentral Benutzer-, Gruppen- und Hostinformationen zu verwalten. Bei NIS betreibt man einen NIS-Server, der diese Daten als „Maps“ liefert, und bindet dann die Clients per ypbind und libnss_yp.so in den Namensdienst (NSS) ein. Authentifizierung läuft häufig über pam_unix oder pam_krb5, während die Account-Listen aus NIS gezogen werden. Schwachstellen wie unverschlüsselte Passwort-Übertragung, fehlende Rollenkonzepte und schlechte Skalierbarkeit haben dazu geführt, dass NIS und NIS+ (die proprietäre Fortsetzung von Sun) durch LDAP-basierte Directory-Services oder AD-Anbindungen mittels SSSD, aktiver Directory-Funktionalität und Kerberos abgelöst wurden. Für die zentrale Benutzer- und Gruppenverwaltung setzt man heute praktisch immer auf LDAP/SSSD-, FreeIPA- oder AD-basierte Lösungen.

Domänen-Join RHEL 9 > Windows AD

Client im Authorative DNS-Resolver des ADs anlegen.

Chrony installieren, konfigurieren und aktivieren. Der Pool oder die Peers sollten wenn möglich die gleichen sein, gegen die sich auch das AD synchronisiert - wenn möglich den AD-DC direkt verwenden.

dnf -y install chrony
systemctl enable --now chronyd
chronyc sources

Hostname des Clients korrekt konfigurieren:

hostnamectl set-hostname myclient.example.com

DNS des Clients korrekt konfigurieren. Aufpassen: Damit am Ende die richtigen DNS-Server abgefragt werden (siehe /etc/resolv.conf), unbedingt alle vorhandenen Netzwerkkarten und die Default-Routen prüfen.

nmcli con show
nmcli con show eth0 | grep dns

nmcli con mod eth0 ipv4.ignore-auto-dns yes
nmcli con mod eth0 ipv4.dns-search "example.com"
nmcli con mod eth0 ipv4.dns "192.0.2.10"

nmcli con down eth0 && nmcli con up eth0
nmcli con show eth0 | grep dns

/etc/resolv.conf kontrollieren.

Toolset installieren:

dnf -y install \
    sssd \
    sssd-ad \
    sssd-tools \
    realmd \
    adcli \
    oddjob \
    oddjob-mkhomedir \
    samba-common-tools \
    krb5-workstation

Mit realm lässt sich die Registrierung in Kerberos-Realms wie beispielsweise Active-Directory-Domains oder IPA-Domains sehr einfach verwalten. Zum Client passenden Realm und seine Fähigkeiten ermitteln:

# domain assigned through DHCP is used as a default
realm --verbose discover

# domain is specified
realm --verbose discover ad.example.com

Nachdem ein Realm ermittelt wurde, werden dessen Name, Typ und Fähigkeiten angezeigt.

Lokale Maschine für die Verwendung mit einem Realm konfigurieren (Domänen-Join):

realm --verbose join ad.example.com

Standardmässig verwendet realm das „Administrator“-Konto der Domäne, um den Join anzufordern. Soll ein anderer Benutzer verwendet werden, kann dieser mit --user angegeben werden. Eine andere Möglichkeit, einer Domäne beizutreten, ist die Verwendung eines Einmalpasswort-Tokens (OTP) über die Option --one-time-password.

Das Kommando kümmert sich unter anderem um die Anpassung folgender Dateien:

  • /etc/authselect/authselect.conf

  • /etc/authselect/dconf-db

  • /etc/authselect/dconf-locks

  • /etc/authselect/fingerprint-auth

  • /etc/authselect/nsswitch.conf

  • /etc/authselect/password-auth

  • /etc/authselect/postlogin

  • /etc/authselect/smartcard-auth

  • /etc/authselect/system-auth

  • /etc/krb5.conf

  • /etc/krb5.keytab

  • /etc/sssd/sssd.conf

Ausserdem sorgt es dafür, dass SSSD automatisch und bei jedem Neustart aktiv ist (siehe systemctl status sssd).

Bemerkung

In Konfigurationsdateien wie /etc/krb5.conf werden Kerberos Realm-Namen grundsätzlich UPPERCASE angegeben (EXAMPLE.COM), Domain-Namen dagegen lowercase (example.com). Server-Software, die einen Kerberos-Realm implementiert, ist beispielsweise ein Microsoft Active Directory oder ein FreeIPA.

Nach einem erfolgreichen Beitritt kann die lokale Maschine entfernte Benutzer- und Gruppennamen aus dem Realm auflösen. Für Kerberos-Realms wird ein Computerkonto und ein Host-Keytab erstellt. Ein erfolgreicher Join sieht wie folgt aus:

 * Resolving: _ldap._tcp.ad.example.com
 * Resolving: ad.example.com
 * Performing LDAP DSE lookup on: 192.168.121.22
 * Performing LDAP DSE lookup on: 192.0.2.10
 * Successfully discovered: example.com
Password for Administrator@EXAMPLE.COM:
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --domain example.com --domain-realm EXAMPLE.COM --domain-controller 192.168.121.22 --login-type user --login-ccache=/var/cache/realmd/realm-ad-kerberos-734P72
 * Using domain name: example.com
 * Calculated computer account name from fqdn: MYCLIENT
 * Using domain realm: example.com
 * Sending NetLogon ping to domain controller: 192.168.121.22
 * Received NetLogon info from: ad.example.com
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-0PZnPn/krb5.d/adcli-krb5-conf-Sq4G2p
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: EXAMPLE
 * Looked up domain SID: S-1-5-21-732525231-1764819708-261175322
 * Received NetLogon info from: ad.example.com
 * Using fully qualified name: myclient.example.com
 * Using domain name: example.com
 * Using computer account name: MYCLIENT
 * Using domain realm: example.com
 * Calculated computer account name from fqdn: MYCLIENT
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * A computer account for MYCLIENT$ does not exist
 * Found well known computer container at: CN=Computers,DC=example,DC=com
 * Calculated computer account: CN=MYCLIENT,CN=Computers,DC=example,DC=com
 * Encryption type [16] not permitted.
 * Encryption type [23] not permitted.
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created computer account: CN=MYCLIENT,CN=Computers,DC=example,DC=com
 * Trying to set computer password with Kerberos
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=MYCLIENT,CN=Computers,DC=example,DC=com
 * Checking RestrictedKrbHost/myclient.example.com
 *    Added RestrictedKrbHost/myclient.example.com
 * Checking RestrictedKrbHost/MYCLIENT
 *    Added RestrictedKrbHost/MYCLIENT
 * Checking host/myclient.example.com
 *    Added host/myclient.example.com
 * Checking host/MYCLIENT
 *    Added host/MYCLIENT
 * Discovered which keytab salt to use
 * Added the entries to the keytab: MYCLIENT$@EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/MYCLIENT@EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/myclient.example.com@EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/MYCLIENT@EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/myclient.example.com@EXAMPLE.COM: FILE:/etc/krb5.keytab
 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
Backup stored at /var/lib/authselect/backups/2025-06-05-09-21-24.v6X1NO
Profile "sssd" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group
- netgroup
- automount
- services

Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

- with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
  is present and oddjobd service is enabled and active
  - systemctl enable --now oddjobd.service

Created symlink /etc/systemd/system/multi-user.target.wants/oddjobd.service → /usr/lib/systemd/system/oddjobd.service.
 * Successfully enrolled machine in realm

PAM-Stack kontrollieren und schauen, welches PAM-Profil aktiv ist - dort sollte etwas wie sssd und with-mkhomedir stehen:

authselect current

Falls nicht:

authselect select sssd with-mkhomedir --force

Ein lokaler Login mit dem Domänen-Benutzer „alice“ sollte jetzt schon einwandfrei funktionieren:

getent passwd alice@example.com
groups alice@example.com

su - alice@example.com

Nach dem Join lässt sich beispielsweise auch direkt ein Kerberos-Ticket lösen:

KRB5_TRACE=/dev/stdout kinit administrator

Die Kerberos-Tickets aus dem Cache auflisten (AD-Benutzern wird beim Login automatisch ein Kerberos-Ticket ausgestellt):

klist

# List keys held in a keytab file
klist -k /etc/krb5.keytab

SSH

In /etc/sssd/sssd_config schauen, mit welchem Benutzernamen sich der Benutzer anmelden muss. Ist use_fully_qualified_names aktiv, muss der Benutzername alice@example.com verwendet werden.

Wie sieht die Login-Policy auf dem Client aus? Wer darf sich anmelden?

realm list

login-policy: allow-permitted-logins

Die Login-Policy lässt sich mittels realm permit --all (führt zu login-policy: allow-realm-logins) und realm deny --all (führt zu login-policy: deny-any-login) überschreiben.

Best Practise:

realm deny --all

Benutzer „alice“ explizit freigeben:

realm permit alice@example.com

Das führt zur Login-Policy login-policy: allow-permitted-logins.

Damit sich die Benutzer auch ohne SSH-Key anmelden können (der sonst bereits im Home-Verzeichnis liegen muss):

/etc/ssh/sshd_config
PasswordAuthentication yes

systemctl reload sshd

Anschliessend kann sich „alice“ anmelden (und verwendet dabei das Passwort aus dem AD):

ssh alice@example.com@myclient

Ein ssh-copy-id legt den SSH-Public-Key in /home/alice@example.com/.ssh/authorized_keys ab.

Fertig.

Soll aber der SSH-Key aus dem AD kommen, müssen SSSD und SSH passend konfiguriert werden. Zunächst den SSH-Key im AD beim Benutzer ablegen:

  • SnapIn „Active Directory Users and Computers“ > Menü „View > Advanced Features“ aktivieren

  • User öffnen und im Tab „attributeEditor“ im Feld „altSecuriyIdentities“ den SSH-Key ablegen

Dann:

/etc/sssd/sssd.conf
services = nss, pam, ssh

[domain/example.com]
ldap_user_extra_attrs = altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities

SSSD-Cache löschen und restarten:

systemctl stop sssd && rm -rf /var/lib/sss/{db,mc}/* && systemctl start sssd

Achtung

Startet SSSD nach dem Editieren der Konfigurationsdatei nicht mehr, gilt:

chown root:root /etc/sssd/sssd.conf
chmod 600 /etc/sssd/sssd.conf
systemctl restart sssd

SSH konfigurieren:

/etc/ssh/sshd_config
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Jetzt ist der Login möglich. Der Befehl sss_ssh_authorizedkeys alice@example.com zeigt den authorized_keys des Benutzers an.

Troubleshooting

tail -f /var/log/sssd/sssd*log /var/log/secure /var/log/audit/audit.log

Built on 2025-07-14