¿Utiliza una clave reenviada específica del agente SSH?

Digamos que tengo una clave para Github, junto con otras claves. He agregado muchas claves a mi agente ssh ( ssh-add -Ldevuelve muchas líneas) en la computadora de mi casa A. En mi .ssh/confighe configurado qué clave usar con qué host, por ejemplo

ssh -T -vvv [email protected] 2>&1 | grep Offering

da

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Solo se ofrece una clave, como se esperaba. Pero luego, pasando a algún host B con ForwardAgent yesy repitiendo el mismo comando, obtengo

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

lo que significa que prueba todas mis llaves. Esto es problemático ya que solo se puede probar un número limitado de claves antes de que los servidores regresen Too many authentication failures. Así que intenté editar .ssh/configen el host B para incluir

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

pero luego no recibo ofertas clave, sino más bien

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

lo que supongo que significa que no se encontró la clave (?) Y después de todo, la clave se encuentra en la computadora A de mi casa, no en el host B, por lo que la pregunta es cómo hacer referencia a ella en el host B. Espero haber logrado explicar la pregunta.

Tienes la idea correcta. La única parte que falta es que el archivo señalado por IdentityFiledebe existir. No necesita contener una clave privada, basta con tener disponible la clave pública.

En el host B, puede extraer la clave pública del agente escribiendo ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.puby luego apuntar a ese archivo desde~/.ssh/config

Buena respuesta de @Kasperd, pero tenga en cuenta también que si el Host B se ve comprometido, o si no confía en todos aquellos con privilegios de root allí, aún está exponiendo todas sus claves al abuso durante el tiempo que esté conectado en ese host.

Entonces, un mejor enfoque podría ser solo reenviar el acceso a las claves que necesita. Quizás intente con los ssh-agent-filterrepositorios de Debian / Ubuntu, o desde github .

EDIT: Me he decidido por ssh-identmás que ssh-agent-filterpara la transmisión de las claves de forma selectiva, aunque no es tan suave como una experiencia que uno podría esperar.