web-dev-qa-db-fra.com

github deploy keys: comment autoriser plusieurs référentiels pour une seule machine

Donc, j'ai un hôte, appelez-le rob. J'ai utilisé ssh-keygen sur rob pour obtenir une clé publique, que j'ai donnée à github dans l'écran d'ajout d'une nouvelle clé de déploiement pour le référentiel cheech. Maintenant, je souhaite également déployer chong sur rob. Mais si je vais à l'écran d'ajout d'une nouvelle clé de déploiement pour le référentiel chong sur github, et que je colle la clé publique que j'ai générée sur rob, elle indique key already in use. Je pensais que si la clé était utilisée, je pourrais cloner chong sur rob mais cela dit permission refusée.

Donc, clairement, c'est plus compliqué que je ne le pensais et cela implique de posséder plusieurs clés. Que dois-je faire pour cloner chong sur rob?

Merci de votre aide.

githubssh-keys
35
user1552512

Une fois qu'une clé a été attachée à un référentiel en tant que clé de déploiement, elle ne peut plus être utilisée sur un autre référentiel. Si vous rencontrez cette erreur lors de la configuration des touches de déploiement Up, vous devez modifier votre télécommande et configurer votre fichier ~/.ssh/config afin qu'il utilise un nom d'hôte non-existant github.com qui ssh pourra choisir la clé de déploiement ssh appropriée pour votre référentiel 

# first we remove the Origin
$ git remote -v
Origin  [email protected]:username/foo.git (fetch)
Origin  [email protected]:username/foo.git (Push)
$ git remote rm Origin

# here we add a new Origin using a Host nickname called
# foo.github.com that we will reference with a Host stanza in our
# ~/.ssh/config to specify which key to use with which fake hostname.
$ git remote add Origin [email protected]:username/foo.git
$ git remote -v
Origin  [email protected]:username/foo.git (fetch)
Origin  [email protected]:username/foo.git (Push)

Générez la clé de déploiement pour votre référentiel et nommez-le quelque chose Raisonnable comme:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa-foo -C https://github.com/username/foo
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/username/.ssh/id_rsa-foo.
Your public key has been saved in /home/username/.ssh/id_rsa-foo.pub.
The key fingerprint is:
c0:ff:ee:34:24:11:5e:6d:7c:4c:b1:a0:de:ad:be:ef https://github.com/username/foo
The key's randomart image is:
+--[ RSA 2048]----+
|  E   o..o.oo.   |
| M o o o .+CoW   |
|  + o = o. ..    |
| .   . +         |
|        S        |
|       o .       |
|        +        |
|       . o       |
|        ..o.     |
+-----------------+

Une fois que vous avez ajouté la clé de déploiement Vous devrez ensuite ajouter la strophe suivante à votre fichier ~/.ssh/config:

Host fake-hostname-foo.github.com
    Hostname github.com
    IdentityFile ~/.ssh/id_rsa-foo

Maintenant, vous pouvez le tester avec:

$ ssh -T [email protected]
Hi username! You've successfully authenticated, but GitHub
does not provide Shell access.
62
aculich

La solution la plus simple que j'ai trouvée a été décrite ici .

1) Entrez cette commande (vous le ferez pour le nombre de clés dont vous avez besoin):

ssh-keygen -t rsa -C "[email protected]"

2) Lorsque vous êtes invité avec l’instruction ci-dessous, entrez un nom unique (par exemple, foo1_rsa). Le fichier sera créé dans votre répertoire actuel et vous devrez peut-être le déplacer vers .ssh si vous souhaitez que tout soit bien rangé:

Entrez le fichier dans lequel enregistrer la clé (/Users/you/.ssh/id_rsa): [Appuyez sur Entrée]

3) Mettez à jour votre fichier de configuration SSH:

vi ~/.ssh/config

Qui peut être vide:

Host cheech github.com
Hostname github.com
IdentityFile ~/.ssh/foo1_rsa

Host chong github.com
Hostname github.com
IdentityFile ~/.ssh/foo2_rsa
11
Naruto Sempai

Une clé de déploiement pour github est unique ... Vous devez générer une nouvelle clé pour l'autre référentiel. Il suffit de lancer à nouveau ssh-keygen

Voir la documentation de github à ce sujet: https://help.github.com/articles/managing-deploy-keys

