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 discontinuó el 2021-03-02. 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.

Acerca de las autoridades de certificación de SSH

Con una autoridad de certificación de SSH, tu cuenta de empresa u organización puede ofrecer certificados SSH que los miembros pueden usar para aceder a tus recursos con Git.

El soporte para las autoridades con certificado SSH se encuentra disponible con GitHub Enterprise Cloud y Servidor de GitHub Enterprise 2.19+. Para obtener más información, consulta la sección "Productos de GitHub".

Un certificado SSH es un mecanismo para que una clave SSH firme otra clave SSH. Si usas una autoridad de certificación de SSH (CA) para ofrecerle a los miembros de tu organización certificados SSH firmados, puedes agregar la CA a tu cuenta de empresa u organización para permitirle a los miembros de la organización usar sus certificados para acceder a los recursos de la organización. Para obtener más información, consulta Administrar las autoridades de certificación de SSH de tu organización ".

Una vez que agregas una CA de SSH a tu cuenta de empresa u organización, puedes usar la CA para firmar certificados de SSH de clientes para los miembros de la organización. Los miembros de la organización pueden usar los certificados firmados para acceder a los repositorios de tu organización (y solo los repositorios de tu organización) con Git. Puedes solicitar a los miembros que usen certificados SSH para acceder a los recursos de la organización.

Por ejemplo, puedes crear un sistema interno que emita un nuevo certificado para tus programadores cada mañana. Cada programador puede usar su certificado diario para trabajar en los repositorios de tu organización en GitHub Enterprise. Al finalizar el día, el certificado puede expirar automáticamente, protegiendo tus repositorios si el certificado más tarde se ve comprometido.

Cuando emites cada certificado, debes incluir una extensión que especifique para qué usuario de GitHub Enterprise es el certificado. Por ejemplo, puedes usar el comando ssh-keygen de OpenSSH, reemplazando KEY-IDENTITY por tu identidad de clave y USERNAME por un nombre de usuario de GitHub Enterprise:

$ ssh-keygen -s ./ca-key -I KEY-IDENTITY -O extension:login@github.com=USERNAME ./user-key.pub

Para emitir un certificado para alguien que tiene diferentes nombres de usuario para Servidor de GitHub Enterprise y GitHub Enterprise Cloud, puedes incluir dos extensiones de inicio de sesión.

$ ssh-keygen -s ./ca-key -I KEY-IDENTITY -O extension:login@github.com=CLOUD-USERNAME extension:login@HOSTNAME=SERVER-USERNAME ./user-key.pub

Puedes restringir las direcciones IP desde las que un miembro de la organización puede acceder a los recursos de tu organización usando una extensión source-address. La extensión acepta una dirección IP específica o una gama de direcciones IP con la notación CIDR. Puedes especificar múltiples direcciones o rangos separando los valores con comas. Para obtener más información, consulta "Enrutamiento entre dominios sin clases" en Wikipedia.

$ ssh-keygen -s ./ca-key -I KEY-IDENTITY -O extension:login@github.com=USERNAME -O source-address=COMMA-SEPARATED-LIST-OF-IP-ADDRESSES-OR-RANGES ./user-key.pub

Los miembros de la organización pueden usar sus certificados firmados para la autenticación, incluso si has aplicado el inicio de sesión único de SAML. A menos que hagas que los certificados SSH sean un requisito, los miembros de la organización pueden seguir usando otros medios para la autenticación para acceder a los recursos de tu organización con Git, incluyendo sus nombre de usuario y contraseña, tokens de acceso personales y sus propias claves SSH.

Para evitar errores de autenticación, los miembros de la organización deben usar una URL especial que incluya el ID de la organización para clonar los repositorios mediante certificados firmados. Cualquier persona con acceso de lectura al repositorio puede buscar esta URL en la página del repositorio. Para obtener más información, consulta "Clonar un repositorio".