Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Esta versión de GitHub Enterprise se discontinuará el Esta versión de GitHub Enterprise se discontinuó el 2020-08-20. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Versión del artículo: Enterprise Server 2.18

Administrar las llaves de despliegue

Aprende las diversas formas de administrar llaves SSH en tus servidores cuando automatizas los scripts de desplegue y averigua qué es lo mejor para ti.

En este artículo

Puedes administrar llaves SSH en tus servidores cuando automatices tus scripts de despliegue utilizando el reenvío del agente de SSH, HTTPS con tokens de OAuth, o usuarios máquina.

Reenvío del agente SSH

En muchos casos, especialmente al inicio de un proyecto, el reenvío del agente SSH es el método más fácil y rápido a utilizar. El reenvío de agentes utiliza las mismas llaves SSH que utiliza tu ordenador de desarrollo local.

Pros
  • No tienes que generar o llevar registros de las llaves nuevas.
  • No hay administración de llaves; los usuarios tienen los mismos permisos en el servidor y localmente.
  • No se almacenan las llaves en el servidor, así que, en caso de que el servidor se ponga en riesgo, no necesitas buscar y eliminar las llaves con este problema.
Contras
  • Los usuarios deben ingresar cno SSH para hacer los despliegues; no pueden utilizarse los procesos de despliegue automatizados.
  • El reenvío del agente SSH puede ser difícil de ejecutar para usuarios de Windows.
Configuración
  1. Habilita el reenvío de agente localmente. Consulta nuestra guía sobre el redireccionamiento del agente SSH para obtener más información.
  2. Configura tus scripts de despliegue para utilizar el reenvío de agente. Por ejemplo, el habilitar el reenvío de agentes en un script de bash se vería más o menos así: ssh -A serverA 'bash -s' < deploy.sh

Clonado de HTTPS con tokens de OAuth

Si no quieres utilizar llaves SSH, puedes utilizar HTTPS con tokens de OAuth.

Pros
  • Cualquiera que tenga acceso al servidor puede desplegar el repositorio.
  • Los usuarios no tienen que cambiar su configuración local de SSH.
  • No se necesitan tokens múltiples (uno por usuario); un token por servidor es suficiente.
  • Los tokens se pueden revocar en cualquier momento, convirtiéndolos esencialmente en una contraseña de un solo uso.
  • Se puede generar nuevos tokens con scripts si se utiliza la API de OAuth.
Contras
  • Debes asegurarte de que configuras tu token con los alcances de acceso correctos.
  • Los tokens son prácticamente contraseñas, y deben protegerse de la misma manera.
Configuración

Consulta nuestra guía sobre la automatización de tokens en Git.

Llaves de implementación

Puedes lanzar proyectos desde un repositorio de GitHub Enterprise hacia tu servidor al utilizar una llave de despliegue, la cual es una llave SSH que otorga acceso a un repositorio específico. GitHub Enterprise adjunta la parte pública de la llave directamente en tu repositorio en vez de hacerlo a una cuenta de usuario, y la parte privada de ésta permanece en tu servidor. Para obtener más información, consulta la sección "Entregar despliegues".

Las claves de despliegue con acceso de escritura pueden llevar a cabo las mismas acciones que un miembro de la organización con acceso administrativo o que un colaborador en un repositorio personal. Para obtener más información, consulta las secciones "Niveles de permiso en los repositorios para una organización" y "Niveles de permiso para un repositorio de una cuenta de usuario".

Pros
  • Cualquiera que tenga acceso al repositorio y al servidor tiene la capacidad de desplegar el proyecto.
  • Los usuarios no tienen que implementar la configuración local de SSH.
  • Las llaves de despliegue son de solo lectura predeterminadamente, pero les puedes otorgar acceso de escritura cuando las agregas a un repositorio.
Contras
  • Las llaves de despliegue solo otorgan acceso a un solo repositorio. Los proyectos más complejos pueden tener muchos repositorios que extraer del mismo servidor.
  • Las llaves de lanzamiento habitualmente no están protegidas con una frase de acceso, lo cual hace que se pueda acceder fácilmente a ellas si el servidor estuvo en riesgo.
Configuración
  1. Ejecuta el procedimiento de ssh-keygen en tu servidor, y recuerda en donde guardaste el par de llaves pública/privada de rsa.
  2. En la esquina superior derecha de cualquier página de GitHub Enterprise, da clic en tu foto de perfil y luego da clic en Tu perfil.
    Navegación al perfil
  3. En tu página de perfil, da clic en Repositorios y luego en el nombre de tu repositorio.
    Enlace de los repositorios
  4. Desde tu repositorio, da clic en Configuración.
    Configuración del repositorio
  5. En la barra lateral, da clic en Desplegar llaves y luego en Agregar llave de despliegue.
    Enlace para agregar llaves de despliegue
  6. Proporciona un título, pégalo en tu llave pública.
    Página de la llave de despliegue
  7. Selecciona Permitir acceso de escritura si quieres que esta llave tenga acceso de escritura en el repositorio. Una llave de despliegue con acceso de escritura permite que un despliegue cargue información al repositorio.
  8. Da clic en Agregar llave.

Usuarios máquina

Si tu servidor necesita acceder a repositorios múltiples, puedes crear una nueva cuenta de GitHub Enterprise y adjuntar una llave SSH que se utilizará exclusivamente para fines de automatización. Ya que ninguna persona utilizará esta cuenta de GitHub Enterprise, se le llama usuario máquina. Puedes agregar el usuario máquina como colaborador en un repositorio personal (otorgándole acceso de lectura y escritura), como un colaborador externo en el repositorio de una organización (otorgándole acceso de lectura, escritura y administrador), o a un equipo con acceso a los repositorios que necesite para la automatización (otorgándole los permisos del equipo).

Pros
  • Cualquiera que tenga acceso al repositorio y al servidor tiene la capacidad de desplegar el proyecto.
  • No se necesitan usuarios (humanos) para cambiar su configuración local de SSH.
  • No se necesitan llaves múltiples; una por servidor está bien.
Cons
  • Únicamente las organizaciones pueden restringir a los usuarios máquina para que tengan acceso de solo lectura. Los repositorios personales siempre otorgan a los colaboradores acceso de lectura/escritura.
  • Las llaves de los usuarios máquina, tal como las llaves de despliegue, a menudo no se encuentran protegidas con una frase de acceso.
Configuración
  1. Ejecuta el procedimiento de ssh-keygen en tu servidor y adjunta la llave pública a la cuenta del usuario máquina.
  2. Otorga a la cuenta del usuario máquina el acceso a los repositorios que quieras automatizar. Puedes hacer esto si agregas la cuenta como un colaborador, como un colaborador externo, o a un equipo en una organización.

Pregunta a una persona

¿No puedes encontrar lo que estás buscando?

Contáctanos