À propos des autorités de certification SSH

À propos des autorités de certification SSH

Un certificat SSH est un mécanisme permettant à une clé SSH de signer une autre clé SSH. Si vous utilisez une autorité de certification SSH pour fournir aux membres et les collaborateurs externes de votre organisation des certificats SSH signés, vous pouvez ajouter l'autorité de certification à votre compte d'entreprise ou à votre organisation pour autoriser ces contributeurs de l'organisation à accéder aux ressources de l'organisation en utilisant leurs certificats.

Après avoir ajouté une autorité de certification SSH à votre organisation ou à votre compte d'entreprise, vous pouvez utiliser cette autorité de certification afin de signer des certificats SSH clients pour les membres et les collaborateurs externes de l'organisation. Ces contributeurs externes de l'organisation peuvent ensuite utiliser les certificats signés pour accéder aux dépôts de votre organisation.

Les certificats ajoutés à votre entreprise permettent d'accéder à toutes les organisations appartenant à votre compte d’entreprise. Pour plus d’informations, consultez « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».

Vous pouvez exiger que les membres utilisent des certificats SSH pour accéder aux ressources de l’organisation, sauf si SSH est désactivé dans votre dépôt.

Si vous le souhaitez, vous pouvez exiger que les membres et les collaborateurs externes utilisent des certificats SSH pour accéder aux ressources de l'organisation. Pour plus d’informations, consultez « Gestion des autorités de certification SSH de votre organisation » et « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».

Par exemple, vous pouvez créer un système interne qui émet un nouveau certificat pour vos développeurs tous les matins. Chaque développeur peut alors utiliser son certificat quotidien pour travailler dans les dépôts de votre organisation sur GitHub Enterprise Cloud. À la fin de la journée, le certificat peut expirer automatiquement, protégeant ainsi vos dépôts contre toute compromission ultérieure du certificat.

Les contributeurs de l'organisation peuvent utiliser leurs certificats signés pour l'authentification sans avoir à les autoriser, même si vous avez appliqué l'authentification unique SAML.

Sauf si vous rendez les certificats SSH obligatoires, les membres et les collaborateurs externes de l'organisation peuvent continuer à utiliser d'autres moyens d'authentification pour accéder aux ressources de votre organisation avec Git, notamment leur nom d'utilisateur et leur mot de passe, leur personal access token et leurs propres clés SSH.

Les membres ne peuvent pas utiliser le certificat pour accéder aux duplications des référentiels de l’organisation, sauf si l’entreprise a autorisé les autorités de confiance SSH à accéder aux référentiels appartenant aux utilisateurs. Pour plus d’informations, consultez « À propos des autorités de certification SSH ».

À propos des URL SSH avec des certificats SSH

Si votre organisation exige des certificats SSH, pour éviter les erreurs d'authentification, les membres et collaborateurs externes de l'organisation doivent utiliser une URL spéciale qui inclut l'ID de l'organisation quand ils effectuent des opérations Git via SSH. Cette URL spéciale permet au client et au serveur de négocier plus facilement quelle clé sur l'ordinateur du membre doit être utilisée pour l'authentification. Si un membre utilise l'URL standard, qui commence par git@github.com, le client SSH risque de fournir la mauvaise clé, entraînant l'échec de l'opération.

Toute personne qui a un accès en lecture au dépôt peut trouver cette URL en sélectionnant le menu déroulant Code dans la page principale du dépôt, puis en cliquant sur Utiliser SSH.

Si votre organisation n'exige pas de certificats SSH, les contributeurs peuvent continuer à utiliser leurs propres clés SSH ou d'autres moyens d'authentification. Dans ce cas, l'URL spéciale ou l'URL standard (qui commence par git@github.com) fonctionne.

Émission de certificats

Lorsque vous émettez chaque certificat, vous devez inclure une extension qui spécifie pour quelles données GitHub Enterprise Cloud le certificat est utilisé. Vous pouvez référencer l’utilisateur à l’aide de son identifiant de connexion. Par exemple, vous pouvez utiliser la commande ssh-keygen d’OpenSSH, en remplaçant KEY-IDENTITY par votre propre identité de clé, et USERNAME par un GitHub Enterprise Cloud nom d’utilisateur ou un identifiant utilisateur. Le certificat que vous générez sera autorisé à agir pour le compte de cet utilisateur sur toutes les ressources de votre organisation. Assurez-vous de valider l'identité de l'utilisateur avant d'émettre le certificat.

Pour utiliser login afin d’identifier l’utilisateur, utilisez extension:login :

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

Pour utiliser l’identifiant utilisateur, utilisez extension:id :

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

Pour les autorités de confiance chargées après le 27 mars 2024, vous absolument utiliser l’indicateur -V pour configurer une durée de vie inférieure à 366 jours pour le certificat. Pour les autorités de confiance chargées avant cette date, l’indicateur -V est facultatif et vous pouvez créer des certificats qui sont irréversibles et définitifs.

Si vous avez des autorités de confiance héritées qui sont exemptées de l’exigence d’expiration, vous pouvez mettre à niveau l’autorité de confiance pour appliquer l’exigence. Pour en savoir plus, consultez « Gestion des autorités de certification SSH de votre organisation » et « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».

Si vous utilisez un nom d’utilisateur comme extension de connexion, GitHub valide que l’utilisateur nommé n’a pas été renommé depuis l’émission du certificat. Cela empêche une attaque de renommage, où un certificat émis pour un nom d’utilisateur est valide même si le compte d’utilisateur sous-jacent change. Pour ce faire, le certificat doit inclure la revendication valid_after qui nous indique quand le certificat a été émis. Ce champ est souvent manquant si une expiration n’est pas requise pour le certificat, c’est pourquoi les expirations sont désormais requises.

Pour émettre un certificat destiné à une personne qui utilise SSH pour accéder à plusieurs produits GitHub, vous pouvez inclure deux extensions de connexion afin de spécifier le nom d'utilisateur de chaque produit. Par exemple, la commande suivante émettrait un certificat pour USERNAME-1 pour le compte de l'utilisateur sur GitHub Enterprise Cloud, et USERNAME-2 pour le compte de l'utilisateur sur GitHub Enterprise Server à 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

Vous pouvez restreindre les adresses IP à partir desquelles un membre de l'organisation peut accéder aux ressources de votre organisation, en utilisant une extension source-address. L'extension accepte une adresse IP spécifique ou une plage d'adresses IP utilisant la notation CIDR. Vous pouvez spécifier plusieurs adresses ou plages en séparant les valeurs par des virgules. Pour plus d'informations, consultez « Routage CIDR (Classless Interdomain Routing) » sur Wikipédia.

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