SSSD: SSH Public Key aus Active Directory/LDAP auslesen

Hier wird erklärt, wie SSSD den sshPublicKey direkt aus der Active Directory lädt. Vorbei die Zeit, wo man noch PublicKeys in ~/.ssh/authorized_keys ablegen musste, *Yippie* :-)!

Du loggst dich auf einem Linux-Server bereits mit einem AD-Username + AD-Passwort via SSSD ein? Dann weiterlesen. Ansonsten bitte zurück zu #Teil 1: Linux Active Directory/LDAP SSH Login mit sssd und realmd.

Übersicht

Der grösste Haufen Arbeit ensteht beim Erstellen eines AD Attributes sshPublicKey. Danach ist die Umstellung der Linux-Konfiguration ein Klacks.

Die Umstellung von AD-Username + Passwort auf Private/Public SSH Key Authentication (und, optional, zusätzlich zum SSH Key trotzdem das AD-Passwort abfragen lassen) bedingt folgende Arbeitsschritte:

• Active Directory Schema um das Attribut sshPublicKey erweitern
  • (Für LDAP Schema Erweiterung bitte eine andere Anleitung ergoogeln, ich beschreibe hier nur den Fall ActiveDirectory)
• sshPublicKey bei einem ersten User in der AD hinterlegen.
• Falls das Attribut nicht sshPublicKey heisst, sondern zb "sshPublicKeyblablaXX" dann /etc/sssd/sssd.conf um eine Zeile ergänzen
• /etc/ssh/sshd_config anpassen

Fertig.

Optional:

• Den SSSD Cache 1x löschen und dem Problem, oder besser, dem Problem „Global Catalog“ Herr werden.
• Administrator-Hintertür: Erlaube extra definierten Accounts auf dem Linux-System (nicht aus dem AD) den Login immer noch ohne SSH-Key aus dem AD.

Active Directory Schema erweitern

Dann legen wir los. Wie gesagt, das Schema in der AD zu erweitern ist der grösste Teil und mir persönlich auch der ekligste. Aber es ist Windowstypisch Klick-Klick-Fertig.

Wichtig zu beachten: Ich Depp habe das AD Attribut falsch benannt, nämlich „sshPublicKeys“ mit dem Buchstaben „s“ am Ende anstatt „sshPublicKey“. Schlimm ist das nicht, jedoch empfehle ich gleich das Attribut nach dem SSSD Standard zu benennen: sshPublicKey (ohne S am Ende).

1. mmc.exe auf einem beschreibbaren AD Server öffnen als Domain Administrator > Datei >> Snap-In Hinzufügen >> Active Directory-Schema Snap-In hinzufügen
2. Rechtsklick auf Attribute > Hinzufügen. Es erscheint eine recht eklige Warnmeldung, dass diese Anpassung niemals wieder Rückgängig gemacht werden kann:
3. Neues Attribut erstellen:
   1. Allgemeiner Name: sshPublicKey
   2. LDAP-Anzeigename: sshPublicKey
   3. Eindeutige X500-OID: Mit einem VBS Script von Microsoft erstellen und jetzt eintragen.
   4. Beschreibung: ssh Public Key
   5. Syntax: IA5-Zeichenfolge
   6. Minimum/Maximum: Habe ich leer gelassen.
   7. [x] Mehrwertig ankreuzen ja, man möchte ja auch pro User mehrere PublicKeys hinterlegen dürfen.
4. Puh. Soweit so gut. Jetzt eine neue Schemaklasse erstellen: 
   1. Allgemeiner Name: ldapPublicKey
   2. LDAP-Anzeigename: ldapPublicKey
   3. Eindeutige X500-OID: Nochmal mit einem VBS Script eine neue eindeutige OID erstellen und jetzt eintragen.
   4. Übergeordnete Klasse: top
   5. Klassentyp: Zusätzlich (Auxiliary)
   6. Weiter
   7. Optional: Hinzufügen… sshPublicKey .. OK
   8. Fertig stellen
5. Rechtsklick auf das Attribut „user“ (Eigenschaften von user)
   1. Erweiterungsklassen: Hinzufügen… ldapPublicKey
6. Dienst neu starten: Active Directory-Domänendienste. (Man empfiehlt einen Restart dieses Dienstes bei Schema Erweiterungen, ob es tatsächlich notwendig war, kann ich nicht mehr beurteilen).

Bravo! Jetzt ist der Windows Active Directory Schema Teil erledigt. Die Active Directory ist jetzt bereit, den SSH Public Key als User Attribut zu speichern.

SSH Public Key in der Active Directory hinterlegen

Jetzt kann das User Attribut „sshPublicKey“ mit einem PublicKey befüllt werden. Los, tu es 🙂

1. Erweiterte Ansicht aktivieren
2. AD Benutzer in der AD-Struktur suchen & editieren (der Tab „Attribute“ wird nicht angezeigt, wenn man den Benutzer „nur“ über die Suchfunktion sucht & editiert. Fragt mich nicht warum o_O! Ich bin nach wie vor kein Windows AD Spezi)
3. AD Attribut sshPublicKey befüllen mit einem SSH Public Key:

/etc/sssd/sssd.conf anpassen

So. Jetzt der Fail von mir: Ich nannte das AD Attribut ja nicht „sshPublicKey“ sondern „sshPublicKeys“. Deshalb muss ich /etc/sssd.conf um eine Zeile erweitern. Falls das Attribut schon „sshPublicKey“ lautet (ohne S am Ende), ist das überhaupt nicht notwendig. SSSD sucht nach diesem Attribut jetzt schon automatisch.

