Utilisation de plusieurs clés publiques SSH

J'ai un compte personnel et un compte d'entreprise sur Unfuddle. Les clés SSH ne peuvent être utilisées que sur un seul compte. Je dois donc créer une clé SSH séparée sur mon ordinateur portable pour les deux comptes. J'ai couru ssh-keygen -t rsapour générer deux clés avec des noms différents (Personal est le nom par défaut et la société est {company} _rsa). Le problème maintenant, c’est qu’il semble que ma clé par défaut soit utilisée partout et que je ne sois pas en mesure de spécifier une clé à utiliser dans Git pour des pensions individuelles.

Ma question est donc la suivante: comment puis-je spécifier une clé SSH à utiliser sur une base repo-repo?

J'ai configuré mon ssh_config (~ / .ssh / config) mais cela ne semble toujours pas fonctionner.

config:

Host {personalaccount}.unfuddle.com
     HostName {personalaccount}.unfuddle.com
     User git
     IdentityFile /Users/dave/.ssh/id_rsa

Host {companyaccount}.unfuddle.com
     HostName {companyaccount}.unfuddle.com
     User git
     IdentityFile /Users/dave/.ssh/cage_rsa

Mon fichier de configuration de référentiel Git pour un référentiel sur le compte vide de ma société se présente comme suit:

[remote "origin"]
     url = git@{companyaccount}.unfuddle.com:{companyaccount}/overall.git
     fetch = +refs/heads/*:refs/remotes/origin/*

Donc je ne suis pas sûr s'il y a quelque chose qui ne va pas avec ma config ssh ou ma config git.

Si vous avez un agent ssh actif avec votre id_rsaclé chargée, le problème est probablement que ssh offre cette clé en premier. Unfuddle l'accepte probablement pour l'authentification (par exemple, dans sshd ) mais le refuse pour l'autorisation d'accéder aux référentiels de la société (par exemple, quel que soit le logiciel interne utilisé pour l'autorisation, possiblement quelque chose qui s'apparente à Gitolite). Peut-être y a-t-il un moyen d'ajouter votre clé personnelle au compte de l'entreprise (plusieurs personnes ne partagent pas les mêmes corp_rsafichiers de clés publique et privée, n'est-ce pas?).

Le IdentitiesOnly .ssh/configmot-clé de configuration peut être utilisé pour limiter les clés que ssh offre au sshd distant uniquement à celles spécifiées via des IdentityFilemots-clés (c.-à-d. Qu'il refusera d'utiliser des clés supplémentaires chargées d'être chargées dans un ssh-agent actif ).

Essayez ces .ssh/configsections:

Host {personalaccount}.unfuddle.com
     IdentityFile ~/.ssh/id_rsa
     IdentitiesOnly yes

Host {companyaccount}.unfuddle.com
     IdentityFile ~/.ssh/{companyaccount}_rsa
     IdentitiesOnly yes

Ensuite, utilisez les URL Git comme celles-ci:

git@{personalaccount}.unfuddle.com:{personalaccount}/my-stuff.git
git@{companyaccount}.unfuddle.com:{companyaccount}/their-stuff.git

Si vous souhaitez tirer pleinement parti du .ssh/configmécanisme, vous pouvez fournir votre propre nom d'hôte personnalisé et modifier le nom d'utilisateur par défaut:

Host uf-mine
     HostName {personalaccount}.unfuddle.com
     User git
     IdentityFile ~/.ssh/id_rsa
     IdentitiesOnly yes

Host uf-comp
     HostName {companyaccount}.unfuddle.com
     User git
     IdentityFile ~/.ssh/{companyaccount}_rsa
     IdentitiesOnly yes

Ensuite, utilisez les URL Git comme celles-ci:

uf-mine:{personalaccount}/my-stuff.git
uf-comp:{companyaccount}/their-stuff.git

man ssh_config

Quelque chose comme

Host personal_repo
  User personal
  IdentityFile .ssh/personal_rsa

Host company_repo
  User company
  IdentityFile .ssh/company_rsa

Et utilisez-le personal_repocomme hôte dans votre dépôt Git.

IdentityFile et IdentitiesOnly fonctionnent bien. Ce qui me dérange, c’est que je dois penser à utiliser différents noms d’hôtes pour la connexion et au fait que la connexion de l’agent transféré conserve toutes les clés, ce qui signifie que si l’hôte distant est compromis, ils peuvent utiliser n’importe laquelle de mes identités pendant que je suis en poste. .

J'ai récemment commencé à utiliser:

https://github.com/ccontavalli/ssh-ident

c'est un wrapper autour de ssh, ça:

• conserve un agent entièrement distinct pour chaque identité que vous définissez.
• partage automatiquement les agents entre les sessions de connexion, rien à faire dans votre .bashrc.
• charge l'agent et les clés correspondantes à la demande la première fois que vous en avez besoin.
• détermine quel agent utiliser en fonction de la ligne de commande ssh (nom d'hôte, etc.) ou de votre répertoire de travail actuel. Ceci est particulièrement utile car j'ai tendance à travailler à partir de différents chemins en fonction de ce que je fais.

Voici une manière appropriée si vous voulez utiliser l'agent ssh:

# Create public keys to make sure they exist
# this is a must if you use ssh agent forwarding
# or want to use ssh-agent at all
ssh-add -L | grep personal > ~/.ssh/personal_identity.pub
ssh-add -L | grep company > ~/.ssh/company_identity.pub


# Add to ~/.ssh/config
Host {personalaccount}.unfuddle.com
  IdentityFile ~/.ssh/personal_identity.pub

Host {companyaccount}.unfuddle.com
  IdentityFile ~/.ssh/company_identity.pub

Explication: si vous avez une clé privée dans votre répertoire ~ / .ssh, ssh-agent ne sera pas utilisé. Nous créons donc une clé publique sous un autre nom, de sorte que ssh est obligé d'utiliser ssh-agent. Cela aide également si vous n’avez pas accès aux clés privées (par exemple, le transfert d’agent ssh)