Administrar las llaves de despliegue

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.

Ventajas de usar el reenvío del agente SSH

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.

Desventajas de usar el reenvío del agente SSH

Los usuarios deben utilizar SSH para la implementación; no se pueden usar procesos de implementación automatizados.
El reenvío del agente SSH puede ser difícil de ejecutar para usuarios de Windows.

Configurar el reenvío del agente SSH

Habilita el reenvío de agente localmente. Vea nuestra guía sobre el reenvío de agentes SSH para más información.
Configura tus scripts de despliegue para utilizar el reenvío de agente. Por ejemplo, en un script de Bash, la habilitación del reenvío de agentes tendría un aspecto similar al siguiente: 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.

Ventajas del clonado de HTTPS con tokens de OAuth

Cualquiera que tenga acceso al servidor puede desplegar el repositorio.
Los usuarios no tienen que implementar la 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.
La generación de nuevos tokens se puede incluir fácilmente en un script mediante la API de OAuth.

Desventajas del clonado de HTTPS con tokens de OAuth

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.

Configurar el clonado de HTTPS con tokens de OAuth

Consulta nuestra guía sobre la creación de personal access token.

Claves de implementación

Puedes iniciar proyectos hacia tu servidor desde un repositorio de tu instancia de GitHub Enterprise Server utilizando una clave de implementación, que es una clave SSH que otorga acceso a un único repositorio. GitHub Enterprise Server adjunta la parte pública de la llave directamente en tu repositorio en vez de hacerlo a una cuenta personal, mientras que la parte privada de la clave permanece en tu servidor. Para obtener más información, vea «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, vea «Roles de repositorio para una organización» y «Niveles de permisos para un repositorio de una cuenta personal».

Ventajas de las claves de implementación

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 claves de implementación son de solo lectura de forma predeterminada, pero puede darles acceso de escritura al agregarlas a un repositorio.

Desventajas de las claves de implementación

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.
Si el usuario que creó la clave de implementación se quita del repositorio, la clave de implementación seguirá estando activa, ya que no está vinculada al usuario específico, sino al repositorio.

Configuración de las claves de implementación

Ejecuta el procedimientossh-keygen en el servidor y recuerda dónde guardas el par de claves RSA públicas y privadas generado.
En tu instancia de GitHub Enterprise Server, navega a la página principal del repositorio.
En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.
En la barra lateral, haz clic en Claves de implementación.
Haz clic en Agregar clave de implementación.
En el campo "Título", proporciona un título.
En el campo "Clave", pega tu clave pública.
Seleccione Allow write access si quiere que esta clave tenga acceso de escritura en el repositorio. Una llave de despliegue con acceso de escritura permite que un despliegue cargue información al repositorio.
Haga clic en Add key.

También puedes usar la API de REST para crear claves de implementación. Para obtener más información, vea «Puntos de conexión de la API de REST para claves de implementación».

Utilizar repositorios múltiples en un servidor

Si utilizas repositorios múltiples en un servidor, necesitarás generar un par de llaves dedicados para cada uno. No puedes reutilizar una llave de despliegue para repositorios múltiples.

En el archivo de configuración SSH del servidor (habitualmente ~/.ssh/config), agregue una entrada de alias para cada repositorio. Por ejemplo:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

Host my-GHE-hostname.com-repo-0: alias del repositorio.
Hostname my-GHE-hostname.com: configura el nombre de host que se va a usar con el alias.
IdentityFile=/home/user/.ssh/repo-0_deploy_key: asigna una clave privada al alias.

Entonces podrás utilizar el alias del nombre de host para que interactúe con el repositorio utilizando SSH, lo cual utilizará la llave de despliegue única que se asignó a dicho alias. Por ejemplo:

git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Tokens de acceso de instalación de GitHub App

Si el servidor tiene que acceder a repositorios en una o más organizaciones, puede usar GitHub App para definir el acceso necesario y, luego, generar tokens de acceso de instalación de ámbito limitado desde esa GitHub App. Se puede ajustar el alcance de los tokens de acceso de instalación para repositorios múltiples y pueden tener permisos específicos. Por ejemplo, puedes generar un token con acceso de solo lectura al contenido de un repositorio.

