Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

À propos des autorités de certification SSH

Avec une autorité de certification SSH, votre organisation ou votre compte d’entreprise peut fournir des certificats SSH que les membres peuvent utiliser pour accéder à vos ressources avec Git.

À 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 de votre organisation des certificats SSH signés, vous pouvez ajouter l’autorité de certification à votre compte d’entreprise ou à votre organisation pour autoriser les membres de l’organisation à accéder aux ressources de l’organisation en utilisant leurs certificats.

Remarque : Pour utiliser des autorités de certification SSH, votre organisation doit utiliser GitHub Enterprise Cloud. Pour plus d’informations sur la façon d’essayer gratuitement GitHub Enterprise Cloud, consultez « Configuration d’un essai de GitHub Enterprise Cloud ».

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 de l’organisation. Les membres de l’organisation peuvent ensuite utiliser les certificats signés pour accéder aux dépôts de votre organisation (et uniquement aux dépôts de votre organisation) avec Git. Si vous le souhaitez, vous pouvez exiger que les membres 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 membres de l’organisation peuvent utiliser leurs certificats signés pour les besoins d’authentification même si vous avez activé l’authentification unique SAML. Sauf si vous rendez les certificats SSH obligatoires, les membres 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 pourront pas utiliser leurs certificats pour accéder à des duplications (fork) de vos dépôts appartenant à leurs comptes personnels.

À propos des URL SSH avec des certificats SSH

Si votre organisation exige des certificats SSH, pour éviter les erreurs d’authentification, les membres 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 membres 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é. 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 nom d’utilisateur GitHub Enterprise Cloud. 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.

Remarque : Vous devez effectuer une mise à jour vers OpenSSH 7.6 ou version ultérieure pour utiliser ces commandes.

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

Avertissement : Une fois qu’un certificat a été signé et émis, il ne peut pas être révoqué. Veillez à utiliser l’indicateur -V pour configurer la durée de vie du certificat ; sans cet indicateur, le certificat peut être utilisé indéfiniment.

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 émet un certificat pour USERNAME-1 pour le compte d’utilisateur sur GitHub Enterprise Cloud, et pour USERNAME-2 pour le compte d’utilisateur sur GitHub AE ou GitHub Enterprise Server à l’emplacement 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