Utilisation de la directive IdentityFile dans ssh_config lorsque AgentForwarding est en cours d'utilisation

Est-il possible de spécifier des clés transférées à l'aide de la directive IdentityFile dans .ssh / config?

J'ai rencontré cette bizarrerie en essayant de déployer du code via Capistrano / GIT sur notre serveur de production. Mes clés GIT personnelles et professionnelles sont toujours chargées dans mon agent SSH et il se trouve que ma clé personnelle a été ajoutée en premier à l'agent. J'utilise le transfert d'agent lors du déploiement avec Capistrano, donc lorsque l'hôte a tenté d'authentifier l'opération `git pull`, il a échoué avec l'erreur suivante:

ERREUR: Autorisation de `certains repo` refusée à` votre utilisateur`.

car il a tenté de s'authentifier à l'aide de ma clé git personnelle avant d'essayer la clé appropriée (qui est venue plus tard dans l'agent ssh) et a supposé que j'accédais à un référentiel étranger auquel je n'ai pas l'autorisation d'accéder. Je peux potentiellement donner à mon utilisateur personnel un accès à chaque dépôt de travail, mais sur ma machine locale, je peux contourner ce problème en définissant des domaines personnalisés dans .ssh / config comme suit:

Hôte personal.github.com
Nom d'hôte github.com
Utilisateur git
IdentityFile ~ / .ssh / some_key

Hôte work.github.com
Nom d'hôte github.com
User git
IdentityFile ~ / .ssh / some_other_key

et de cette façon, git ne se confond jamais. Est-il possible de créer des règles .ssh / config pour les clés transférées sur mes boîtes de production afin qu'elles sachent toujours quelle clé utiliser lors de l'extraction de nouveau code? Fondamentalement, je veux pouvoir faire:

Hôte work.github.com
Hostname github.com
User git
IdentityFile some_forwarded_key

Merci!

— skryl
source

Vous pouvez utiliser la partie publique d'une clé pour spécifier la clé privée que vous souhaitez utiliser à partir de l'agent transféré. Cela nécessite de créer un fichier supplémentaire (la partie publique de la clé) sur toutes les machines «intermédiaires» (machines vers lesquelles vous transférez votre agent ssh local ).

Faites en sorte que la machine intermédiaire ait une copie de la partie publique de la clé souhaitée dans un endroit pratique (par exemple ~/.ssh/some_other_key.pub).

Depuis n'importe quelle machine qui possède déjà la partie publique de la clé:
```
scp some_other_key.pub intermediate:.ssh/
```
ou, sur la machine intermédiaire:
```
ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
```
Vous souhaiterez peut-être modifier la partie «commentaire» de fin de la clé publique pour mieux identifier l'origine / le propriétaire / l'objectif de la clé (ou tenter de masquer la même chose).
Utilisez le chemin d'accès au fichier de clé publique ci-dessus avec -iou IdentityFile.
Vous devrez peut-être également utiliser IdentitiesOnly yes(dans .ssh/configou -o) pour empêcher ssh d'essayer de proposer des identités supplémentaires à partir de votre agent transféré.

— Chris Johnsen
source

C'est la seule chose qui a fonctionné pour moi à partir de 10 autres solutions.

— Tracy Fu

En jouant avec cela, j'ai réalisé que si vous mettez la clé publique associée à la clé privée que vous souhaitez utiliser dans ~ / .ssh / id_rsa.pub sur la machine intermédiaire, elle sera utilisée par défaut, pas besoin de configuration dans ~ / .ssh / config.

— bschlueter

Merci Chris et bschlueter! Je me connecte maintenant avec: ssh someserver -t "ssh-add -L | grep something_unique> ~ / .ssh / id_rsa.pub; cd some / other / folder; bash --login"

— blablabla

Lorsque j'essaie ceci avec ssh -v -T ...le serveur accepte la clé publique, mais ssh dit No such identity: /home/name/.ssh/id_rsa: No such file or directoryet par la suite l'authentification échoue. J'ai ForwardAgent activé dans toutes mes configurations. Quel pourrait être le problème?

— Lars Nyström