Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Diese Version von GitHub Enterprise wird eingestellt am 2023-03-15. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Verwalten von Bereitstellungsschlüsseln

Hier erfährst du, wie du SSH-Schlüssel auf deinen Servern verwalten kannst, wenn du Bereitstellungsskripts automatisierst, und welche Möglichkeit für dich am besten geeignet ist.

Du kannst SSH-Schlüssel auf deinen Servern verwalten, wenn du Bereitstellungsskripts mithilfe von SSH-Agent-Weiterleitung, HTTPS mit OAuth-Token, Bereitstellungsschlüsseln oder Computerbenutzern automatisierst.

SSH-Agent-Weiterleitung

In vielen Fällen – insbesondere zu Beginn eines Projekts – ist die SSH-Agent-Weiterleitung die schnellste und einfachste Methode. Bei der Agent-Weiterleitung werden dieselben SSH-Schlüssel verwendet wie bei deinem lokalen Entwicklungscomputer.

Vorteile

  • Du musst keine neuen Schlüssel generieren oder nachverfolgen.
  • Es gibt keine Schlüsselverwaltung. Benutzer*innen verfügen auf dem Server über dieselben Berechtigungen wie auf dem lokalen Computer.
  • Auf dem Server werden keine Schlüssel gespeichert. Sollte der Server kompromittiert sein, musst du also nicht nach kompromittierten Schlüsseln suchen und diese entfernen.

Nachteile

  • Benutzer*innen müssen SSH für die Bereitstellung nutzen. Automatisierte Bereitstellungsprozesse können nicht verwendet werden.
  • Für Windows-Benutzer*innen kann die SSH-Agent-Weiterleitung umständlich sein.

Einrichten

  1. Aktiviere die Agent-Weiterleitung lokal. Weitere Informationen findest du in unserem Leitfaden zur SSH-Agent-Weiterleitung.
  2. Lege deine Bereitstellungsskripts so fest, dass die Agent-Weiterleitung verwendet wird. Bei einem Bash-Skript sieht die Aktivierung der Agent-Weiterleitung z. B. in etwa wie folgt aus: ssh -A serverA 'bash -s' < deploy.sh

HTTPS-Klonen mit OAuth-Token

Wenn du keine SSH-Schlüssel verwenden möchtest, kannst du HTTPS mit OAuth-Token nutzen.

Vorteile

  • Alle Benutzer*innen mit Zugriff auf den Server können das Repository bereitstellen.

  • Benutzer*innen müssen ihre lokalen SSH-Einstellungen nicht ändern.

  • Es werden nicht mehrere Token (ein Token pro Benutzer*in) benötigt. Ein Token pro Server ist ausreichend.

  • Da Token jederzeit widerrufen werden können, sind sie im Wesentlichen ein einmaliges Kennwort.

  • Neue Token können unter Verwendung der OAuth-API problemlos mit einem Skript generiert werden.

Nachteile

  • Du musst sicherstellen, dass du dein Token mit den richtigen Zugriffsbereichen konfigurierst.
  • Token sind im Wesentlichen Kennwörter und müssen auf dieselbe Weise geschützt werden.

Einrichten

Lies unseren Leitfaden, der erklärt, wie ein personal access token erstellt wird.

Schlüssel bereitstellen

Du kannst Projekte aus einem Repository in your GitHub Enterprise Server instance auf deinem Server starten, indem du einen Bereitstellungsschlüssel verwendest. Dabei handelt es sich um einen SSH-Schlüssel, der Zugriff auf ein einzelnes Repository gewährt. GitHub Enterprise Server fügt den öffentlichen Teil des Schlüssels direkt an dein Repository anstatt an dein persönliches Konto an, und der private Teil des Schlüssels verbleibt auf deinem Server. Weitere Informationen findest du unter Übermitteln von Bereitstellungen.

Durch die Bereitstellung von Schlüsseln mit Schreibzugriff können dieselben Aktionen durchgeführt werden wie von einem Organisationsmitglied mit Administratorzugriff oder einem Mitarbeiter in einem persönlichen Repository. Weitere Informationen findest du unter Repositoryrollen für eine Organisation und unter Berechtigungsebenen für ein Repository in einem persönlichen Konto.

Vorteile

  • Alle Benutzer*innen, die Zugriff auf das Repository und den Server haben, können das Projekt bereitstellen.
  • Benutzer*innen müssen ihre lokalen SSH-Einstellungen nicht ändern.
  • Bereitstellungsschlüssel sind standardmäßig schreibgeschützt, aber du kannst ihnen Schreibzugriff erteilen, wenn du sie einem Repository hinzufügst.

