Uso de la directiva IdentityFile en ssh_config cuando AgentForwarding está en uso

¿Es posible especificar claves reenviadas utilizando la directiva IdentityFile en .ssh / config?

Me encontré con esta peculiaridad cuando intentaba implementar algún código a través de Capistrano / GIT en nuestro servidor de producción. Tanto mi clave GIT personal como la de mi trabajo siempre se cargan en mi agente SSH y sucedió que mi clave personal se agregó primero al agente. Utilizo el reenvío de agentes al implementar con Capistrano, por lo que cuando el host intentó autenticar la operación `git pull` falló con el siguiente error:

ERROR: Permiso a `algún repositorio` denegado a` su usuario`.

porque intentó autenticarse usando mi clave git personal antes de probar la clave apropiada (que vino más tarde en el agente ssh) y asumió que estaba accediendo a un repositorio extranjero al que no tengo permiso de acceso. Potencialmente, puedo dar acceso a mi usuario personal a cada repositorio de trabajo, pero en mi máquina local puedo solucionar este problema definiendo dominios personalizados en .ssh / config de la siguiente manera:

Host personal.github.com Nombre de
host github.com
Usuario git
IdentityFile ~ / .ssh / some_key

Host work.github.com Nombre de
host github.com
Usuario git
IdentityFile ~ / .ssh / some_other_key

y de esta manera git nunca se confunde. ¿Es posible crear reglas .ssh / config para las claves reenviadas en mis cuadros de producción para que siempre sepan qué clave usar al extraer un código nuevo? Básicamente quiero poder hacer:

Host work.github.com Nombre de
host github.com
Usuario git
IdentityFile some_forwards_key

¡Gracias!

— skryl
fuente

Puede usar la parte pública de una clave para especificar qué clave privada desea usar del agente reenviado. Esto requiere crear un archivo adicional (la parte pública de la clave) en cualquier máquina "intermedia" (máquinas a las que reenvíe su agente ssh local ).

Haga los arreglos para que la máquina intermedia tenga una copia de la parte pública de la clave deseada en una ubicación conveniente (por ejemplo ~/.ssh/some_other_key.pub).

Desde cualquier máquina que ya tenga la parte pública de la clave:
```
scp some_other_key.pub intermediate:.ssh/
```
o, en la máquina intermedia:
```
ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
```
Es posible que desee editar la parte de "comentario" final de la clave pública para identificar mejor el origen / propietario / propósito de la clave (o intentar ocultar la misma).
Utilice la ruta de acceso al archivo de clave pública anterior con -io IdentityFile.
También es posible que deba usar IdentitiesOnly yes(en .ssh/configo -o) para evitar que ssh intente ofrecer identidades adicionales de su agente reenviado.

— Chris Johnsen
fuente

Esto es lo único que me ha funcionado de otras 10 soluciones.

— Tracy Fu

Jugando con esto, me di cuenta de que si coloca la clave pública asociada con la clave privada que desea usar en ~ / .ssh / id_rsa.pub en la máquina intermedia, se usará de manera predeterminada, no es necesario realizar ninguna configuración en ~ / .ssh / config.

— bschlueter

Gracias Chris y bschlueter! Ahora me conecto con: ssh someserver -t "ssh-add -L | grep something_unique> ~ / .ssh / id_rsa.pub; cd some / other / folder; bash --login"

— blablabla

Cuando intento esto con ssh -v -T ...el servidor acepta la clave pública, pero luego ssh dice No such identity: /home/name/.ssh/id_rsa: No such file or directoryy posteriormente la autenticación falla. Tengo ForwardAgent habilitado en todas mis configuraciones. ¿Cual podría ser el problema?

— Lars Nyström