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

Question

Github ne permet pas d'utiliser la même clé ssh deploy pour plus d'un projet, ce qui serait très utile dans certains cas (par exemple, un serveur CI traitant un projet avec des sous-modules privés). J'ai vu plusieurs fils de discussion qui semblent dire que cette limitation est là pour des "raisons de sécurité", mais je n'ai pas encore vu d'explication convaincante sur le risque exact que cela soulève.

Notez que le fait que Github n'autorise pas Niveau du compte La réutilisation des clés a du sens (deux utilisateurs ne devraient pas partager leurs clés). C'est seulement la restriction sur Déployer les clés que je remets en question.

Et pour être clair, je suis no Je cherche des solutions de contournement (créer un utilisateur fictif, utiliser plusieurs clés, ...), mais seulement une explication plausible pour cette limitation des clés de déploiement.

Fils connexes :

• L'un d'eux montre un solution de contournement
• Un discuter de la question mais qui ne vont pas vraiment n'importe où

Answer 1

Malheureusement, il s'agit d'un scénario où 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é. La connexion des comptes Github aux paires de clés établit effectivement une correspondance 1:N entre les identités basées sur les comptes Github et les identités des paires de clés.

À l'inverse, github applique une correspondance 1:N entre les projets et les identités basées sur les paires de clés. Dans le monde réel, il existe une porte donnant accès au projet qui peut être déverrouillée par de nombreuses personnes différentes. Mais une fois que l'une d'entre elles a obtenu la clé de la porte, elle ne peut plus jamais obtenir d'autres clés pour d'autres portes.

Il est logique de ne pas réutiliser souvent les clés dans l'optique de contenir les brèches si une clé est compromise. Mais c'est juste une bonne administration politique . Il n'est pas très logique d'empêcher une clé d'être utilisée plus d'une fois. par principe . Le fait qu'il y ait des clés pour certaines portes qui ne sont jamais réutilisées, eh bien, encore une fois, c'est une question de choix. politique .

---

Une vision légèrement plus complexe consiste à illustrer les paires de clés comme suit rôles . Vous pouvez posséder plusieurs paires de clés, et donc habiter plusieurs rôles. La clé privée vous authentifie pour le rôle.

La mise en correspondance des clés de déploiement de Github avec les projets stipule qu'un rôle ne peut jamais englober plus d'une tâche. C'est rarement réaliste.

Rien de tout cela ne change ce que github permet, bien sûr.

Answer 2