Nachteile

  • Bereitstellungsschlüssel gewähren lediglich Zugriff auf ein einzelnes Repository. Komplexere Projekte verfügen möglicherweise über eine Vielzahl von Repositorys, die Daten vom selben Server pullen.
  • Bereitstellungsschlüssel sind in der Regel nicht durch eine Passphrase geschützt, sodass der Schlüssel bei einem kompromittierten Server leicht zugänglich ist.

Einrichten

  1. Führe die ssh-keygen-Prozedur auf deinem Server aus, und merke dir, wo du das generierte Schlüsselpaar aus öffentlichem und privatem RSA-Schlüssel speicherst.

  2. Klicke oben rechts auf einer GitHub Enterprise Server-Seite auf dein Profilfoto und dann auf Dein Profil.

    Navigation zum Profil

  3. Klicke auf deiner Profilseite auf Repositorys, und klicke dann auf den Namen deines Repositorys. Link zu Repositorys

  4. Klicke in deinem Repository auf Einstellungen. Repositoryeinstellungen

  5. Klicke auf der Randleiste auf Bereitstellungsschlüsselund dann auf Bereitstellungsschlüssel hinzufügen. Link zum Hinzufügen von Bereitstellungsschlüsseln

  6. Gib einen Titel an, und füge deinen öffentlichen Schlüssel ein. Seite für Bereitstellungsschlüssel

  7. Wähle Schreibzugriff gewähren aus, wenn dieser Schlüssel über Schreibzugriff auf das Repository verfügen soll. Ein Bereitstellungsschlüssel mit Schreibzugriff ermöglicht einen Bereitstellungs-Push an das Repository.

  8. Klicke auf Schlüssel hinzufügen.

Verwenden von mehreren Repositorys auf einem Server

Wenn du mehrere Repositorys auf einem Server verwendest, musst du für jedes Repository ein dediziertes Schlüsselpaar generieren. Bereitstellungsschlüssel können nicht für mehrere Repositorys wiederverwendet werden.

Füge in der SSH-Konfigurationsdatei des Servers (üblicherweise ~/.ssh/config) einen Aliaseintrag für jedes Repository hinzu. Beispiel:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 – der Alias des Repositorys.
  • Hostname my-GHE-hostname.com – konfiguriert den Hostnamen, der mit dem Alias verwendet wird.
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key – weist dem Alias einen privaten Schlüssel zu.

Anschließend kannst du den Alias des Hostnamens für die Interaktion mit dem Repository über SSH verwenden. Dabei wird der eindeutige Bereitstellungsschlüssel verwendet, der diesem Alias zugewiesen ist. Beispiel:

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Server-zu-Server-Token

Wenn dein Server auf Repositorys in einer oder mehreren Organisationen zugreifen muss, kannst du eine GitHub-App verwenden, um den benötigten Zugriff zu definieren, und dann in dieser GitHub-App Server-zu-Server-Token mit präzise definiertem Bereich generieren. Für die Server-zu-Server-Token können einzelne oder mehrere Repositorys als Bereich festgelegt werden, und es können präzise abgestimmte Berechtigungen zugewiesen werden. Du kannst z. B. ein Token mit Lesezugriff auf den Inhalt eines Repositorys generieren.

Da GitHub-Apps Hauptakteure in GitHub Enterprise Server sind, werden die Server-zu-Server-Token von GitHub-Benutzer*innen getrennt, sodass sie mit „Diensttoken“ vergleichbar sind. Darüber hinaus verfügen Server-zu-Server-Token über dedizierte Ratenlimits, die mit der Größe der Organisationen skaliert werden, für die sie eingesetzt werden. Weitere Informationen findest du unter Rate limits for GitHub Apps („Ratenlimits für GitHub-Apps“).

Vorteile

  • Token mit präzise definiertem Bereich und sorgfältig definierten Berechtigungen sowie Ablaufzeiten (1 Stunde, sofern das Token nicht vorher manuell über die API widerrufen wird).
  • Dedizierte Ratenlimits, die mit deiner Organisation skaliert werden
  • Entkoppelt von GitHub-Benutzeridentitäten, sodass keine lizenzierten Arbeitsplätze genutzt werden.
  • Da niemals ein Kennwort zugewiesen wird, ist keine direkte Anmeldung möglich.

