J'ai une machine Windows 7 qui ne fait pas partie du domaine et une machine Linux.
Je souhaite me connecter à Linux à partir de Windows à l'aide d'un certificat x509 stocké dans le magasin de certificats Windows.
C'est possible?
Citant Comment configurer OpenSSH pour utiliser la PKI x509 pour l'authentification?
Je ne parle pas simplement de mettre la clé publique RSA d’un certificat x.509 dans ~ / .ssh / registered_keys - je cherche un moyen de configurer un SSH tel que des certificats x.509 signés par une autorité de certification prédéfinie automatiquement être autorisé à accéder au compte d'utilisateur lié. La RFC 6187 semble suggérer une telle fonctionnalité
Je ne souhaite pas installer de clés pour chaque utilisateur au lieu d'un certificat d'autorité de certification, d'un certificat d'ordinateur et d'un DN de certificat de mappage pour héberger les noms d'utilisateur à autoriser.
De https://serverfault.com/questions/417518/windows-ca-to-issue-certificate-to-authenticate-ssh-to-a-linux-server?lq=1 il semble que ce n’est possible qu’avec un serveur OpenSSH en fork. Suite à une réponse il
Je ne suis pas enclin à diverger de la branche principale d'OpenSSH, la sécurité est trop importante et je ne dispose pas des ressources nécessaires pour vérifier correctement cette importante modification.
Le patch mesure 200 Ko, il est trop facile de se tirer une balle dans le pied avec un langage aussi dangereux que C sans une communauté importante dans la branche principale d’OpenSSH. De plus, il semble mettre en œuvre un projet plus ancien au lieu de RFC 6187
La communauté OpenSSH n'est pas intéressée par x509 parce que travailler avec une spécification aussi importante est pénible:
Les développeurs ont maintenu que la complexité des certificats X.509 introduit une surface d’attaque inacceptable pour sshd. Au lieu de cela, ils ont [récemment] implémenté un format de certificat alternatif qui est beaucoup plus simple à analyser et présente donc moins de risques.
Le "format de certificat alternatif" ci-dessus n'est pas une bonne idée pour moi non plus. X.509 étant largement pris en charge, deux certificats et une clé privée peuvent être utilisés dans de nombreux endroits différents, par exemple. dans TLS, IPSec, S / MIME et d’autres applications de CMS. De plus, la révocation centralisée semblable aux listes de révocation de certificats n'est pas prise en charge, de sorte que la révocation des "certificats alternatifs" avec des clés privées compromises est fastidieuse et source d'erreurs.
Jusqu'à présent, la seule option viable est GSSAPI - elle est même prise en charge par PuTTY.
Y a-t-il autre chose pour simplifier la gestion des clés SSH?