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

94

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:

git  github  ssh 
— David Ebbo
fuente
Dado que no hay mejor manera, hemos creado un usuario de implementación dedicado a quien le estamos otorgando acceso de solo lectura a los repositorios. El resultado final es el mismo.
— Datageek
Excelente respuesta aquí: stackoverflow.com/questions/11656134/…
— apple16

Respuestas:

22

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.
— VonC
fuente
53
GitHub admite claves públicas de nivel de cuenta y claves de nivel de proyecto (también conocidas como claves de implementación). No permitir la reutilización de claves de nivel de cuenta tiene sentido, pero afirmo que no permitirlo para Deploy Keys no lo tiene. Mi única clave de nivel de cuenta permite el acceso a todos mis proyectos, entonces, ¿por qué no podría tener una clave de implementación que permita el acceso a algunos de mis proyectos? Es solo más restrictivo y no crea ninguna preocupación que pueda ver. Su preocupación sobre la posibilidad de que dos usuarios diferentes compartan la misma clave ssh no aparece en la imagen en ese escenario.
— David Ebbo
@DavidEbbo Puede que no aparezca en la imagen, pero esa preocupación (dos usuarios diferentes para compartir la misma clave ssh) es la razón principal por la que una clave ssh no se comparte.
— VonC
21
Me temo que no sigo tu razonamiento aquí. Estoy preguntando sobre un escenario muy específico (use una clave de implementación en varios proyectos), y su argumento para que no sea posible es mostrar un escenario no relacionado (dos usuarios que comparten claves ssh). Siguiendo exclusivamente con el escenario Deploy Key, ¿cuál sería el negativo de que github lo permitiera?
— David Ebbo
6
@DavidEbbo Siguiendo help.github.com/articles/managing-deploy-keys , ninguno de los tres métodos (Cuenta, Implementación o Cuentas de máquina) implica compartir una clave SSH privada para acceder a dichos repositorios. Apegarse exclusivamente al escenario Deploy Key, ya que es una clave en el servidor , para que sea válida en varios repositorios significaría compartir (o replicar) una clave privada en varios repositorios. Eso disminuye el aspecto de la autenticación y, si la clave se ve comprometida, aumenta la cantidad de repositorios expuestos.
— VonC
8
gracias, esa página tiene información interesante. Marcaré su respuesta como la respuesta en uno o dos días si no veo nada más, aunque para ser honesto, todavía no estoy convencido por el argumento. Tener una clave de implementación utilizada en dos repositorios no es más débil que usar una clave de máquina que tiene acceso al mismo conjunto de repositorios.
— David Ebbo
11

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.

— Jens Finkhaeuser
fuente
1
Je. Es un poco gracioso cómo se rechaza esto, cuando es más correcto que la respuesta aceptada. Literalmente, no hay nada en esto que impida compartir una clave con varios usuarios.
— Jens Finkhaeuser
2

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 .

— Zhro
fuente
1
No me convence esta explicación. ¿En qué se diferencia fundamentalmente de permitir que un usuario acceda a varios repositorios, lo que obviamente está permitido? Si ya no confiaba en ese usuario, tendría que eliminarlo de cada repositorio.
— David Ebbo
@David: How is that fundamentally different from allowing one user to access multiple repositories, which is obviously allowed¿Puedes explicar esto con más detalle ? Solo tengo una cuenta de desarrollador y veo que puede agregar claves ssh para el acceso de toda la cuenta (una clave para todos los repositorios) o agregar claves de implementación individuales (una clave para cada repositorio). Esta sigue siendo una relación de uno a varios o uno a uno en la que la revocación de la clave "uno" revoca el acceso a "todos" en ambos casos.
— Zhro
Para aclarar aún más, no hay oportunidad (lo que puedo decir) de asignar accidentalmente una clave en una relación de muchos a uno donde el acceso puede existir en otro lugar después de haber sido revocado. Esta parece ser la motivación de GitHub para esta restricción, pero solo supongo.
— Zhro
De la forma en que veo las cosas, las claves de implementación son un poco como 'usuarios anónimos' que no tienen una cuenta completa, pero aún representan algún tipo de identidad. La diferencia es que en el caso de la cuenta, usted da acceso a la cuenta, que indirectamente da acceso a todas las claves ssh en esa cuenta. Mientras está en el caso de Implementar clave, omite la abstracción de la cuenta y da acceso directamente a la clave ssh. Pero más allá de eso, no veo que las necesidades de seguridad sean diferentes. Si la cuenta O el propietario de la clave de implementación se vuelve maligno, debe eliminarlos de cada repositorio.
— David Ebbo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.