Wenn Ihr Linux-Server über SSSD Mitglied einer Active Directory (AD)-Domäne ist, können sich Benutzer nicht nur mit einem Passwort, sondern auch mit einem SSH-Schlüssel anmelden, sofern sich ihr öffentlicher Schlüssel im AD-Verzeichnis befindet. Auf diese Weise müssen die Schlüssel nicht für jeden Server einzeln in die „authorized_keys“-Dateien kopiert werden: Das Hinzufügen eines neuen Schlüssels oder das Widerrufen des Schlüssels eines ausscheidenden Mitarbeiters erfolgt an einer einzigen Stelle, nämlich im AD, und gilt für alle angeschlossenen Server.

Das Wesentliche der Lösung: Der Benutzer speichert den Schlüssel im Attribut „altSecurityIdentities“, das SSSD wird so konfiguriert, dass es dieses Attribut abfragt, und OpenSSH ruft die öffentlichen Schlüssel des Benutzers über den Befehl „sss_ssh_authorizedkeys“ ab.

Voraussetzungen

• Der Server wurde bereits in die Domäne eingebunden (beispielsweise mit dem Befehl „realm join“), und die AD-Benutzer können sich mit ihrem Passwort anmelden. Dies können Sie mit dem Befehl „id felhasznalo@example.com“ überprüfen.
• Der Benutzer verfügt über ein Schlüsselpaar, und sein öffentlicher Schlüssel (z. B. „ssh-ed25519 AAAA... bob@example.com“) liegt ihm vor. Einen Schlüssel können Sie mit dem Befehl „ssh-keygen -t ed25519“ erstellen, siehe: SSH-Schlüssel erstellen.
• Im AD verfügen Sie über Berechtigungen zum Bearbeiten von Benutzerattributen, auf dem Linux-Server hingegen über root-Rechte.

1. Active Directory

Aktivieren Sie in der Konsole „Active Directory-Benutzer und -Computer“ im Menü „Ansicht“ die Option „Erweiterte Funktionen“, damit die Registerkarte „Attribut-Editor“ angezeigt wird.

Suchen Sie den Benutzer, öffnen Sie dessen Eigenschaften und klicken Sie auf die Registerkarte „Attribute Editor“. Suchen Sie das Attribut „altSecurityIdentities“, öffnen Sie es zur Bearbeitung und fügen Sie den öffentlichen SSH-Schlüssel des Benutzers als einzelne Zeile ein. Das Attribut kann mehrere Werte speichern, sodass einem Benutzer mehrere Schlüssel zugewiesen werden können.

Das Gleiche in PowerShell: Set-ADUser bob -Add @{altSecurityIdentities="ssh-ed25519 AAAA... bob@example.com"}.

Das Attribut „altSecurityIdentities“ wird auch zur Zuordnung von AD-Zertifikaten und Kerberos-Identitäten verwendet. Sollte für den Benutzer bereits eine solche Zuordnung bestehen, überschreiben Sie diese bitte nicht, sondern fügen Sie lediglich einen neuen Wert hinzu.

2. SSSD

Fügen Sie im Abschnitt [sssd] der Datei /etc/sssd/sssd.conf in der Zeile „services“ den Wert „ssh“ hinzu:

services = nss, pam, ssh

Geben Sie im Bereich „Domain“ an, in welchem Attribut sich die Schlüssel befinden:

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

Leeren Sie den SSSD-Cache und starten Sie den Dienst neu:

systemctl stop sssd
rm -rf /var/lib/sss/db/* /var/lib/sss/mc/*
systemctl start sssd

3. OpenSSH

Fügen Sie die folgenden Zeilen in die Datei „/etc/ssh/sshd_config“ ein:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Der Befehl sollte gemäß der Dokumentation zu „sss_ssh_authorizedkeys“ vom Benutzer „nobody“ ohne Berechtigungen ausgeführt werden, nicht von „root“. Überprüfen Sie die Einstellung und starten Sie anschließend den SSH-Dienst neu (unter Debian und Ubuntu lautet der Name des Dienstes „ssh“):

sshd -t
systemctl restart sshd

Überprüfung und Fehlerbehebung

Der Befehl „sss_ssh_authorizedkeys“ gibt aus, welche öffentlichen Schlüssel SSSD für den Benutzer erkennt:

# sss_ssh_authorizedkeys bob
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... bob@example.com

Falls dieser Schlüssel angezeigt wird, die Anmeldung jedoch dennoch nicht gelingt:

• Der Befehl „sshd -T | grep -i authorizedkeyscommand“ zeigt die tatsächlich gültige Einstellung an. Die Dateien im Verzeichnis „/etc/ssh/sshd_config.d/“ können die Hauptkonfiguration überschreiben, da OpenSSH den zuerst gelesenen Wert verwendet.
• Im Kundenbereich zeigt der Befehl „ssh -v bob@szerver“ detailliert an, welche Schlüssel ausprobiert wurden.
• Der Grund für die Ablehnung ist im Serverprotokoll (journalctl -u sshd bzw. journalctl -u sssd) ersichtlich.

Sollte der Befehl keine Ausgabe liefern, überprüfen Sie bitte, ob die Berechtigungen für die Datei „sssd.conf“ auf 600 gesetzt sind, ob der Eigentümer „root“ ist (andernfalls startet SSSD gar nicht) und ob der Schlüssel genau in einer Zeile ohne Zeilenumbruch in das Attribut eingegeben wurde. Einen Überblick über die Funktionsweise von SSH und die Authentifizierung per Schlüssel finden Sie im Artikel „Linux Secure Shell (SSH)“.