¿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 git@github.com 2>&1 | grep Offering

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.

ssh ssh-agent

— danmichaelo
fuente

Respuestas:

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

— kasperd
fuente

Para su información, el nombre de la clave pública no importa. Seleccionará la clave adecuada del agente en función del contenido.

— akostadinov

@akostadinov Verdadero. Si señala sshun archivo de clave pública sin un archivo de clave privada asociado, solo debe leer la clave pública del archivo y hacer que el agente use la clave privada correspondiente para generar la firma.

— kasperd el

¡Esto efectivamente guarda su clave en el host B! Consulte la respuesta a continuación de @ mc0e para obtener una solución que no guarda la clave en el servidor.

— Pitt

@ Pitt No, no lo hace. Solo almacena la clave pública . Y eso no es un problema, ya que nunca se esperaba que la clave pública se mantuviera en secreto en primer lugar. El reenvío de agente le da acceso al host para usar la clave siempre que el reenvío del agente esté en su lugar, pero el agente nunca enviará la clave secreta a ninguna parte.

— kasperd

@kasperd, no necesita una copia real de la clave privada mientras tiene una conexión en vivo a un agente de usuario con la clave. Como root, puede acceder a las conexiones del agente de otros usuarios registrados.

— mc0e

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.

— mc0e
fuente

Según el comentario de @ kasperd sobre su respuesta: "no lo hace. Solo almacena la clave pública. Y eso no es un problema ya que nunca se esperaba que la clave pública se mantuviera en secreto en primer lugar. El reenvío de agentes le da acceso al host a use la clave mientras el reenvío del agente esté en su lugar, pero el agente nunca enviará la clave secreta a ninguna parte "

— Bdoserror

@Bdoserror Como root, puede abusar de la conexión ssh-agent mientras el usuario asociado está conectado. Simplemente copie las SSH_*variables de entorno e inicie sesión donde quiera que vaya usando la clave, a pesar de no tener una copia real.

— mc0e

Para aclarar: esta respuesta es realmente incorrecta, aunque el escenario de abuso de mc0e es real, no tiene nada que ver con guardar la clave pública; si el host intermedio se ve comprometido, su conexión de agente se puede utilizar para autenticar con su clave privada, independientemente de si guarda la clave pública en el host intermedio o no. Su clave privada no se verá comprometida, y guardar la clave pública no lo hará más fácil, ya que cualquier atacante que tenga una conexión con el agente puede pedirle las claves públicas de todos modos.

— Restablece a Mónica el

@ marc-lehmann releyó lo que escribí. Si reenvía las teclas, estarán expuestas, pero puede limitar qué teclas se reenvían.

— mc0e

Sigo lo que escribiste. Por favor, aborda la esencia de nuestros comentarios, no la persona. El problema es que su respuesta es simplemente incorrecta porque supone, a medida que escribe, que las claves "se reenvían" al host remoto. No ocurre tal cosa, y las claves en sí no están expuestas.

— Restablece a Mónica el