/etc/sssd/sssd.conf

ldap_user_ssh_public_key = sshPublicKeys

Neustart mit systemctl restart sssd

sshPublicKey Abfrage auf der Command Line testen

Bevor wir den SSH Agenten umkonfigurieren um Keys aus der AD zu erzwingen, kann auf der Command Line die Abfrage getestet werden:

sss_ssh_authorizedkeys ADUserName

Die Antwort sollte der Public Key aus dem ActiveDirectory des jeweiligen Users ein, zum Beispiel:

Bravo! SSSD hat den sshPublicKey aus dem AD geholt

So und sollte das nicht funktionieren, kann mti sss_cache -E der lokale LDAP-Cache von SSSD gelöscht werden. Falls danach mit sss_ssh_authorizedkeys ADUSERNAME der PublicKey angezeigt wird, dürfte das Problem bei der „Global Config“ sein. SSSD zieht den AD Public Key nur dann immer korrekt, wenn das AD Attribut sshPublicKey mit [x] Attribut in den globalen Katalog replizieren konfiguriert ist:

/etc/ssh/sshd_config anpassen

Als krönenden Abschluss muss nur noch dem SSH beigebracht werden, jetzt eben auch SSH Keys abzufragen.

Warnung: Wer jetzt Dummheiten konfiguriert sperrt sich aus. Also Hirn eingeschaltet lassen und bitte vor jeder Änderung jetzt eine separate extra SSH-Verbindung zum Server öffnen und offen lassen um Fehlkonfigurationen in sshd_config rückgängig machen zu können.

/etc/ssh/sshd_config

Variante 1: sshPublicKey + AD Passwort beides wird abgefragt & notwendig für einen Login

#Get PublicKey via SSSD  from AD Atribute "sshPublicKey"
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root
#Require Public Key AND AD Password
AuthenticationMethods publickey,password

Variante 1a: sshPublicKey + AD Passwort beides benötigt, aber erlaube Login mit lokalem User+Passwort für zwei spezielle User

#Get PublicKey via SSSD  from AD Atribute "sshPublicKeys"
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root

#Require Both, KeyPair + AD Passwort as default
AuthenticationMethods publickey,password

#Allow explicit Password Login for localuser1,localuser2
Match User localuser1,localuser2
AuthenticationMethods password
PubkeyAuthentication no
PasswordAuthentication yes

Variante 2: sshPublicKey zwingend, Passwort Login deaktivieren

#Get PublicKey via SSSD  from AD Atribute "sshPublicKeys"
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root

#Require Pubkey Authentication, disable Password (!)
PubkeyAuthentication yes
PasswordAuthentication no

In jedem Fall muss danach der SSH Daemon neu gestartet werden: systemctl restart ssh

Deiner Fantasie über die verschiedenen Möglichkeiten sind keine Grenzen gesetzt.

Abschließende Gedanken

Warum ein AD-Passwort abfragen, wenn schon ein SSHKeyPair bereits erzwungen wurde? Meine Überlegung ist, dass jeder Mitarbeiter seinen SSH Key auch ohne Passwortschutz auf seinem Desktop herumliegen haben kann. Und damit ist das File per sé unsicher bzw. vor Diebstahl ungeschützt. Ich kann nicht erzwingen, dass der Private SSH Schlüssel  Passwortgeschützt sein muss. Daher – sozusagen als 2. Faktor – wird bei jedem Login das AD Passwort abgefragt. Oder anders herum betrachtet, der 2. Faktor ist der SSH Private Key.

Und wie schon Teil #1 erklärt, muss der Benutzer in einer definierten AD-Gruppe sein um überhaupt SSH machen zu dürfen.

PS: Im übrigen ist unter Windows FileZilla (SFTP) wieder einmal das dümmste Programm im Bunde, das schnallt nicht, dass ein SSH Key + AD Passwort verlangt wird. Jedoch WinSCP schnurrt auch in dieser Konstellation wie ein Kätzchen und ein SFTP Zugriff klappt damit problemlos. Schade, Mozilla… Mal wieder (Ich bevorzuge längst Evolution dem Thunderbird und Chromium dem Firefox……) (FileZilla wird nicht von Mozilla entwickelt, just ignore my last stupid sentence…)

PPS: SSSD kann noch deutlich mehr, z.B. Sudo-Rules aus dem AD lesen. Ja sogar Active Directory Gruppenrichtlinien sollen damit auf einen Linux Server anwendbar sein (noch nie ausprobiert). Die Manpage zeigt im Prinzip all die Möglichkeiten, die mit SSSD so möglich wären: https://linux.die.net/man/5/sssd.conf

Update 07/2021: Ansible Playbook

Hier findet sich mein Ansible Playbook, geschrieben für Ubuntu Server 18.04/20.04: https://seafile.schroeffu.ch/d/2d51829bf48249848775/

Ansible Playbook Inhalt grob umrissen:

• SSSD + Abhängigkeiten installieren
• Join AD durchführen
• AD Gruppe(n) berechtigen
• Sudo-Berechtigungen hinterlegen
• Home-Verzeichnis bei LDAP/AD Login münzen auf /home/DOMAIN.INTAR/Username
• Mind. 1 Fix damit Postfix aufhört Mailbomben zu versenden wenn man sudo ausführt, im Zusammenspielmit nss/sssd.