La seule raison, illustrée par la solution de contournement à laquelle vous faites référence (création d'un seul utilisateur "build", ou partage du même utilisateur "build"), c'est qu'il n'y a pas d'autre solution. id_rsa.REPONAME.pub par repo) est :

éviter le partage des clés publiques/privées pour différents utilisateurs

Même si ce n'est pas le cas dans votre situation (construction de plusieurs projets), le fait de permettre la réutilisation de la même clé ssh ouvrirait la possibilité d'utiliser deux clés ssh. différents utilisateurs de partager la même clé ssh, ce qui irait à l'encontre de l'objectif de la authentification objectif.

Moyens d'authentification :
"utiliser une certaine clé ssh devrait impliquer que vous êtes supposé savoir qui l'utilise".

Cependant, comme indiqué dans jtlindsey 's réponse Si l'on se réfère à l'histoire de l'Union européenne, il s'agit moins d'une question d'authentification, d'identité ou de bonne politique que d'une question d'" identité ". rôle " que vous attachez à ces clés. (rôle pour déployer un certain référentiel).

Comme indiqué dans " Pourquoi je ne peux pas utiliser une clé ssh sur plusieurs repo github ? " par tkeeler :

Ce flux de travail devient un problème lorsqu'on utilise des systèmes automatisés et des submodules git.
Vous ne pouvez pas utiliser la même clé de déploiement dans plus d'un repo, donc la solution de contournement consiste à ajouter cette clé à leur compte utilisateur (ou à un compte machine dédié).

En choisissant la voie de la moindre résistance, la plupart des utilisateurs l'ajouteront à leur propre compte, ce qui entraînera un risque accru pour la sécurité.

GitHub devrait plutôt laisser l'utilisateur choisir et assumer le risque sur une base par dépôt.

---

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

• Transfert d'agent SSH : Le transfert d'agent utilise les clés SSH déjà configurées sur votre machine de développement locale lorsque vous vous connectez en SSH à votre serveur et exécutez des commandes git.
  Vous pouvez sélectivement laisser les serveurs distants accéder à votre ssh-agent local comme s'il était exécuté sur le serveur.
  Il n'est donc pas nécessaire de répliquer votre clé privée sur le serveur.

• Utilisateurs de machines (c'est la stratégie du "compte factice") Attachez la clé à un compte utilisateur. Comme ce compte ne sera pas utilisé par un humain, on l'appelle un utilisateur machine.
  Vous traiteriez cet utilisateur de la même manière qu'un humain, en attachant la clé au compte utilisateur de la machine comme s'il s'agissait d'un compte normal.
  Accordez au collaborateur du compte ou à l'équipe l'accès aux dépôts auxquels il doit accéder.
  Donc une clé privée associée à un "utilisateur machine", une par serveur.

( DHa souligne dans les commentaires à un nombre limite de clés de déploiement, et le fait que vous ne pouvez avoir qu'un seul compte utilisateur de machine)

• Déployer la clé (une par repo GitHub) Clé SSH stockée sur le serveur et donnant accès à un seul repo sur GitHub.
  Cette clé est attachée directement au repo plutôt qu'à un compte utilisateur. .
  Au lieu d'aller dans les paramètres de votre compte, allez sur la page d'administration du repo cible.
  Aller à " Deploy Keys "et cliquez sur " Add deploy key ". Collez la clé publique et soumettez.

Cette fois, la clé ssh n'est pas attachée à un utilisateur (pour lequel vous pourriez accorder l'accès à plusieurs repo), mais à un seul repo.
Accorder l'accès ssh pour plusieurs repo serait l'équivalent d'un "utilisateur machine".

En termes de authentification :

• l'utilisation de la même clé pour plusieurs dépôts est acceptable si elle est faite par un utilisateur (qui a ladite clé associée à son compte)
• utiliser la même clé pour plusieurs repo n'est PAS acceptable lorsque la clé est attachée à un repo, parce que vous ne le savez pas du tout qui accéder à quoi.
  Cela diffère de l'"utilisateur machine" où un "utilisateur" est déclaré comme collaborateur pour de nombreux repo.
  Ici (touche Déployer), il n'y a pas de "collaborateur" il suffit d'un accès direct par ssh au repo.

---

Yusuf Bhabhrawala illustre davantage cette limitation du modèle dans les commentaires :

Considérez ces cas d'utilisation très plausibles - un projet python utilisant un module pip privé ou un projet node utilisant un paquet npm privé - tous deux provenant d'un autre dépôt de la même organisation.

Actuellement, il n'y a aucun moyen de déployer ce cas d'utilisation très simple en utilisant une clé de déploiement ou une clé de compte (qui expose trop d'autres dépôts).

Et Chris Stenkamp fait remarquer à " Comment découvrir où ' pip install git+ssh://... cherche les clés ssh ? ", qui consiste à fixer le GIT_SSH_COMMAND variable d'environnement.

Answer 3

Je me rends compte que vous ne recherchez pas une solution de contournement, mais j'imagine que beaucoup d'utilisateurs arrivent sur cette page et aimeraient également une solution simple. La solution de contournement dont vous avez posté le lien est similaire à ce qui se trouve sur la page d'accueil. dans les documents github . Ce processus est source d'erreurs s'il est effectué manuellement.

Pour info, Bitbucket.org n'a pas cette limitation. Vous pouvez utiliser la même clé d'accès en lecture seule sur plusieurs dépôts . Il est ainsi très facile d'utiliser un seul serveur de production avec plusieurs dépôts.

Si vous vous en tenez à Github, voici une script que j'ai écrit qui vous permet de passer simplement le nom du propriétaire du dépôt et le nom du dépôt en exécutant ./generateDeployKey.sh repo_owner_name repo_name et il fait tout pour vous et sort tout ce que vous pourriez avoir besoin de copier.

Enregistrez les éléments suivants dans un nouveau fichier nommé generateDeployKey.sh

#!/bin/sh
# This script generates a ssh key for a single repository
# and adds a custom configuration to the users (not global) ssh config file,
# and outputs the public key for you to copy and paste as the repo deploy key
# and outputs the url for you to clone the repo on the machine.
# Github docs ref:
# https://docs.github.com/en/developers/overview/managing-deploy-keys#using-multiple-repositories-on-one-server
#
# 1. Add the script to the user account of the machine. The home directory is fine.
# 2. Make the script executable by running the following command as the user:
# chmod u+x generateDeployKey.sh
# 3. Run script like `./generateDeployKey.sh REPO_OWNER_NAME REPO_NAME` Note the space between owner and repo name. Example:
# ./generateDeployKey.sh yourname hello_world
# If you make a mistake with what you pass in, you can remove change from your ~/.ssh/config file
# by deleting the most recent "New Key Generated on...." and deleting the related .pub and private keys

# Check if user passed in both parameters
if [ -z "$1" ] || [ -z "$2" ]
then
  echo "Make sure to pass in both parameters REPO_OWNER_NAME and REPO_NAME. Example:"
  echo "./generateDeployKey.sh yourname hello_world"
else
  REPO_OWNER_NAME=$1
  REPO_NAME=$2
  KEY_PATH=~/.ssh/id_rsa.$REPO_NAME
  echo "Generating ssh key At ${KEY_PATH}"
  ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa.${REPO_NAME}
  echo "Your ssh deploy key is:"
  PUB_KEY_PATH=$KEY_PATH".pub"
  cat $PUB_KEY_PATH
  echo ""
  # Will create config if it does not exist
  echo "Updating ~/.ssh/config"
  DATE_TIME=$(date +"%Y-%m-%d at %r")
  echo "
  # New Key Generated on $DATE_TIME
  Host github.com-$REPO_NAME
    HostName github.com
    User git
    IdentityFile $KEY_PATH" >> ~/.ssh/config
  echo ""
  echo "Here is your hostname's alias to interact with the repository using SSH:"
  echo "git clone git@github.com-$REPO_NAME:$REPO_OWNER_NAME/$REPO_NAME.git"
fi

Answer 4

Il m'a fallu beaucoup de réflexion pour rationaliser les implications et j'ai abouti à ce scénario.

Imaginez que vous créez une clé de déploiement unique pour un utilisateur que vous avez affecté à plusieurs référentiels. Vous voulez maintenant révoquer cette clé mais elle est utilisée à plusieurs endroits. Ainsi, au lieu de pouvoir révoquer tous les accès, vous pouvez par inadvertance ne révoquer qu'un accès partiel.

Cela peut sembler un avantage, mais cette relation de personne à personne est en fait intrinsèquement peu sûre si l'on tient compte du facteur humain. En effet, vous ne pouvez pas savoir avec certitude si vous avez réellement révoqué tous les accès sans inspecter chaque dépôt et comparer chaque clé publique individuellement dans le cas où vous auriez oublié où vous l'avez réellement assignée.

Il est certainement frustrant d'attribuer 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 institué sa politique : lorsque vous révoquez une clé, vous avez la garantie de révoquer tous les accès accordés par cette clé, car elle n'est utilisée qu'à un seul endroit.