Putty Kerberos / GSSAPI-Authentifizierung

9

Ich habe einige Linux-Server für die Authentifizierung bei Active Directory-Kerberos mithilfe von sssd unter RHEL6 konfiguriert. Ich habe auch die GSSAPI-Authentifizierung in der Hoffnung auf kennwortlose Anmeldungen aktiviert.

Aber ich kann Putty (0.63) scheinbar nicht dazu bringen, sich ohne Passwort zu authentifizieren.

GSSAPI funktioniert zwischen Linux-Systemen (openSSH-Client), die für die AD-Authentifizierung konfiguriert sind, und verwendet die Einstellungen für .ssh / config, um GSSAPI zu aktivieren.

Es funktioniert auch von Cygwin (openSSH-Client) aus, wobei dieselben .ssh / config-Einstellungen verwendet werden und der Befehl kinit ausgeführt wird, um ein Ticket zu erhalten.

Auch Samba-Freigaben auf allen Linux-Systemen, einschließlich Home-Verzeichnissen, funktionieren über Windows Explorer, ohne dass ein Kennwort erforderlich ist (ich bin nicht sicher, ob GSSAPI dort ins Spiel kommt).

Welche Art von Dingen kann ich versuchen, dies zu beheben? Die meisten meiner Benutzer verwenden Putty. Außerdem bin ich kein Windows-Administrator, daher kann ich auf den Domänencontrollern nichts tun. Mein Konto verfügt nur über Berechtigungen zum Hinzufügen von Servern zur AD-Domäne.


Ich habe die Kitt-SSH-Paketprotokollierung aktiviert. Ich fand diese Art von interessant, ich bin mir noch nicht sicher, was ich mit diesen Informationen anfangen soll:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
xdaxdb
quelle
1
Wenn Sie das Debuggen in der Nacht des SSH-Daemons aktivieren, werden nützliche Informationen angezeigt. Sie können jederzeit eine zweite Instanz an einem anderen Port zum Testen starten.
Paul Haldane

Antworten:

7

Auf Windows-Computern, die Teil einer Active Directory-Domäne sind, erhalten Benutzer ihr Kerberos-Ticketgewährungsticket, wenn sie sich bei Windows anmelden. PuTTY kann dieses zur Authentifizierung verwenden, wenn die GSSAPI-Authentifizierung in PuTTY Configuration Connection | SSH | Auth | GSSAPI aktiviert ist (und andere Authentifizierungsmethoden, die vor GSSAPI versucht werden, wie z. B. der öffentliche Schlüssel über Pageant, werden in Connection | SSH | Auth nicht eingerichtet oder deaktiviert).

[Wenn Sie auch eine Ticketdelegierung benötigen (z. B. um kerberisierte Dateisysteme nach der Anmeldung auf dem Server bereitzustellen), stellen Sie sicher, dass die GSSAPI-Delegierung auch in PuTTY aktiviert ist und die Server, bei denen Sie sich anmelden, in Active Directory auf der Registerkarte Delegierung als markiert sind " Vertrauen Sie diesem Computer für die Delegierung an einen Dienst (nur Kerberos) ", was nicht standardmäßig der Fall ist. Diese letztere Vertrauensstellung in AD wird seltsamerweise nur benötigt, damit die Delegierung von Windows-Clients wie PuTTY aus funktioniert. es wird nicht für Linux "ssh -K" Clients benötigt.]

Auf selbstverwalteten (persönlichen) Windows-Computern, die nicht Teil einer Active Directory-Domäne sind, können Sie die Kerberos / GSSAPI-Authentifizierung (und die Ticketdelegierung) weiterhin über PuTTY verwenden, müssen das Ticket jedoch selbst erwerben. Leider wird Windows 7 nicht mit einem Äquivalent des Kinit-Programms installiert (damit Sie manuell ein Ticket anfordern können), und PuTTY fordert Sie auch dann nicht zur Eingabe Ihres Kerberos-Kennworts auf, wenn Sie kein Ticket haben. Daher müssen Sie MIT Kerberos für Windows installierenPaket, das sowohl die üblichen Kinit / Klist / Kdestroy-Befehlszeilentools als auch ein ordentliches GUI-Tool "MIT Kerberos Ticket Manager" enthält. Verwenden Sie diese, um Ihr Ticket zu erhalten, und dann verwendet PuTTY automatisch die MIT GSSAPI-Bibliothek anstelle der Microsoft SSPI-Bibliothek, und alles sollte funktionieren. Wenn der "MIT Kerberos Ticket Manager" ausgeführt wird, werden Sie automatisch zur Eingabe Ihres Kerberos-Kennworts aufgefordert, wenn PuTTY ein Ticket benötigt. Es empfiehlt sich daher, es über den Startordner zu verknüpfen.

