Acerca de las autoridades de certificación de SSH

Acerca de las autoridades de certificación de SSH

Un certificado SSH es un mecanismo para que una clave SSH firme otra clave SSH. Si usa una autoridad de certificación de SSH (CA) para ofrecerle a los miembros de su organización y a los colaboradores externos certificados SSH firmados, puede agregar la CA a su cuenta de empresa u organización para permitirle a estos colaboradores de la organización usar sus certificados para acceder a los recursos de la organización.

          GitHub usa certificados de usuario SSH con formato OpenSSH para autenticar las operaciones de Git a través de SSH validando la firma y los campos del certificado (incluido su período de validez) en una entidad de certificación (CA) SSH de confianza configurada en el nivel de organización o de empresa.

Una vez que agrega una CA de SSH a su cuenta de empresa u organización, puede usar la CA para firmar certificados de SSH de clientes para los miembros y colaboradores externos de la organización. Estos colaboradores de la organización pueden utilizar los certificados firmados para acceder a los repositorios de esa organización.

Los certificados agregados a su empresa conceden acceso a todas las organizaciones que pertenecen a su cuenta empresarial. Para más información, consulta Aplicar políticas sobre los ajustes de seguridad en tu empresa.

Puedes solicitar que los miembros usen certificados SSH para acceder a los recursos de la organización.

Opcionalmente, puede requerir que los miembros y colaboradores externos utilicen certificados SSH para acceder a los recursos de la organización. Para más información, consulta Administrar las autoridades de certificación SSH de tu organización y Aplicar políticas sobre los ajustes de seguridad en tu empresa.

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

Los colaboradores de la organización pueden usar sus certificados firmados para la autenticación, incluso si ha aplicado el inicio de sesión único (SSO) de SAML, sin necesidad de autorizar los certificados firmados.

A menos que haga que los certificados SSH sean un requisito, los miembros de la organización y los colaboradores externos pueden seguir usando otros medios de autenticación para acceder a los recursos de la organización con Git, incluido su nombre de usuario y contraseña, personal access tokens y sus propias claves SSH.

Los miembros no pueden usar el certificado para acceder a bifurcaciones de los repositorios de la organización, a menos que la empresa haya permitido que las CA SSH accedan a repositorios propiedad del usuario. Para más información, consulta Acerca de las autoridades de certificación de SSH.

Acerca de las URL SSH con certificados SSH

Si su organización requiere certificados SSH, para prevenir los errores de autenticación, los miembros y colaboradores externos de la organización deberán utilizar una URL especial que incluya la ID de organización al realizar operaciones de Git por SSH. La URL especial permite que el cliente y servidor negocien con mayor facilidad qué llave debería utilizarse para la autenticación en la computadora del miembro. Si un miembro usa la URL normal que comienza con git@github.com, el cliente SSH podría ofrecer la clave incorrecta, lo que provocaría un error en la operación.

Cualquiera con acceso de lectura al repositorio puede encontrar esta URL si selecciona el menú desplegable Código en la página principal del repositorio y, después, hace clic en Utilizar SSH.

Si su organización no requiere certificados SSH, los colaboradores pueden seguir utilizando sus propias llaves SSH u otros medios de autenticación. En ese caso, funcionará tanto la URL especial como la normal, que comienza con git@github.com.

Emitir certificados

Al emitir cada certificado, debe incluir una extensión que especifique para qué GitHub usuario está el certificado. Puede referirse al usuario utilizando su nombre de usuario o su ID de usuario. Por ejemplo, puede usar el comando de ssh-keygen OpenSSH, reemplazando KEY-IDENTITY por la identidad de clave y USERNAME por un nombre de usuarioGitHub o un identificador de usuario. El certificado que generes se autorizará para actuar en nombre de ese usuario para cualquiera de los recursos de tu organización. Asegúrate de validar la identidad de los usuarios antes de que emitas el certificado.

Para usar login a fin de identificar al usuario, utilice extension:login:

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME ./user-key.pub

Para usar el identificador de usuario, use extension:id:

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:id@github.com=ID ./user-key.pub

Para las CA cargadas a partir del 27 de marzo de 2024, debe usar la marca -V para configurar una duración inferior a 366 días para el certificado. En el caso de las CA cargadas antes de esta fecha, la -V marca es opcional y puede crear certificados que sean irreversibles y que estén activos para siempre.

Si tiene autoridades de certificación (CAs) antiguas que están exentas del requisito de expiración, puede actualizar la CA para hacer cumplir el requisito. Para obtener más información, consulta Administrar las autoridades de certificación SSH de tu organización y Aplicar políticas sobre los ajustes de seguridad en tu empresa.

Si usa un nombre de usuario como extensión de inicio de sesión, GitHub valida que el usuario especificado no ha sido renombrado desde que se emitió el certificado. Esto evita un ataque de cambio de nombre, donde un certificado emitido para un nombre de usuario es válido incluso si cambia la cuenta de usuario subyacente. Para aplicar esto, el certificado debe incluir la notificación valid_after, que nos indica cuándo se emitió el certificado. Este campo suele faltar si no se requiere una expiración para el certificado, por lo que ahora se requieren expiraciones.

Para emitir un certificado para alguien que usa SSH para acceder a varios GitHub productos, puede incluir dos extensiones de inicio de sesión para especificar el nombre de usuario de cada producto. Por ejemplo, el siguiente comando emitiría un certificado para USERNAME-1 para la cuenta del usuario para GitHub Enterprise Cloudy USERNAME-2 para la cuenta del usuario en GitHub Enterprise Server o Nube de GitHub Enterprise con residencia de datos en HOSTNAME.

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub

Puede restringir las direcciones IP desde las que un miembro de la organización puede acceder a los recursos de la organización mediante 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 más información, consulta Enrutamiento entre dominios sin clases en Wikipedia.

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

Revocación de certificados y rotación de Autoridad de Certificación

          GitHub valida los certificados SSH en función de su firma, campos (incluido su período de validez) y si la entidad de certificación de firma es de confianza en el nivel de organización o de empresa. Los certificados OpenSSH no usan listas de revocación de certificados (CRL) ni el Protocolo de estado de certificado en línea (OCSP), por lo que no hay ninguna manera de revocar un certificado ya emitido individual mientras sigue confiando en la misma CA.

Para invalidar los certificados antes de que expiren de forma natural, quite la entidad de certificación emisora de la configuración de la organización o de la empresa. La eliminación de una ENTIDAD de certificación impide GitHub inmediatamente aceptar los certificados SSH firmados por esa ENTIDAD de certificación.

Para rotar una entidad de certificación con una interrupción mínima:

1. Agregue la nueva autoridad de certificación (CA) en la configuración de su empresa u organización.
2. Actualice el sistema de emisión de certificados para firmar nuevos certificados con la nueva ENTIDAD de certificación.
3. Después de que todos los usuarios hayan recibido nuevos certificados de la nueva entidad de certificación, quite la ca anterior.

La emisión de certificados de corta duración reduce la ventana de riesgo si un certificado está en peligro. Para obtener más información sobre la administración de CA, consulte Administrar las autoridades de certificación SSH de tu organización y Aplicar políticas sobre los ajustes de seguridad en tu empresa.