Comment puis-je utiliser la même clé pour SSH et SSL (https)

J'essaie d'installer les outils de développement pour une petite équipe et je n'arrive pas à obtenir l'authentification correcte.

Puisque nous sommes une équipe distribuée, le serveur est sur Internet. Et j'aimerais avoir une configuration client SSO + zéro.

Donc, fondamentalement, git sur https + webdav n'est pas pratique, car le client git ne peut utiliser que l'authentification de base mais n'enregistre pas le mot de passe et certains plugins IDE ne transmettent même pas la question du mot de passe dans leur interface utilisateur.

Je dois alors utiliser git sur ssh. J'ai installé la gitose et cela fonctionne essentiellement avec des clés asymétriques, ok. Je vais devoir demander à chaque développeur d'installer sa clé, je peux le faire, oublier la configuration zéro.

Ensuite, je veux que les développeurs accèdent aux outils web (wiki, tickets, etc.) qui sont sur https, mais cette fois je dois leur donner soit un login / mot de passe soit une autre clé privée juste parce que les formats ne sont pas compatibles entre SSH et SSL et l'endroit où le stocker sur le système d'exploitation n'est pas le même. Maintenant, je dois oublier le SSO?

Suis-je trompé?

ssh ssl certificate

— tshepang
source

Réponses:

Résumé TL; DR: Si vous avez un certificat + clé SSL / X.509, donnez simplement le fichier de clé privée à ssh. Ou , si vous avez déjà une clé SSH id_rsa, utilisez-la simplement avec OpenSSL lors de la signature d'un CSR. C'est tout.

Supposons que vous disposez du certificat SSL d'un utilisateur joeuser.pemet de sa clé privée joeuser.key.

Étant donné que X.509 utilise des clés RSA standard, ainsi que SSH, vous devriez pouvoir simplement dire à votre client SSH d'utiliser joeuser.key- la seule condition est qu'il soit dans un format compréhensible.

Regardez l'intérieur joeuser.keyet vérifiez si cela ressemble un peu à ceci:

----- COMMENCER LA CLÉ PRIVÉE RSA -----
MGECAQACEQCxQaFwijLYlXTOlwqnSW9PAgMBAAECEETwgqpzhX0IVhUa0OK0tgkC
CQDXPo7HDY3axQIJANLRsrFxClMDAghaZp7GwU2T1QIIMlVMo57Ihz8CCFSoKo3F
2L / 2
----- FIN DE LA CLÉ PRIVÉE RSA -----

Dans Open SSL , ce format est appelé "PEM" (comme dans -outform pem) et est utilisé par défaut. Le même format est utilisé par Open SSH , et vous pouvez utiliser ssh -i joeuser.keypour vous connecter.

Vous pouvez extraire la clé publique au id_rsa.pubformat OpenSSH (à insérer authorized_keys) avec:

ssh-keygen -y -f joeuser.key> joeuser-ssh.pub

(La même clé publique au format PEM peut être extraite avec openssl rsa -pubout, mais elle sera peu utile.)

Si vous avez une clé DSA, elle devrait fonctionner exactement de la même manière que RSA.

— user1686
source

bonjour, merci, mais je sais que je peux convertir un format de clé en un autre pour chaque développeur, mais mon problème est d'éviter autant de configuration que possible de leur part. Pour autant que je m'en souvienne (j'avoue que je n'ai pas vérifié récemment), l'ajout d'un certificat 509 pour tous les navigateurs clients n'est pas anodin.

nraynaud: Ce sont des développeurs . S'ils ne peuvent pas installer un certificat X.509 sur leur navigateur préféré (au moins en suivant TFM), c'est déjà effrayant.

— user1686

...en tous cas. Pour les navigateurs basés sur NSS (Firefox, Mozilla, Epiphany), il existe un ensemble d'outils de ligne de commande à modifier cert.db. Pour Windows, les certificats peuvent être installés à l'aide de certutil ou (je pense) via la stratégie de groupe AD. SSH ne nécessite aucune configuration, il suffit de ssh-keygen -y -fvider les deux fichiers dans le répertoire d'origine de l'utilisateur.

— user1686

ce ne sont pas des développeurs, ce sont des étudiants de première année non scolarisés et des stagiaires. Je les martèle simplement avec git, sécurité web, javascript, sécurité et code propre. Je veux juste limiter ce genre de choses non centrées sur le développement. (en plus, je déteste les gens qui m'imposent ce genre de choses idiotes, donc je veux juste éviter d'imposer ça aux autres)

Bien que cela fonctionne, je vous déconseille. Vous utilisez les mêmes clés, mais de différentes manières, différents formats. Lorsque les utilisateurs génèrent de nouveaux certificats X.509, ils utiliseront de toute façon différentes clés pour SSH et HTTPS. Il serait logique qu'OpenSSH prenne en charge l'intégralité de la PKI X.509 (comme le fait OpenVPN, où vous pouvez utiliser des scripts pour lier des certificats à LDAP et vérifier si un utilisateur est dans le groupe approprié).

— Hubert Kario

OpenSSH a un support expérimental pour les certificats x509 ici:

http://roumenpetrov.info/openssh

Vous pouvez émettre un seul certificat x509 par utilisateur et les utiliser pour les deux.

au lieu de placer la clé publique de l'utilisateur dans ses clés autorisées, vous pouvez spécifier les DN autorisés des certificats utilisateur; et vous devez configurer le serveur Web / l'application Web pour que le DN soit traduit en nom d'utilisateur.

— b0fh
source

Merci beaucoup, mais l'installation est encore pire que la configuration je pense.

Vous voulez dire installer la version corrigée de openssh? il peut être déjà expédié par votre distribution (je sais qu'au moins Gentoo le fait). Il est inutile d'utiliser la même clé RSA pour les deux applications mais avec un format différent - vous devez toujours configurer manuellement la clé publique ssh de chaque utilisateur. OTOH, avec des clés x.509, vous pouvez garder votre autorité de certification distincte, et ajouter de nouveaux utilisateurs à SSH ou HTTPS peut se faire sans connaître leur clé publique, il vous suffit de choisir une politique de DN cohérente ...

— b0fh

Pour info, cette fonctionnalité est maintenant dans la version principale d'OpenSSH.

— Zoredache

Vous n'avez pas beaucoup de chance - les clés SSH et les certificats SSL sont différents animaux et pour autant que je sache, ils ne sont pas interchangeables.

Votre meilleur pari est probablement de configurer l'authentification unique / le magasin de mots de passe partagé / quoi que ce soit pour vos outils Web et de laisser git / gitosis comme îlot d'authentification.

— voretaq7
source