Authentification Kerberos/GSSAPI avec PuTTY

J’ai configuré quelques serveurs Linux pour s’authentifier avec Active Directory Kerberos en utilisant sssd sur RHEL6. J’ai également activé l’authentification GSSAPI dans l’espoir d’avoir des connexions sans mot de passe.

Mais je n’arrive pas à faire en sorte que PuTTY (0.63) s’authentifie sans mot de passe.

GSSAPI fonctionne entre les systèmes Linux (client openSSH) qui sont configurés pour l’authentification AD, en utilisant les paramètres .ssh/config pour activer GSSAPI.

Cela fonctionne aussi depuis Cygwin (client openSSH), en utilisant les mêmes paramètres .ssh/config ainsi que la commande kinit pour obtenir un ticket.

De plus, les partages Samba sur tous les systèmes Linux, y compris les répertoires personnels, fonctionnent depuis l’Explorateur Windows sans nécessiter de mot de passe (je ne suis pas sûr que GSSAPI entre en jeu ici).

Que puis-je essayer pour résoudre ce problème ? La plupart de mes utilisateurs utilisent PuTTY. De plus, je ne suis pas administrateur Windows et je ne peux rien faire sur les contrôleurs de domaine. Mon compte n’a que les privilèges pour ajouter des serveurs au domaine AD.

J’ai activé la journalisation des paquets SSH de PuTTY. J’ai trouvé ceci assez intéressant, je ne suis pas encore sûr de quoi faire de cette information :

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.

Sur les machines Windows faisant partie d’un domaine Active Directory, les utilisateurs reçoivent leur ticket Kerberos d’octroi de ticket (TGT) lorsqu’ils se connectent à Windows, et PuTTY peut l’utiliser pour l’authentification si l’authentification GSSAPI est activée dans PuTTY via Configuration Connection|SSH|Auth|GSSAPI (et que les autres méthodes d’authentification qu’il essaie avant GSSAPI, comme la clé publique via Pageant, ne sont pas configurées ou sont désactivées dans Connection|SSH|Auth).

[Si vous avez également besoin de la délégation de ticket (par exemple, pour monter des systèmes de fichiers kerbérisés sur le serveur après la connexion), assurez-vous que la délégation GSSAPI est également activée dans PuTTY, et que les serveurs auxquels vous vous connectez sont marqués dans Active Directory dans l’onglet Délégation comme « Approuver cet ordinateur pour la délégation à tous les services (Kerberos uniquement) », ce qui n’est pas le cas par défaut. Ce paramètre d’approbation dans AD n’est étrangement nécessaire que pour que la délégation fonctionne depuis les clients Windows comme PuTTY ; il n’est pas nécessaire pour les clients Linux « ssh -K ».]

Sur les machines Windows auto-gérées (personnelles) qui ne font pas partie d’un domaine Active Directory, vous pouvez toujours utiliser l’authentification Kerberos/GSSAPI (et la délégation de ticket) via PuTTY, mais vous devez obtenir le ticket vous-même. Malheureusement, Windows 7 n’est pas livré avec un équivalent du programme kinit (pour demander manuellement un ticket), et PuTTY ne vous demande pas non plus votre mot de passe Kerberos si vous n’avez pas de ticket. Par conséquent, vous devez installer le package MIT Kerberos for Windows, qui inclut à la fois les outils en ligne de commande habituels kinit/klist/kdestroy, ainsi qu’un outil graphique pratique « MIT Kerberos Ticket Manager ». Utilisez-les pour obtenir votre ticket, et PuTTY utilisera alors automatiquement la bibliothèque MIT GSSAPI au lieu de celle Microsoft SSPI, et tout devrait fonctionner. Si le « MIT Kerberos Ticket Manager » est en cours d’exécution, il vous demandera automatiquement votre mot de passe Kerberos lorsque PuTTY a besoin d’un ticket, c’est donc une bonne idée de le lier depuis le dossier Démarrage.

Mise à jour : À partir de Windows 10 version 21H1 et Windows Server 2022, le client et serveur OpenSSH for Windows (version 8.1 ou ultérieure) intégré à Windows prend désormais en charge l’authentification et la délégation GSSAPI (c’est-à-dire ssh -K). Si c’est tout ce dont vous avez besoin, depuis 2021 vous n’avez plus besoin d’installer PuTTY et MIT Kerberos.