Usando la misma clave de implementación para múltiples proyectos de github

Github no permite que se use la misma clave de implementación ssh para más de un proyecto, lo que sería muy útil en algunos casos (por ejemplo, el servidor CI que se ocupa del proyecto con submódulos privados). He visto varios hilos que parecen decir que esta limitación existe por 'razones de seguridad', pero aún no he visto una explicación convincente sobre exactamente qué riesgo generaría.

Tenga en cuenta que el hecho de que Github no permita que las claves de nivel de cuenta se reutilicen tiene sentido (dos usuarios no deberían compartir claves). Es solo la restricción de las claves de implementación lo que estoy cuestionando.

Y para ser claro, estoy no buscando soluciones alternativas (crear un usuario simulado, utilizar varias claves, ...), pero sólo para una explicación plausible para esta limitación de Despliegue llaves.

Temas relacionados:

• Uno que muestra una solución
• Uno discutiendo el tema pero sin ir a ninguna parte

La única razón, ilustrada por la solución alternativa a la que hace referencia (crear un único usuario de "compilación" o compartir el mismo id_rsa.REPONAME.pubpor repositorio) es:

evitar compartir claves públicas / privadas para diferentes usuarios

Aunque ese no sería el caso en su situación (compile varios proyectos), permitir reutilizar la misma clave ssh abriría la posibilidad de que dos usuarios diferentes compartan la misma clave ssh, lo que anularía el propósito de autenticación .

Autenticación significa:
"el uso de una determinada clave ssh debería implicar que se supone que debe saber quién la está utilizando".

La página de GitHub " Administrar claves de implementación " detalla las distintas cuentas que usan ssh:

• Reenvío de agentes SSH : el reenvío de agentes usa las claves SSH ya configuradas en su máquina de desarrollo local cuando ingresa SSH a su servidor y ejecuta comandos git.
  Puede permitir de forma selectiva que los servidores remotos accedan a su ssh-agent local como si se estuviera ejecutando en el servidor.
  Por lo tanto, no es necesario replicar su clave privada en el servidor.

• Usuarios de máquinas : (esta es la estrategia de "cuenta ficticia") Adjunte la clave a una cuenta de usuario. Dado que esta cuenta no será utilizada por un humano, se llama usuario de máquina.
  Sin embargo, trataría a este usuario de la misma manera que lo haría con un humano, adjunte la clave a la cuenta de usuario de la máquina como si fuera una cuenta normal.
  Otorgue al colaborador de la cuenta o al equipo acceso a los repositorios a los que necesita acceder.
  Entonces, una clave privada asociada a un "usuario de máquina", una por servidor.

( DHa señala en los comentarios un número de límite de clave de implementación y el hecho de que solo puede tener una cuenta de usuario de máquina)

• Implementar clave (una por repositorio de GitHub) Clave SSH que se almacena en el servidor y otorga acceso a un único repositorio en GitHub.
  Esta clave se adjunta directamente al repositorio en lugar de a una cuenta de usuario .
  En lugar de ir a la configuración de su cuenta, vaya a la página de administración del repositorio de destino.
  Vaya a " Deploy Keys" y haga clic en " Add deploy key". Pegue la clave pública y envíela.

Esta vez, la clave ssh no está adjunta a un usuario (para el cual podría otorgar acceso a varios repositorios), sino a un repositorio.
Otorgar acceso ssh para varios repositorios sería equivalente a un "usuario de máquina".

En términos de autenticación :

• usar la misma clave para varios repositorios está bien cuando lo hace un usuario (que tiene dicha clave asociada a su cuenta)
• usar la misma clave para varios repositorios NO está bien cuando la clave está adjunta a un repositorio, porque no sabe en absoluto quién accedió a qué.
  Eso difiere del "usuario de la máquina" donde un "usuario" se declara como colaborador para muchos repositorios.
  Aquí (clave de implementación), no hay "colaborador" , solo un acceso ssh directo otorgado al repositorio.

Desafortunadamente, este es un escenario en el que github simplemente malinterpreta la distinción entre un par de claves y una cuenta o proyecto.

Dado que un par de claves se utiliza para autenticación y autorización, es efectivamente una identidad. Las cuentas de Github son otra identidad. La conexión de cuentas de github con pares de claves establece de manera efectiva un mapeo 1: N entre las identidades basadas en cuentas de github y las identidades de pares de claves.

Por el contrario, github impone un mapeo 1: N de proyectos a identidades basadas en pares de claves. La analogía del mundo real es que hay una puerta que da acceso al proyecto y que muchas personas diferentes pueden abrir. Pero una vez que alguno de ellos obtiene la llave de la puerta, no puede volver a obtener ninguna otra llave para ninguna otra puerta, nunca más.

Tiene sentido no reutilizar las claves a menudo desde la perspectiva de contener las infracciones si una clave se ve comprometida. Pero esa es solo una buena política de administración . No tiene mucho sentido evitar que una clave se use más de una vez por principio . Que hay algunas llaves para algunas puertas que nunca se reutilizan, bueno, nuevamente eso se debe a la política .

Una vista un poco más compleja es ilustrar pares de claves como roles . Puede poseer muchos pares de claves y, por lo tanto, ocupar muchos roles. La clave privada lo autentica para el rol.

La asignación de claves de implementación de Github en proyectos establece que un rol nunca puede abarcar más de una tarea. Eso rara vez es realista.

Ninguno de los cuales cambia lo que permite github, por supuesto.

Me tomó mucho pensar racionalizar las implicaciones y se me ocurrió este escenario.

Imagine que crea una única clave de implementación para un usuario que ha asignado a varios repositorios. Ahora desea revocar esa clave, pero se usa en varios lugares. Por lo tanto, en lugar de poder revocar todos los accesos, es posible que, sin darse cuenta, solo revoque el acceso parcial.

Esto puede parecer un beneficio, pero esta relación de muchos a uno es en realidad inherentemente insegura una vez que se considera el factor humano. Esto se debe a que no puede saber con certeza si realmente ha revocado todos los accesos sin inspeccionar cada repositorio y comparar cada clave pública individualmente en el caso de que haya olvidado dónde realmente la asignó.

Definitivamente es frustrante asignar y administrar tantas claves únicas, pero las implicaciones de seguridad son claras con la forma en que GitHub ha instituido su política: cuando revoca una clave, tiene la garantía de revocar todo el acceso otorgado por esa clave porque solo se usa en un lugar .