À 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.

          GitHub utilise des certificats utilisateur SSH au format OpenSSH pour authentifier les opérations Git sur SSH en validant la signature et les champs du certificat (y compris sa période de validité) par rapport à une autorité de certification SSH approuvée configurée au niveau de l’organisation et/ou de l’entreprise.

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 référentiel.

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 utiliser son certificat quotidien pour travailler sur les dépôts de votre organisation sur GitHub. À 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 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@HOSTNAME, 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@HOSTNAME) fonctionne.

Émission de certificats

Lorsque vous émettez chaque certificat, vous devez inclure une extension qui spécifie l’utilisateur pour lequel GitHub le certificat est destiné. Vous pouvez référencer l’utilisateur à l’aide de son handle de connexion ou de son ID d’utilisateur. Par exemple, vous pouvez utiliser la ssh-keygen commande d’OpenSSH, en remplaçant KEY-IDENTITY par votre identité de clé et nom d’utilisateur par un nom d’utilisateurGitHub ou un ID d’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@HOSTNAME=USERNAME ./user-key.pub

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

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

Pour les autorités de certification chargées vers GitHub Enterprise Server la version 3.13 ou ultérieure, vous devez utiliser l’indicateur -V pour configurer une durée de vie inférieure à 366 jours pour le certificat. Pour les autorités de certification chargées avant la version 3.13, l’indicateur -V est facultatif et vous pouvez créer des certificats qui sont irréversibles et vivants pour toujours.

Si vous avez des autorités de certification héritées qui sont exemptées de l’exigence d’expiration, vous pouvez mettre à niveau l’autorité de certification 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 vérifie 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 pour une personne qui utilise SSH pour accéder à plusieurs GitHub produits, vous pouvez inclure deux extensions de connexion pour spécifier le nom d’utilisateur de chaque produit. Par exemple, la commande suivante émet un certificat pour USERNAME-1 pour le compte GitHub Enterprise Cloudde l’utilisateur pour , et USERNAME-2 pour le compte de l’utilisateur sur GitHub Enterprise Server ou GitHub Enterprise Cloud avec résidence des données sur 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 sans classe entre domaines (CIDR) sur Wikipédia.

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

Révocation de certificats et rotation de l’autorité de certification

          GitHub valide les certificats SSH en fonction de leur signature, champs (y compris leur période de validité) et indique si l’autorité de certification de signature est approuvée au niveau de l’organisation ou de l’entreprise. Les certificats OpenSSH n’utilisent pas de listes de révocation de certificats (CRL) ou OCSP (Online Certificate Status Protocol), de sorte qu’il n’existe aucun moyen de révoquer un certificat déjà émis individuellement tout en continuant à approuver la même autorité de certification.

Pour invalider les certificats avant leur expiration naturelle, supprimez l’autorité de certification émettrice de vos paramètres d’entreprise ou d’organisation. La suppression d’une autorité de certification empêche GitHub immédiatement d’accepter les certificats SSH signés par cette autorité de certification.

Pour effectuer une rotation d'une autorité de certification tout en minimisant les interruptions :

1. Ajoutez la nouvelle autorité de certification à vos paramètres d’entreprise ou d’organisation.
2. Mettez à jour votre système d’émission de certificats pour signer de nouveaux certificats avec la nouvelle autorité de certification.
3. Une fois que tous les utilisateurs ont reçu de nouveaux certificats de la nouvelle autorité de certification, supprimez l’ancienne autorité de certification.

L’émission de certificats à courte durée réduit la fenêtre de risque si un certificat est compromis. Pour plus d’informations sur la gestion des autorités de certification, 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.