Kerberos für Dienste
Version vom 18. Oktober 2026, 16:46 Uhr von Thomas.will (Diskussion | Beiträge) (Neue Seite (Kurs Linux - Samba))
| Kurs | Lab | Rechner | Domäne |
|---|---|---|---|
| Linux - Samba | Linux - Samba Lab | fs (Server), lx (Client) | ad.it2XX.int |
Einfach erklärt
- Mit Kerberos meldet man sich einmal an und kommt danach ohne Passwort zu allen Diensten der Domäne: Single Sign-on.
- Jeder Dienst hat einen Namen in der Domäne, den Service Principal Name (SPN), z.B. host/fs.ad.it2XX.int für ssh oder HTTP/www.ad.it2XX.int für einen Webserver.
- Der Dienst braucht den passenden Schlüssel, um Tickets zu prüfen. Der liegt in einer Keytab, einer Datei auf dem Server.
- Auf dieser Seite: die Grundlagen und ssh. Weiter geht es mit Squid mit Kerberos und Apache mit Kerberos.
Das Wichtigste
- Ein SPN gehört zu genau einem Konto in der Domäne. Doppelte SPNs führen zu Fehlern, die schwer zu finden sind.
- Der Name im SPN muss der Name sein, den der Client benutzt. Wer per IP-Adresse zugreift, bekommt kein Kerberos.
- Die Keytab passt zur Schlüsselversion (kvno) im AD. Ändert sich das Passwort des Kontos, muss die Keytab neu erzeugt werden.
- Seit Samba 4.21 erledigt winbind das automatisch über sync machine password to keytab.
Wie ein Dienst mit Kerberos funktioniert
- max meldet sich an und hat ein TGT: klist
- Er ruft ssh fs.ad.it2XX.int auf. Der Client fragt den DC nach einem Ticket für host/fs.ad.it2XX.int.
- Der DC sucht das Konto mit diesem SPN, hier das Maschinenkonto FS$, und verschlüsselt das Ticket mit dessen Schlüssel.
- fs entschlüsselt das Ticket mit dem Schlüssel aus /etc/krb5.keytab und weiß: Das ist max.
Werkzeuge
| Befehl | Wirkung |
|---|---|
| klist | eigene Tickets |
| klist -k /etc/krb5.keytab | Einträge einer Keytab, mit kvno |
| klist -ke | dasselbe mit Verschlüsselungsarten |
| kvno host/fs.ad.it201.int | ein Service-Ticket holen und die kvno anzeigen |
| net ads setspn list | SPNs des eigenen Maschinenkontos |
| net ads setspn add HTTP/www.ad.it201.int -U administrator | SPN beim eigenen Konto eintragen |
| net ads keytab create | Keytabs nach sync machine password to keytab neu schreiben |
| setspn -L fs | SPNs eines Kontos, auf Windows |
| setspn -X | doppelte SPNs in der Domäne suchen, auf Windows |
ssh mit Kerberos
Server fs
- fs ist der Domäne beigetreten, siehe Samba Mitgliedsserver. Die Keytab mit host/fs entsteht über diese Zeile in der smb.conf:
sync machine password to keytab = /etc/krb5.keytab:spn_prefixes=host:account_name:sync_spns:sync_kvno:machine_password
net ads keytab create klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ------------------------------------------ 2 host/fs@AD.IT201.INT 2 host/fs.ad.it201.int@AD.IT201.INT 2 FS$@AD.IT201.INT
- /etc/ssh/sshd_config.d/kerberos.conf
GSSAPIAuthentication yes GSSAPICleanupCredentials yes
- systemctl restart ssh
Client lx
- ~/.ssh/config
Host *.ad.it201.int
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
kinit max ssh fs.ad.it201.int klist
- Nach der Anmeldung zeigt klist auf lx zusätzlich ein Ticket für host/fs.ad.it201.int@AD.IT201.INT.
- GSSAPIDelegateCredentials yes gibt das TGT an fs weiter. Dann geht von fs aus ssh zum nächsten Rechner ohne Passwort. Nur auf vertrauenswürdigen Servern.
- Von Windows aus kann PuTTY Kerberos: Verbindung, SSH, Auth, GSSAPI.
Fehler finden
ssh -v fs.ad.it201.int 2>&1 | grep -i gssapi
- Auf dem Server: journalctl -u ssh -e
Stolperfallen
- ssh 10.2XX.1.31 statt ssh fs.ad.it2XX.int: Es gibt keinen SPN host/10.2XX.1.31. ssh fragt nach dem Passwort.
- Kurzer Name ohne Domäne: ssh fs geht nur, wenn der Client den Namen richtig zum FQDN ergänzt. Im Zweifel den vollen Namen benutzen.
- Keytab veraltet: Nach einem neuen Beitritt stimmt die kvno nicht mehr. klist -k mit kvno vergleichen, net ads keytab create.
- Rückwärtsauflösung: Manche Clients bilden den SPN aus dem PTR-Eintrag. Fehlt er oder ist er falsch, passt der SPN nicht. Rückwärtszonen pflegen.
- Zeit: mehr als 5 Minuten Abweichung, und nichts geht.
Übungen
Grundübungen
- Schauen Sie sich auf fs die Keytab an. Welche Principals stehen darin, welche kvno haben sie?
- Schalten Sie auf fs GSSAPIAuthentication ein und melden Sie sich von lx als max ohne Passwort an.
- Welches neue Ticket hat max danach auf lx? Erklären Sie seinen Namen.
- Holen Sie mit kvno ein Ticket für host/fs.ad.it2XX.int und vergleichen Sie die kvno mit der Keytab.
- Lassen Sie sich auf win-dc mit setspn -L fs die SPNs anzeigen.
Vertiefung
- Melden Sie sich mit GSSAPIDelegateCredentials yes an fs an und von dort weiter an lx. Was zeigt klist auf fs?
- Lösen Sie auf fs einen Passwortwechsel des Maschinenkontos aus: net ads changetrustpw. Was passiert mit der kvno in der Keytab?
- Melden Sie sich von win11 mit PuTTY per Kerberos an fs an.
Fehlersuche
- 1. ssh fragt trotz Ticket nach dem Passwort
Möglich sind: Zugriff per IP statt Name, GSSAPIAuthentication auf Client oder Server aus, oder kein host/-Eintrag in der Keytab. ssh -v zeigt, welche Methode versucht wurde.
- 2. ssh -v meldet
- Server not found in Kerberos database
Den SPN gibt es im AD nicht. Meist wird ein Name benutzt, der nicht zum Rechnerkonto passt, z.B. ein DNS-Alias. Entweder den echten Namen nehmen oder den Alias als SPN eintragen: net ads setspn add host/alias.ad.it2XX.int
- 3. Im Journal von ssh steht
- Wrong principal in request oder Key version number for principal in key table is incorrect
Die Keytab ist veraltet, z.B. nach einem neuen Beitritt. net ads keytab create und klist -k prüfen.
Vertiefung
- Kerberos SSH Login · Kerberos ssh samba · Kerberos Befehle · Kerberos-Befehle - Service · Kerberos Sicherheitsaspekte