Skip to main content

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 der SSH-Agent-Weiterleitung

  • 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 der SSH-Agent-Weiterleitung

  • 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 der SSH-Agent-Weiterleitung

  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 des HTTPS-Klonens mit OAuth-Token

  • 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 des HTTPS-Klonens mit OAuth-Token

  • 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 des HTTPS-Klonens mit OAuth-Token

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

Schlüssel bereitstellen

Du kannst Projekte aus einem Repository in deine GitHub Enterprise Server-Instanz 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 von Bereitstellungsschlüsseln

  • 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 von Bereitstellungsschlüsseln

  • 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 von Bereitstellungsschlüsseln

  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. Navigiere auf deine GitHub Enterprise Server-Instanz zur Hauptseite des Repositorys.
  3. Wähle unter dem Namen deines Repositorys die Option Einstellungen aus. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus. Screenshot eines Repositoryheaders mit den Registerkarten. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.
  4. Klicke auf der Randleiste auf Bereitstellungsschlüssel.
  5. Klicke auf Bereitstellungsschlüssel hinzufügen.
  6. Gib im Feld „Titel“ einen Titel an.
  7. Kopiere deinen öffentlichen Schlüssel in das Feld „Schlüssel“.
  8. 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.
  9. 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

Installationszugriffstoken für eine GitHub App

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 die Installationszugriffstoken mit präzise definiertem Bereich über diese GitHub-App generieren. Für die Installationszugriffstoken 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 Installationszugriffstoken von GitHub-Benutzer*innen getrennt, sodass sie mit „Diensttoken“ vergleichbar sind. Darüber hinaus verfügen Installationszugriffstoken ü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 von Installationszugriffstoken

  • 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 von Installationszugriffstoken

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

Einrichten von Installationszugriffstoken

  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 Installationszugriffstoken über den entsprechenden REST-API-Endpunkt. Weitere Informationen findest du unter 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 Installationszugriffstoken für die Interaktion mit deinen Repositorys (über die REST- oder GraphQL-API bzw. über einen Git-Client).

Weitere Informationen findest du unter Generieren eines Installationszugriffstokens für eine GitHub-App.

Computerbenutzer

Wenn dein Server auf mehrere Repositorys zugreifen muss, kannst du ein neues Konto auf deine GitHub Enterprise Server-Instanz erstellen und einen SSH-Schlüssel anfügen, der ausschließlich für die Automatisierung verwendet wird. Da dieses Konto auf deine GitHub Enterprise Server-Instanz 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 von Computerbenutzern

  • 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 von Computerbenutzern

  • 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 von Computerbenutzern

  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