administrando claves públicas ssh en repositorios de organizaciones github

Question

Me preguntaba si alguien tiene una forma buena, limpia y segura de administrar el acceso al repositorio de la organización github en sus servidores?

Parece que solo puede adjuntar claves de pub a su cuenta personal y no puede restringir el acceso únicamente a una organización.

Tenemos un servidor beta donde colocamos múltiples proyectos para implementar claves, ya que necesitan ser únicos, no son ideales. Sería bueno dar acceso global a la organización, pero no quiero dar acceso completo a mi cuenta personal al servidor, del que tenemos trabajadores independientes (El servidor tiene acceso a la organización, lo cual es bueno, pero también a mis proyectos personales y a todas las demás organizaciones a las que pertenezco, lo cual es malo).

Las dos soluciones que veo son configurar un usuario github ficticio para pasar, lo que parece estúpido, o habilitar el reenvío de agente ssh, lo que se siente como un riesgo de seguridad (no soy el mejor administrador de servidor)

Un amigo sugirió configurar el servidor como un control remoto al que presionar, pero parece una solución de curita.

Me gustaría pensar que hay una forma más fácil de configurar el repositorio de una organización, ya que creo que sería una necesidad fundamental para todos.

Soy todo oídos si alguien quisiera compartir algo que tiene/está trabajando para su organización github.

Probablemente voy a romper la bala y crear un usuario dummy github y llamarlo un día, tengo que hacer el trabajo.

Answer 1

una alternativa a la respuesta de sergey_mo (y como una respuesta directa la pregunta final de Michał Szajbe) es la creación de múltiples claves ssh como se documenta por chalien en githib:

https://gist.github.com/jexchan/2351996

Answer 2

No entiendo por qué agregar una cuenta ficticia es tan mala para la implementación automática, siempre que ejecute su propio servidor beta como área de preparación antes de enviar a GitHub. Es decir, si quieres que el betacode sea privado.

El GitHub-way habitual sería agregar todos los colaboradores y simplemente tener un proyecto estable y un fork beta. Automáticamente extraerá la versión beta actual de su servidor beta para realizar pruebas (no se necesita ninguna clave ssh allí) y, si sus pruebas tienen éxito, obtendrá las fusiones del fork beta al proyecto estable.

Answer 3

Puede solucionar esto haciendo que sus aplicaciones sean ejecutadas por diferentes usuarios (un usuario por aplicación). Me refiero a los usuarios del servidor, no a los usuarios de github. De todos modos, es una buena práctica en servidores de aplicaciones múltiples.

Cada usuario tiene su propio par de llaves ssh, por lo que tiene muchas claves de implementación únicas (una por repo de github).

Utilizo este enfoque siempre que sea posible. Sin embargo, hay situaciones en las que un solo usuario ejecuta más de una aplicación y probablemente no se pueda hacer con las claves de despliegue de github. También estoy buscando una buena solución para tales casos.

Answer 4

pequeña nota sobre CI:
Por ejemplo, si se utiliza Jenkins y lo necesita para tener acceso a más de 1 proyecto tendrá que: 1.
añadir la clave pública a una cuenta de usuario github
2. complemento este usuario como propietario (para acceder a todos los proyectos) o como colaborador en cada proyecto.

Muchos claves públicas para un usuario del sistema no funcionará porque GitHub encontrará primera emparejados desplegar clave y enviará de vuelta error como "ERROR: El permiso para el usuario/repo2 negado a usuario/repo1"

http://help.github.com/ssh-issues/