Utilisation de la même clé de déploiement pour plusieurs projets github

Github ne permet pas d’utiliser la même clé de déploiement ssh pour plusieurs projets, ce qui serait très utile dans certains cas (par exemple, serveur CI traitant de projets avec des sous-modules privés). J’ai vu différents sujets qui semblent indiquer que cette limitation existe pour des «raisons de sécurité», mais je ne vois pas encore d’explication convaincante sur le risque que cela poserait.

Notez que le fait que Github n’autorise pas la réutilisation des clés de niveau compte est logique (deux utilisateurs ne doivent pas partager les clés). C’est seulement la ressortingction sur les clés de déploiement que je remets en question.

Et pour être clair, je ne recherche pas de solutions de contournement (créer un utilisateur factice, utiliser plusieurs clés, etc.), mais seulement pour une explication plausible de cette limitation sur les clés de déploiement.

Fils associés:

  • Un montrant une solution de contournement
  • On discute de la question mais on ne va pas vraiment n’importe où

La seule raison, illustrée par la solution de contournement à laquelle vous faites référence (création d’un utilisateur unique “build” ou partage du même id_rsa.REPONAME.pub par id_rsa.REPONAME.pub ) est la suivante:

éviter de partager une clé publique / privée pour un utilisateur différent

Même si cela ne serait pas le cas dans votre cas (générer plusieurs projets), autoriser la réutilisation de la même clé ssh ouvrirait la possibilité pour deux utilisateurs différents de partager la même clé ssh, ce qui irait à l’ encontre de l’ objective de l’ authentification .

Authentification signifie:
“L’utilisation d’une certaine clé ssh devrait impliquer que vous êtes censé savoir qui l’ utilise”.


La page GitHub ” Gestion des clés de déploiement ” détaille les différents comptes utilisant ssh:

  • Transfert de l’agent SSH : le transfert de l’ agent utilise les clés SSH déjà configurées sur votre ordinateur de développement local lorsque vous connectez SSH à votre serveur et exécutez les commandes git.
    Vous pouvez laisser sélectivement les serveurs distants accéder à votre agent ssh local comme s’il était exécuté sur le serveur.
    Donc, pas besoin de répliquer votre clé privée sur le serveur.

  • Utilisateurs de la machine : (il s’agit de la stratégie “Compte factice”) Connectez la clé à un compte d’utilisateur. Comme ce compte ne sera pas utilisé par un humain, il s’appelle un utilisateur de machine.
    Vous devez traiter cet utilisateur de la même manière que vous le feriez avec un humain, attachez la clé au compte d’utilisateur de la machine comme s’il s’agissait d’un compte normal.
    Accordez au collaborateur du compte ou à l’équipe l’access aux pensions auxquelles il a besoin d’accéder.
    Donc, une clé privée associée à un “utilisateur de la machine”, une par serveur.

  • Déployez la clé SSH (un par repository GitHub) stockée sur le serveur et donne access à un seul repository sur GitHub.
    Cette clé est attachée directement au repository plutôt qu’à un compte utilisateur .
    Au lieu d’aller dans les parameters de votre compte, accédez à la page d’administration du repository cible.
    Allez dans ” Deploy Keys ” et cliquez sur ” Add deploy key “. Collez la clé publique dans et soumettez.

Cette fois, la clé ssh n’est pas attachée à un utilisateur (pour lequel vous pouvez accorder l’access à plusieurs référentiels), mais à un seul référentiel.
Accorder l’access ssh à plusieurs référentiels équivaudrait à un “utilisateur de la machine”.

En terme d’ authentification :

  • utiliser la même clé pour plusieurs mises en pension est acceptable lorsque cela est fait par un utilisateur (qui a cette clé associée à son compte)
  • utiliser la même clé pour plusieurs sockets en pension n’est PAS correct lorsque la clé est attachée par un repo, car vous ne savez pas du tout qui a accédé à quoi.
    Cela diffère de “l’utilisateur de la machine” où un “utilisateur” est déclaré collaborateur pour de nombreux repo.
    Ici (clé de déploiement), il n’y a pas de “collaborateur” , juste un access ssh direct accordé au repository.

Il m’a fallu beaucoup de reflection pour rationaliser les implications et arriver à ce scénario.

Imaginez que vous créez une clé de déploiement unique pour un utilisateur que vous avez atsortingbué à plusieurs référentiels. Maintenant, vous voulez révoquer cette clé mais elle est utilisée à plusieurs endroits. Ainsi, au lieu de pouvoir révoquer tous les access, vous pouvez par inadvertance uniquement révoquer un access partiel.

Cela peut sembler être un avantage mais cette relation plusieurs-à-un-est en fait insortingnsèquement peu sûre une fois que vous considérez le facteur humain. En effet, vous ne pouvez pas savoir avec certitude si vous avez réellement révoqué tous les access sans inspecter chaque référentiel et comparer chaque clé publique individuellement dans le cas où vous avez oublié l’endroit où vous l’avez effectivement atsortingbué.

Il est vraiment frustrant d’affecter et de gérer autant de clés uniques, mais les implications en matière de sécurité sont claires avec la façon dont GitHub a mis en place sa politique: lorsque vous révoquez une clé, vous êtes assuré de révoquer tous les access .

Malheureusement, github interprète mal la distinction entre une paire de clés et un compte ou un projet.

Comme une paire de clés est utilisée pour l’authentification et l’autorisation, il s’agit effectivement d’une identité. Les comptes Github sont une autre identité. Connecter des comptes github à des paires de clés établit efficacement un mappage 1: N entre les identités basées sur les comptes github et les identités de paires de clés.

À l’inverse, github applique un mappage 1: N des projets aux identités basées sur une paire de clés. L’analogue du monde réel est qu’il existe une porte donnant access au projet et qui peut être débloquée par de nombreuses personnes différentes. Mais une fois que l’un d’entre eux obtient la clé de la porte, ils ne peuvent plus obtenir d’autres clés pour d’autres portes.

Il est judicieux de ne pas réutiliser les clés souvent dans la perspective de contenir des violations si une clé est compromise. Mais ce n’est qu’une bonne politique d’ administration. Cela n’a pas beaucoup de sens d’empêcher l’utilisation d’une clé plus d’une fois par principe . Qu’il y ait des clés pour certaines portes qui ne sont jamais réutilisées, eh bien, encore une fois, c’est la politique .


Une vue légèrement plus complexe consiste à illustrer les paires de clés en tant que rôles . Vous pouvez posséder plusieurs paires de clés et par conséquent, habiter de nombreux rôles. La clé privée vous authentifie pour le rôle.

Le mappage des clés de déploiement de Github aux projets indique qu’un rôle ne peut jamais englober plus d’une tâche. C’est rarement réaliste.

Rien ne change bien sûr ce que github permet.