3
klaustopher

Si vous souhaitez donner à rob l'accès à tous les référentiels privés de votre compte GitHub, vous pouvez supprimer la clé en tant que clé de déploiement de cheech, puis l'ajouter en tant que clé SSH à votre compte GitHub dans son ensemble. Cela donnerait rob accès à la fois à cheech et à chong. 

Cela ne fonctionnera pas si vous avez d'autres référentiels dans votre compte auxquels vous ne souhaitez pas accéder à rob.

Si vous avez besoin d'un contrôle plus précis, vous devrez générer des clés supplémentaires sur rob et les affecter en tant que clés de déploiement à des référentiels spécifiques.

2
Nathan

Je sais que c'est plus de 5 ans mais il n'y a pas de réponse acceptée à cette question populaire, alors voici ce que je considère comme le meilleur moyen de considérer la propreté et la lisibilité future: 

AJOUTER UN UTILISATEUR DEPLOYÉ À VOTRE ÉQUIPE

Étape 1: Créez une nouvelle adresse électronique dans le domaine de votre entreprise pour un nouvel utilisateur deploy. Quelque chose comme [email protected].

Étape 2: Utilisez cette boîte aux lettres pour créer un nouveau compte GitHub ( GitHub appelle ces "utilisateurs de la machine" ) et attribuez-lui un nom d'utilisateur tel que deploy-ExampleOrganisation afin que son rôle soit clairement défini.

Étape 3: créez un utilisateur sur votre serveur nommé "deploy" avec une commande comme celle-ci:

useradd -d /home/deploy -m deploy

Générez une clé SSH pour deploy @ nom_serveur en spécifiant l'absence de phrase secrète et /home/deploy/.ssh/id_rsa comme emplacement du fichier:

ssh-keygen -t rsa -b 4096 -C "deploy@servername"

Ajoutez le contenu de /home/deploy/.ssh/id_rsa.pub en tant que clé SSH sur votre nouveau compte deploy-ExampleOrganisation GitHub: Accédez à Paramètres> SSH et GPG clés> Nouvelle clé SSH.

Étape 4: Créez une équipe dans votre organisation appelée quelque chose comme "Utilisateurs de déploiement en lecture seule", ajoutez votre nouvel utilisateur à l'équipe et donnez à l'équipe un accès en lecture à tous les dépôts qui seront déployés. . (Si vous n'avez pas de compte d'organisation, vous pouvez toujours donner à cet utilisateur l'accès à plusieurs dépôts privés)}

Étape 5: Ajoutez la clé SSH de votre propre machine personnelle pour déployer le fichier de clés autorisées de l'utilisateur (home /deploy/.ssh/authorized_keys)} afin que vous (ou votre script de déploiement) puissiez vous connecter en tant que deploy lors du déploiement du code.

Boom! C'est ça ... Vous avez maintenant un flux propre et auto-documenté. 

PS J'ai essayé la réponse fort élogieuse de aculich, mais je me suis dit que je ne pouvais pas revenir à cela dans quelques années et que je devrais facilement savoir ce que j'ai fait pour créer tous les touches et comprendre comment ce fichier de configuration SSH permet de faire fonctionner ces amusantes adresses distantes non existantes? Probablement pas!

Avantages d'un utilisateur de déploiement par rapport à une méthode de noms d'hôtes factices:

  • Pas de piratage! Il s'agit de comptes d'utilisateur standard avec des noms clairs, accédant à des pensions via de vrais noms d'hôtes.
  • Moins de clés flottant autour. 
  • Si/lorsque vous passez à des serveurs supplémentaires, il est facile de donner à votre utilisateur Deploy un compte sur chacun d'entre eux et en ajoutant simplement une nouvelle clé à son compte GitHub, son compte sur le nouveau serveur est prêt à déployer du code.
  • L'utilisateur à déployer uniquement dispose d'un accès en lecture seule aux privilèges bas répertoriés uniquement dans l'équipe et vos clés SSH personnelles sont conservées hors du serveur. Ainsi, si une personne méchante parvient à accéder à votre serveur, elle ne peut pas nuire à tous vos repos. ainsi que. 
  • Déployez les fichiers de configuration de l'outil (par exemple, Capistrano) ne soyez pas encrassés avec ces faux noms d'hôtes déroutants. (C'est quand ils ont commencé à se répandre au-delà du serveur que je suis vraiment devenu mal à l'aise avec cette méthode.)} 
  • Si vous oubliez comment vous l'avez fait depuis des années, la propriété du fichier vous mènera à l'utilisateur ls -la à déployer, la clé SSH vous mènera au nom de compte GitHub ssh -T [email protected] et, espérons-le, vous serez à nouveau totalement opérationnel. 
  • Et enfin ... c'est la méthode recommandée par GitHub. 
