Solution 1 :
Sur les machines Windows faisant partie d'un domaine Active Directory, les utilisateurs reçoivent leur ticket d'octroi de tickets Kerberos lorsqu'ils se connectent à Windows, et PuTTY peut l'utiliser pour l'authentification si l'authentification GSSAPI est activée dans PuTTY Configuration Connection|SSH|Auth|GSSAPI (et d'autres méthodes d'authentification qu'il essaie avant GSSAPI, telles que la clé publique via Pageant, ne sont pas configurées ou désactivées dans Connection|SSH|Auth).
[Si vous avez également besoin d'une délégation de tickets (par exemple, pour monter des systèmes de fichiers kerberisés sur le serveur après la connexion), assurez-vous que la délégation GSSAPI est également activée dans PuTTY, et les serveurs auxquels vous vous connectez sont marqués dans Active Directory dans l'onglet Délégation comme "Faire confiance à cet ordinateur pour la délégation à n'importe quel service (Kerberos uniquement) ", ce qu'ils ne sont pas par défaut. Ce dernier paramètre de confiance dans AD n'est étrangement nécessaire que pour que la délégation fonctionne à partir de clients Windows comme PuTTY ; il n'est pas nécessaire pour les clients Linux "ssh -K".]
Sur les machines Windows autogé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 installé avec un équivalent du programme kinit (pour que vous demandiez 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 pour Windows, qui comprend à la fois les outils de ligne de commande habituels kinit/klist/kdestroy, ainsi qu'un outil graphique soigné "MIT Kerberos Ticket Manager". Utilisez-les pour obtenir votre ticket, puis PuTTY utilisera automatiquement la bibliothèque MIT GSSAPI au lieu de celle de 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 à partir du dossier de démarrage.
Solution 2 :
Vérifiez d'abord que votre sortie klist sur la boîte Windows exécutant PuTTY affiche un TGT valide. Ensuite, dans la configuration de votre session PuTTY, assurez-vous de tenter l'authentification GSSAPI est activé dans Connection - SSH - Auth - GSSAPI . Enfin, assurez-vous qu'il est configuré pour se connecter automatiquement avec votre nom d'utilisateur dans Connection - Data . Vous pouvez soit spécifier explicitement le nom d'utilisateur, soit sélectionner le bouton radio pour Utiliser le nom d'utilisateur du système .
Historiquement, c'est tout ce que j'avais à faire pour que la connexion SSH sans mot de passe fonctionne via Kerberos.
Solution 3 :
Le problème était dans la configuration de Windows Kerberos. Je pense que notre Active Directory est configuré de manière géniale, je ne sais pas vraiment, je ne suis pas un administrateur Windows.
Mais j'ai résolu le problème en configurant manuellement Kerberos à l'aide de ksetup dans la CLI de Windows 7.
Après un redémarrage sur mon poste de travail distant, je n'ai pas pu me connecter à mon PC. En effet, dans la configuration d'origine, la partie TLD de mon domaine de domaine était toujours absente (domaine\utilisateur), mais après l'avoir configuré manuellement, j'ai dû modifier mon domaine de connexion pour refléter le nom de domaine complet du domaine (domaine.TLD\utilisateur) et J'ai pu me connecter à mon PC Windows, même si l'authentification semble prendre plus de temps maintenant.
Avant les modifications, la sortie de ksetup n'affichait que mon domaine par défaut, et il était en minuscules.
J'ai utilisé " nslookup -type=SRV _kerberos._tcp.domain.TLD " pour obtenir tous les serveurs kdc de mon domaine.
Je n'ai défini aucun drapeau.
J'ai mis en correspondance mon nom d'utilisateur " ksetup /mapuser [email protected] user "
Ressources que j'ai utilisées :https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC
https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html
Si quelqu'un a des suggestions que je peux donner aux administrateurs de Windows sur la façon dont ils peuvent résoudre ce problème (est-ce cassé ?), je les transmettrai.