Ya que las GitHub Apps son un actor de primera clase en GitHub Enterprise Server, los tokens de acceso de instalación se desacoplan de cualquier usuario de GitHub, lo cual los hace comparables con los "tokens de servicio". Adicionalmente, los tokens de acceso de instalación tienen límites de tasa dedicados que se escalan de acuerdo con el tamaño de las organizaciones sobre las cuales actúan. Para más información, vea Límites de frecuencia para GitHub Apps.

Ventajas de los tokens de acceso de instalación

Tokens de alcance muy específico con conjuntos de permisos bien definidos y tiempos de vencimiento (1 hora o menos si se revocan manualmente utilizando la API).
Límites de tasa dedicados que crecen con tu organización.
Desacoplado de identidades de usuario de GitHub, por lo que no consumen ningún puesto con licencia.
Nunca se les otorga una contraseña, así que no se puede iniciar sesión directamente en ellos.

Desventajas de los tokens de acceso de instalación

Se necesita una configuración adicional para crear GitHub App.
Los tokens de acceso de instalación expiran después de 1 hora, por lo que necesitan volver a generarse habitualmente cuando se necesiten utilizando código.

Configuración de los tokens de acceso de instalación

Determina si GitHub App debe ser pública o privada. Si GitHub App solo actúa en los repositorios dentro de tu organización, probablemente la quieras como privada.
Determina los permisos que necesita tu GitHub App, tales como el acceso de solo lectura al contenido del repositorio.
Crea tu GitHub App a través de la página de configuración de tu organización. Para obtener más información, consulta Creación de una GitHub App.
Anota tu id de la GitHub App.
Genera y descarga la llave privada de tu GitHub App y almacénala de forma segura. Para más información, vea Generación de una clave privada.
Instala tu GitHub App en los repositorios sobre los que necesita actuar, opcionalmente, puedes instalar GitHub App en todos los repositorios de tu organización.
Identifica el valor installation_id que representa la conexión entre la GitHub App y los repositorios de la organización a los que puede acceder. Cada par de GitHub App y organización tiene como máximo un único installation_id. Puede identificar este valor installation_id mediante la Obtención de una instalación de la organización para la aplicación autenticada. Esto requiere autenticarse como GitHub App con JWT, para más información consulta Autenticación como GitHub App.
Genere un token de acceso de instalación mediante el punto de conexión de la API de REST correspondiente, Crear un token de acceso de instalación para una aplicación. Para esto es necesario autenticase como GitHub App mediante un JWT. Para más información, consulta Autenticación como GitHub App y Autenticación como una instalación.
Use este token de acceso de instalación para interactuar con tus repositorios, ya sea a través de la API de REST o de GraphQL, o mediante el cliente de Git.

Para obtener más información, vea «Generación de un token de acceso de instalación para una aplicación de GitHub».

Usuarios máquina

Si tu servidor necesita acceso a varios repositorios, puedes crear una cuenta nueva en tu instancia de GitHub Enterprise Server y adjuntar la clave SSH que se utilizará exclusivamente para la automatización. Dado que esta cuenta en tu instancia de GitHub Enterprise Server no la usará una persona, se denomina usuario de máquina. Puede agregar el usuario de máquina como colaborador en un repositorio personal (y conceder acceso de lectura y escritura), como colaborador externo en un repositorio de la organización (y conceder acceso de lectura, escritura o administrador), o bien a un equipo con acceso a los repositorios que necesita automatizar (y conceder los permisos del equipo).

Ventajas de los usuarios de máquina

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.

Desventajas de los usuarios de máquina

Ú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 de usuarios de máquina

Ejecute el procedimiento ssh-keygen en el servidor y adjunte la clave pública a la cuenta de usuario de máquina.
Otorga a la cuenta del usuario máquina el acceso a los repositorios que quieras automatizar. Para ello, agregue la cuenta como colaborador, como colaborador externo o a un equipo de una organización.

Información adicional

Configuración de notificaciones

Administrar las llaves de despliegue

En este artículo