Markus Kuhn
quelle
1
Ich habe seitdem erfahren, dass Windows tatsächlich eine Art Äquivalent zum kinitBefehl von MIT Kerberos hat cmdkey.
Markus Kuhn
1
Wenn Sie eine der Personen sind, die verstehen, dass Active Directory eigentlich nur Microsoft LDAPv3 ist, stellen Sie sicher, dass der LDAP-Eintrag des Dienstprinzips, an den Sie ein Kerberos-Ticket delegieren möchten, in seinem userAccountControl the enthalten ist Bit TRUSTED_FOR_DELEGATION = 0x80000 = 524288 gesetzt.
Markus Kuhn
Zu Ihrer Information für alle, die in Betracht ziehen, "Diesem Computer für die Delegierung an einen Dienst vertrauen (nur Kerberos)" zu konfigurieren, z. B. eine nicht eingeschränkte Kerberos-Delegierung. Dies hat schwerwiegende Auswirkungen auf die Sicherheit, die Sie berücksichtigen sollten. Ich würde empfehlen, zuerst adsecurity.org/?p=1667 zu lesen .
Brad
3

Überprüfen Sie zunächst, ob Ihre Klist-Ausgabe auf der Windows-Box, auf der PuTTY ausgeführt wird, eine gültige TGT anzeigt. Stellen Sie dann in der Konfiguration für Ihre PuTTY-Sitzung sicher, dass die Option GSSAPI-Authentifizierung versuchen in aktiviert ist Connection - SSH - Auth - GSSAPI. Stellen Sie schließlich sicher, dass es so konfiguriert ist, dass Sie sich automatisch mit Ihrem Benutzernamen anmelden Connection - Data. Sie können entweder den Benutzernamen explizit angeben oder das Optionsfeld für Systembenutzernamen verwenden aktivieren .

In der Vergangenheit war das alles, was ich tun musste, damit die kennwortlose SSH-Anmeldung über Kerberos funktioniert.

Ryan Bolger
quelle
1
klist tgt sieht aus wie es für mich sinnvoll ist. sagt, es ist auch weiterleitbar. klist zeigt 5 Schlüssel für Dinge wie Exchange. Ich habe auch ein Ticket für den Linux-Server, auf den ich ssh möchte. Ich habe die Kittkonfiguration 100 Mal durchgesehen. Alle Online-Dokumente / Anleitungen sagen so ziemlich dasselbe, daher bin ich zuversichtlich, dass der Teil richtig eingerichtet ist.
xdaxdb
3

Das Problem lag im Windows Kerberos-Setup. Ich denke, unser Active Directory ist funky eingerichtet, ich weiß nicht wirklich, dass ich kein Windows-Administrator bin.

Ich habe das Problem jedoch behoben, indem ich Kerberos mithilfe von ksetup in der Windows 7-CLI manuell konfiguriert habe.

Nach einem Neustart meiner Remote-Workstation konnte ich mich nicht bei meinem PC anmelden. Dies liegt daran, dass in der ursprünglichen Konfiguration der TLD-Teil meiner Realm-Domäne immer fehlte (Domäne \ Benutzer), aber nachdem ich ihn manuell konfiguriert hatte, musste ich meine Anmeldedomäne ändern, um den vollständigen Realm-Domänennamen (domain.TLD \ Benutzer) und wiederzugeben Ich konnte mich bei meinem Windows-PC anmelden, obwohl die Authentifizierung jetzt anscheinend länger dauert.

Vor den Änderungen zeigte die Ausgabe von ksetup nur meinen Standardbereich und war in Kleinbuchstaben.

Ich habe "nslookup -type = SRV _kerberos._tcp.domain.TLD" verwendet, um alle kdc-Server für meinen Realm abzurufen.

Ich habe keine Flags gesetzt.

Ich habe meinen Benutzernamen "ksetup / mapuser [email protected] user" zugeordnet.

Von mir verwendete Ressourcen: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Wenn jemand Vorschläge hat, die ich den Windows-Administratoren geben kann, wie sie das beheben können (ist es kaputt?), Werde ich sie weitergeben.

xdaxdb
quelle