2
Martin Joiner

La gestion de plusieurs clés de déploiement GitHub peut être facilitée avec mon petit module npmgithub-add-key . Il utilise l'approche décrite dans ceci excellente réponse, et tout ce dont vous avez besoin est

$ github-add-key rob/chong

dans votre rob/chong cloné localement et suivez le processus automatisé simple.

1
Vassiliy Pimkin

Je n'ai pas vu de réponse facile ou facile ici, alors j'ai pensé jeter ma solution. Je n'aime pas les réponses dans lesquelles vous devez changer le nom de domaine, utiliser des scripts wrapper, manipuler avec un trousseau de clés ou manipuler des fichiers de configuration .ssh. SSH est juste le transport pour git, donc je ne veux pas remplir mes dossiers importants de ssh et ma configuration avec des hacks et des paramètres pour utiliser plusieurs clés de déploiement qui, une fois définies, ne me dérangent pas et n’en ont qu’une par rapport. Cela devrait être une config git - et ce l'est.

En outre, pourquoi ne pas conserver les informations d'identification dans le dossier .git du référentiel afin que, si vous supprimez le dossier Repos, vous supprimiez la clé de déploiement?

Supposons que/tmp/deploy_key est l’emplacement initial (temporaire) de votre clé de déploiement privée.

# Initial clone of repo    
GIT_SSH_COMMAND="ssh -i /tmp/deploy_key" git clone [email protected]:folder/reponame.git

# cd to the folder to assure we only change config for the repo instead of user/global.
cd reponame
# Could probably just mv instead of cp/chmod/rm the key but lets be precise
cp /tmp/deploy_key ./.git/deploy_key
chmod 600 ./.git/deploy_key
rm /tmp/deploy_key

# This is the magic - note the backslash escaping the $ as PWD is always the repo's
# folder when pulling or pushing etc... and at git (run) command time $PWD is the
# repo's root folder.
git config core.sshCommand "ssh -i \$PWD/.git/deploy_key"

Vous pouvez aussi bien sûr stocker la clé ailleurs et utiliser un chemin absolu sans le $ PWD pour la clé de déploiement: -

# Initial clone of repo    
GIT_SSH_COMMAND="ssh -i /path/to/a/deploy_key" git clone [email protected]:folder/reponame.git
# cd to repo to configure only for this repo
cd reponame
git config core.sshCommand "ssh -i /path/to/a/deploy_key"

Mais je préfère le conserver dans les dossiers .git internes du référentiel. Par conséquent, si je supprime le dossier du référentiel, je sais qu'il n'y a pas d'informations d'identification qui traînent, et que vous ne pouvez disposer que d'un seul référentiel par clé de déploiement.

0
Jimmy

Vous pouvez également créer un wrapper ssh et le transmettre sous la forme GIT_SSH. Cette option a l'avantage de ne pas avoir à changer la télécommande git. https://stackoverflow.com/a/14221028/3461

0
Benjamin Atkin

Bien que l'idée de Pimkin fût géniale, je ne voulais pas installer node juste pour cela, alors j'ai créé quelque chose de similaire dans bash:

https://Gist.github.com/blvz/8eeebacae11011c25fc79eff12f49ae9

Installer et utiliser:

curl https://Gist.githubusercontent.com/blvz/8eeebacae11011c25fc79eff12f49ae9/raw/6f2f7f3709a0fe852d8a3a5bb125325e3ffbc7d8/gh-deploy-clone.sh > /usr/local/bin/gh-deploy-clone
chmod +x /usr/local/bin/gh-deploy-clone

gh-deploy-clone user/repo

# You can also give it a name, in case
# you have multiple deploy targets:

gh-deploy-clone user/repo staging
0
blvz