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.

In diesem Artikel

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

Zur erhöhten Sicherheit und fein abgestimmten Kontrolle über Repository-Zugriff und -Berechtigungen empfehlen wir stattdessen die Verwendung einer GitHub-App. Weitere Informationen findest du unter Entscheidung, wann eine GitHub-App erstellt werden soll.

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.
  • Bereitstellungsschlüssel sind Anmeldeinformationen, die kein Ablaufdatum haben.
  • Bereitstellungsschlüssel sind nicht direkt mit der Unternehmens-Mitgliedschaft verknüpft. Wenn der Benutzer, der den Bereitstellungsschlüssel erstellt hat, aus dem Repository entfernt wird, bleibt der Bereitstellungsschlüssel weiterhin aktiv, da er nicht an den spezifischen Benutzer, sondern an das Repository gebunden 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. Klicke auf der Randleiste auf Bereitstellungsschlüssel.

  3. Klicke auf Bereitstellungsschlüssel hinzufügen.

  4. Gib im Feld „Titel“ einen Titel an.

  5. Kopiere deinen öffentlichen Schlüssel in das Feld „Schlüssel“.

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

  7. Klicke auf Schlüssel hinzufügen.

Sie können auch die REST-API verwenden, um Bereitstellungsschlüssel zu erstellen. Weitere Informationen finden Sie unter REST-API-Endpunkte für Bereitstellungsschlüssel.

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 Ihr Server auf Repositorys in einer oder mehreren Organisationen zugreifen muss, können Sie 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 Apps-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 Ratenbegrenzungen, die mit deiner Organisation skaliert werden
  • Entkoppelt von GitHub-Benutzeridentitäten, sodass sie keine lizenzierten Arbeitsplätze verbrauchen
  • Da niemals ein Passwort zugewiesen wird, ist keine direkte Anmeldung möglich

Nachteile von Installationszugriffstoken

  • Zum Erstellen der GitHub App ist ein zusätzliches Setup erforderlich.
  • Installationszugriffstoken laufen nach einer Stunde ab und müssen daher (üblicherweise nach Bedarf) mithilfe von Code neu generiert werden.

Einrichten von Installationszugriffstoken

  1. Entscheiden Sie, ob Ihre GitHub App öffentlich oder privat sein soll. Wenn Ihre GitHub App ausschließlich mit Repositorys innerhalb Ihrer Organisation eingesetzt wird, sollte sie am besten privat sein.
  2. Weisen Sie die erforderlichen Berechtigungen für Ihre GitHub App zu (z. B. Lesezugriff auf Repositoryinhalte).
  3. Erstellen Sie Ihre GitHub App über die Einstellungsseite Ihrer Organisation. Weitere Informationen finden Sie unter Erstellen einer GitHub App.
  4. Verzeichnen Ihrer GitHub App id.
  5. Generieren Sie den privaten Schlüssel Ihrer GitHub App, laden Sie ihn herunter, und speichern Sie ihn an einem sicheren Speicherort. Weitere Informationen findest du unter Generating a private key („Generieren eines privaten Schlüssels“).
  6. Installieren Sie Ihre GitHub App in den Repositorys, für die sie benötigt wird. Optional können Sie die GitHub App in allen Repositorys in Ihrer Organisation installieren.
  7. Ermittlen Sie die installation_id der Verbindung zwischen Ihrer GitHub App und den Organisationsrepositorys, auf die sie zugreifen kann. Jedes GitHub App-Organisations-Paar weist höchstens ein einzelnes installation_id auf. 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. Dies erfordert die Authentifizierung als GitHub App unter Verwendung eines JWT. Weitere Informationen finden Sie unter 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 finden Sie unter Authentifizieren als GitHub App und 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 finden Sie unter Generieren eines Installationszugriffstokens für eine GitHub-App.

Computerbenutzer

Wenn dein Server auf mehrere Repositorys zugreifen muss, kannst du ein neues Konto auf Ihre 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 Ihre GitHub Enterprise Server-Instance nicht von einem Menschen 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