Informationen zu SSH-Zertifizierungsstellen

Informationen zu SSH-Zertifizierungsstellen

Ein SSH-Zertifikat ist ein Mechanismus, mit dem ein SSH-Schlüssel einen anderen SSH-Schlüssel signieren kann. Wenn Sie eine SSH-Zertifizierungsstelle (CA) verwenden, um Ihren Organisationsmitgliedern und externen Mitarbeitern signierte SSH-Zertifikate bereitzustellen, können Sie die CA zu Ihrem Unternehmenskonto oder Ihrer Organisation hinzufügen, damit diese Organisationsmitarbeiter ihre Zertifikate für den Zugriff auf Organisationsressourcen verwenden können.

Wenn Sie eine SSH-Zertifizierungsstelle zu Ihrem Organisations- oder Enterprise-Konto hinzugefügt haben, können Sie die Zertifizierungsstelle verwenden, um Client-SSH-Zertifikate für Organisationsmitglieder und externe Mitarbeiter zu signieren. Diese Mitwirkenden der Organisation können die signierten Zertifikate verwenden, um auf die Repositories dieser Organisation zuzugreifen.

Zertifikate, die Ihrem Unternehmen hinzugefügt wurden, gewähren Zugriff auf alle Organisationen, die ihrem Enterprise-Konto gehören. Weitere Informationen finden Sie unter Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen.

Du kannst festlegen, dass Mitglieder SSH-Zertifikate verwenden müssen, um auf Organisationsressourcen zuzugreifen, es sei denn, SSH ist in deiem Repository deaktiviert.

Optional können Sie festlegen, dass Mitglieder und externe Mitarbeiter SSH-Zertifikate für den Zugriff auf Organisationsressourcen verwenden. Weitere Informationen findest du unter Verwalten Sie die SSH-Zertifizierungsstellen Ihrer Organisation und Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen.

Du kannst beispielsweise ein internes System einrichten, das jeden Morgen ein neues Zertifikat für deine Entwickler herausgibt. Jeder Entwickler kann sein tägliches Zertifikat verwenden, um an den Repositories Ihrer Organisation auf GitHub zu arbeiten. Am Ende des Tages läuft das Zertifikat automatisch ab. So werden deine Repositorys geschützt, falls das Zertifikat zu einem späteren Zeitpunkt kompromittiert wird.

Mitglieder können das Zertifikat nicht für den Zugriff auf Forks der Repositorys der Organisation verwenden, es sei denn, das Unternehmen hat SSH-CAs für den Zugriff auf Repositorys im Besitz von Benutzern zugelassen. Weitere Informationen finden Sie unter Informationen zu SSH-Zertifizierungsstellen.

Informationen zu SSH-URLs mit SSH-Zertifikaten

Falls Ihre Organisation SSH-Zertifikate verlangt, sollten Organisationsmitglieder und externe Mitarbeiter eine spezielle URL mit der Organisations-ID verwenden, wenn sie Git-Vorgänge über SSH ausführen. So können Authentifizierungsfehler vermieden werden. Mit dieser speziellen URL können der Client und der Server einfacher aushandeln, welche Schlüssel auf dem Computer des Mitglieds für die Authentifizierung verwendet werden sollen. Wenn ein Mitglied die normale URL verwendet, die mit git@HOSTNAME anfängt, bietet der SSH-Client möglicherweise den falschen Schlüssel an, wodurch der Vorgang fehlschlägt.

Jeder mit Lesezugriff auf das Repository kann diese URL finden, indem er das Dropdownmenü Code auf der Hauptseite des Repositorys auswählt und dann auf SSH verwenden klickt.

Wenn Ihre Organisation keine SSH-Zertifikate verlangt, können Mitwirkende weiterhin eigene SSH-Schlüssel oder andere Authentifizierungsmethoden verwenden. In diesem Fall funktioniert entweder die spezielle URL oder die normale URL, die mit git@HOSTNAME beginnt.

Ausgabe von Zertifikaten

Wenn Sie jedes Zertifikat ausstellen, müssen Sie eine Erweiterung angeben, die angibt, für welchen GitHub Benutzer das Zertifikat gilt. Sie können den Benutzer über seinen Anmeldenamen oder seine Benutzer-ID referenzieren. Sie können z. B. den Befehl "OpenSSHssh-keygen" verwenden und KEY-IDENTITY durch Ihre Schlüsselidentität und Ihren BENUTZERNAMEN durch einen BenutzernamenGitHub oder eine Benutzer-ID ersetzen. Das von dir generierte Zertifikat ist berechtigt, im Auftrag dieses Benutzers bzw. dieser Benutzerin für alle Ressourcen deiner Organisation zu handeln. Stelle sicher, dass du die Identität des Benutzers überprüfst, bevor du das Zertifikat ausstellst.

Zur Identifizierung des Benutzers mit login verwenden Sie extension:login:

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

Um die Benutzer-ID zu verwenden, verwenden Sie extension:idFolgendes:

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

Für CAs, die nach dem 27. März 2024 Version 3.13 oder höherGitHub Enterprise Server hochgeladen wurden, müssen Sie die -V Kennzeichnung verwenden, um eine Lebensdauer von weniger als 366 Tagen für das Zertifikat zu konfigurieren. Für CAs, die vor diesem Datum hochgeladen wurden, ist das -V Flag optional, und Sie können Zertifikate erstellen, die unwiderruflich sind und für immer leben.

Wenn Sie über ältere Zertifizierungsstellen verfügen, die von der Ablaufanforderung ausgenommen sind, können Sie die Zertifizierungsstellen aktualisieren, um diese Anforderung durchzusetzen. Weitere Informationen findest du unter Verwalten Sie die SSH-Zertifizierungsstellen Ihrer Organisation und Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen.

Wenn Sie einen Benutzernamen als Anmeldeerweiterung verwenden, wird überprüft, GitHub ob der benannte Benutzer seit der Ausstellung des Zertifikats nicht umbenannt wurde. Dadurch wird ein Umbenennungsangriff verhindert, bei dem ein für einen Benutzernamen ausgestelltes Zertifikat gültig ist, selbst wenn sich das zugrunde liegende Benutzerkonto ändert. Um das zu erzwingen, muss das Zertifikat den Anspruch valid_after enthalten, aus dem hervorgeht, wann das Zertifikat ausgestellt wurde. Dieses Feld fehlt häufig, wenn für das Zertifikat kein Ablaufdatum erforderlich ist. Aus diesem Grund sind Ablauftermine jetzt erforderlich.

Um ein Zertifikat für eine Person auszugeben, die SSH für den Zugriff auf mehrere GitHub Produkte verwendet, können Sie zwei Anmeldeerweiterungen einschließen, um den Benutzernamen für jedes Produkt anzugeben. Der folgende Befehl würde z. B. ein Zertifikat für USERNAME-1 für das Konto GitHub Enterprise Clouddes Benutzers und USERNAME-2 für das Konto des Benutzers auf GitHub Enterprise Server oder GitHub Enterprise-Cloud mit Datenresidenz bei HOSTNAME ausstellen.

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

Mit der Erweiterung source-address schränkst du die IP-Adressen ein, von denen aus ein Organisationsmitglied auf die Ressourcen deiner Organisation zugreifen kann. Als Erweiterung ist eine bestimmte IP-Adresse oder ein IP-Adressbereich mit CIDR-Notation zulässig. Sollen mehrere Adressen oder Bereiche angegeben werden, trenne sie durch Komma voneinander ab. Weitere Informationen findest du unter Classless Inter-Domain Routing auf Wikipedia.

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