Ich habe einige Linux-Server so konfiguriert, dass sie sich mit Active Directory Kerberos unter Verwendung von sssd auf RHEL6 authentifizieren. Außerdem habe ich die GSSAPI-Authentifizierung aktiviert, in der Hoffnung auf passwortlose Anmeldungen.
Aber ich schaffe es nicht, Putty (0.63) dazu zu bringen, sich ohne Passwort zu authentifizieren.
GSSAPI funktioniert zwischen Linux-Systemen (OpenSSH-Client), die für die AD-Authentifizierung konfiguriert sind. Zum Aktivieren von GSSAPI werden die .ssh/config-Einstellungen verwendet.
Es funktioniert auch von Cygwin (OpenSSH-Client) aus, indem dieselben .ssh/config-Einstellungen verwendet und der Befehl kinit ausgeführt wird, um ein Ticket zu erhalten.
Außerdem funktionieren Samba-Freigaben auf allen Linux-Systemen, einschließlich Home-Verzeichnissen, vom Windows Explorer aus, ohne dass ein Passwort erforderlich ist (ich bin nicht sicher, ob GSSAPI hier eine Rolle spielt).
Welche Dinge kann ich versuchen, um das Problem zu beheben? Die meisten meiner Benutzer verwenden Putty. Außerdem bin ich kein Windows-Administrator und kann daher auf den Domänencontrollern nichts tun. Mein Konto hat nur die Berechtigung, Server zur AD-Domäne hinzuzufügen.
Ich habe die SSH-Paketprotokollierung von Putty aktiviert. Ich fand das hier ziemlich interessant, bin mir aber 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.
Antwort1
Auf Windows-Rechnern, die Teil einer Active Directory-Domäne sind, erhalten Benutzer ihr Kerberos-Ticket-Granting-Ticket, wenn sie sich bei Windows anmelden, und PuTTY kann dieses zur Authentifizierung verwenden, wenn die GSSAPI-Authentifizierung in der PuTTY-Konfiguration Verbindung|SSH|Auth|GSSAPI aktiviert ist (und andere Authentifizierungsmethoden, die es vor GSSAPI versucht, wie etwa der öffentliche Schlüssel über Pageant, in Verbindung|SSH|Auth nicht eingerichtet oder deaktiviert sind).
[Wenn Sie auch Ticket-Delegierung benötigen (z. B. um kerberisierte Dateisysteme nach dem Login auf dem Server zu mounten), stellen Sie sicher, dass GSSAPI-Delegierung auch in PuTTY aktiviert ist,UndDie Server, bei denen Sie sich anmelden, sind im Active Directory auf der Registerkarte Delegation als „Diesem Computer bei der Delegierung an alle Dienste vertrauen (nur Kerberos)", was standardmäßig nicht der Fall ist. Diese letztere Vertrauenseinstellung in AD wird seltsamerweise nur benötigt, damit die Delegierung von Windows-Clients wie PuTTY aus funktioniert; sie wird für Linux-"ssh -K"-Clients nicht benötigt.]
Auf selbstverwalteten (persönlichen) Windows-Rechnern, die nicht Teil einer Active Directory-Domäne sind, können Sie weiterhin Kerberos/GSSAPI-Authentifizierung (und Ticketdelegierung) über PuTTY verwenden, aber Sie müssen das Ticket selbst besorgen. Leider ist unter Windows 7 kein Äquivalent des kinit-Programms installiert (damit Sie manuell ein Ticket anfordern können), und PuTTY fordert Sie auch nicht zur Eingabe Ihres Kerberos-Passworts auf, wenn Sie kein Ticket haben. Daher müssen Sie dasMIT Kerberos für WindowsPaket, das sowohl die üblichen Befehlszeilentools kinit/klist/kdestroy als auch ein praktisches GUI-Tool „MIT Kerberos Ticket Manager“ enthält. Verwenden Sie diese, um Ihr Ticket abzurufen, 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 nach Ihrem Kerberos-Passwort gefragt, wenn PuTTY ein Ticket benötigt. Es ist daher eine gute Idee, ihn vom Startordner aus zu verknüpfen.
Aktualisieren:Ab Windows 10 Version 21H1 und Windows Server 2022 ist dieOpenSSH für Windows(Version 8.1 oder neuer) In Windows integrierte Clients und Server unterstützen jetzt auch GSSAPI-Authentifizierung und -Delegierung (d. h. ssh -K). Wenn Sie also nur das benötigen, müssen Sie ab 2021 PuTTY und MIT Kerberos nicht mehr installieren.
Antwort2
Überprüfen Sie zunächst, ob Ihre klist-Ausgabe auf der Windows-Box, auf der PuTTY läuft, ein gültiges TGT anzeigt. Stellen Sie dann in der Konfiguration für Ihre PuTTY-Sitzung sicher, dassGSSAPI-Authentifizierung versuchenist in aktiviert Connection - SSH - Auth - GSSAPI. Stellen Sie abschließend sicher, dass die Anmeldung mit Ihrem Benutzernamen in konfiguriert ist Connection - Data. Sie können den Benutzernamen entweder explizit angeben oder das Optionsfeld fürSystembenutzernamen verwenden.
Bisher war das alles, was ich tun musste, damit die passwortlose SSH-Anmeldung über Kerberos funktionierte.
Antwort3
Das Problem lag im Windows Kerberos-Setup. Ich glaube, unser Active Directory ist komisch eingerichtet, ich weiß es nicht wirklich, ich bin kein Windows-Administrator.
Aber ich habe das Problem behoben, indem ich Kerberos manuell mit ksetup in der Windows 7-CLI konfiguriert habe.
Nach einem Neustart meiner Remote-Workstation konnte ich mich nicht bei meinem PC anmelden. Das liegt daran, dass in der ursprünglichen Konfiguration der TLD-Teil meiner Realm-Domäne immer fehlte (Domäne\Benutzer). Nachdem ich ihn jedoch manuell konfiguriert hatte, musste ich meine Anmeldedomäne ändern, um den vollständigen Realm-Domänennamen (Domäne.TLD\Benutzer) anzuzeigen, und ich konnte mich bei meinem Windows-PC anmelden, obwohl die Authentifizierung jetzt länger zu dauern scheint.
Vor den Änderungen zeigte die Ausgabe von ksetup nur meinen Standardbereich an, und dieser war in Kleinbuchstaben.
Ich habe „nslookup -type=SRV _kerberos._tcp.domain.TLD“ verwendet, um alle KDC-Server für meinen Bereich abzurufen.
Ich habe keine Flags gesetzt.
Ich habe meinen Benutzernamen "ksetup /mapuser" zugeordnet.[email geschützt]Benutzer "
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 für die Windows-Administratoren hat, wie sie das Problem beheben können (ist es kaputt?), gebe ich sie weiter.