Nachteile

  • Zum Erstellen der GitHub-App sind zusätzliche Einrichtungsschritte erforderlich.
  • Server-zu-Server-Token laufen nach 1 Stunde ab und müssen daher (üblicherweise nach Bedarf) mithilfe von Code neu generiert werden.

Einrichten

  1. Lege fest, ob deine GitHub-App öffentlich oder privat sein soll. Wenn deine GitHub-App ausschließlich mit Repositorys innerhalb deiner Organisation eingesetzt wird, sollte sie am besten privat sein.
  2. Weise die erforderlichen Berechtigungen für deine GitHub-App zu (z. B. Lesezugriff auf Repositoryinhalte).
  3. Erstelle deine GitHub-App über die Einstellungsseite deiner Organisation. Weitere Informationen findest du unter Creating a GitHub App („Erstellen einer GitHub-App“).
  4. Notiere die id deiner GitHub-App.
  5. Generiere den privaten Schlüssel deiner GitHub-App, lade ihn herunter, und speichere ihn an einem sicheren Speicherort. Weitere Informationen findest du unter Generating a private key („Generieren eines privaten Schlüssels“).
  6. Installiere deine GitHub-App in den Repositorys, für die sie benötigt wird. Optional kannst du die GitHub-App in allen Repositorys in deiner Organisation installieren.
  7. Ermittle die installation_id der Verbindung zwischen deiner GitHub-App und den Organisationsrepositorys, auf die sie zugreifen kann. Jedes Paar aus GitHub-App und Organisation darf über maximal eine installation_id verfügen. Zum Ermitteln dieser installation_id kannst du die Schritte unter Get an organization installation for the authenticated app („Abrufen einer Organisationsinstallation für die authentifizierte App“) ausführen. Dazu ist eine Authentifizierung als GitHub-App mit einem JWT erforderlich. Weitere Informationen findest du unter Authenticating as a GitHub App („Authentifizieren als GitHub-App“).
  8. Generiere ein Server-zu-Server-Token über den entsprechenden REST-API-Endpunkt. Weitere Informationen findest du unter Create an installation access token for an app („Erstellen eines Installationszugriffstokens für eine App“). Dazu ist eine Authentifizierung als GitHub-App mit einem JWT erforderlich. Weitere Informationen findest du unter Authenticating as a GitHub App („Authentifizieren als GitHub-App“) und Authenticating as an installation („Authentifizieren als Installation“).
  9. Verwende dieses Server-zu-Server-Token für die Interaktion mit deinen Repositorys (über die REST- oder GraphQL-API bzw. über einen Git-Client).

Computerbenutzer

Wenn dein Server auf mehrere Repositorys zugreifen muss, kannst du ein neues Konto auf your GitHub Enterprise Server instance erstellen und einen SSH-Schlüssel anfügen, der ausschließlich für die Automatisierung verwendet wird. Da dieses Konto auf your GitHub Enterprise Server instance nicht von Personen verwendet wird, wird es als Computerbenutzer bezeichnet. Du kannst den Computerbenutzer als Projektmitarbeiter für ein persönliches Repository (mit Lese- und Schreibzugriff), als externen Mitarbeiter für ein Organisationsrepository (mit Lese-, Schreib- oder Administratorzugriff) oder zu einem Team mit Zugriff auf die Repositorys hinzufügen, die automatisiert werden müssen (dabei werden die Berechtigungen des Teams zugewiesen).

Vorteile

  • Alle Benutzer*innen, die Zugriff auf das Repository und den Server haben, können das Projekt bereitstellen.
  • (Menschliche) Benutzer*innen müssen ihre lokalen SSH-Schlüssel nicht ändern.
  • Es werden nicht mehrere Schlüssel benötigt, ein Schlüssel pro Server ist ausreichend.

Nachteile

  • Lediglich bei Organisationen können Computerbenutzer auf Lesezugriff beschränkt werden. Persönliche Repositorys gewähren Projektmitarbeitern immer Lese- und Schreibzugriff.
  • Genau wie Bereitstellungsschlüssel sind auch Computerbenutzerschlüssel in der Regel nicht durch eine Passphrase geschützt.

Einrichten

  1. Führe die ssh-keygen-Prozedur auf deinem Server aus, und füge den öffentlichen Schlüssel an das Computerbenutzerkonto an.
  2. Gewähre dem Computerbenutzerkonto Zugriff auf die Repositorys, die automatisiert werden sollen. Zu diesem Zweck kannst du das Konto als Projektmitarbeiter, als externer Mitarbeiter oder zu einem Team in einer Organisation hinzufügen.

Weitere Informationsquellen