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.
  • Die SSH-Agent-Weiterleitung kann für Windows Benutzer problematisch 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.

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 unsere Anleitung zum Erstellen eines personal access token.

Schlüssel bereitstellen

Du kannst Projekte aus einem Repository in GitHub.com 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 fügt den öffentlichen Teil des Schlüssels direkt an dein Repository anstatt an ein persönliches Konto an, und der private Teil des Schlüssels verbleibt auf deinem Server. Weitere Informationen finden Sie unter Durchführung 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 Berechtigungsebenen für ein Repository in einem persönlichen Konto.

Zur verbesserten Sicherheit und fein abgestimmten Kontrolle über Repositoryzugriff und -berechtigungen empfehlen wir stattdessen die Verwendung einer GitHub App. Weitere Informationen findest du unter Entscheiden, 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][generating-ssh-keys] auf deinem Server aus, und merke dir, wo du das generierte Schlüsselpaar aus öffentlichem und privatem RSA-Schlüssel speicherst.

  2. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  3. Klicke unter dem Repositorynamen auf Settings. 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. Klicken Sie in der Seitenleiste 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.

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.

Anschließend können Sie mit dem Repository mithilfe von SSH interagieren. Beispiel:

git clone git@github.com:OWNER/REPO.git

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 github.com-repo-0
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host github.com-repo-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

  •         `Host github.com-repo-0` – der Alias des Repositorys.

  •         `Hostname github.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@github.com-repo-1:OWNER/repo-1.git


          GitHub App Installationszugriffstoken

Wenn Ihr Server auf Repositorys in einer oder mehreren Organisationen zugreifen muss, können Sie einen GitHub App verwenden, um den benötigten Zugriff zu definieren und daraus engeingeschränkte Installationszugriffstoken GitHub Appzu 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 als erstklassige Akteure auf GitHub gelten, sind die Installationszugriffstoken von jedem GitHub Benutzer entkoppelt, wodurch sie mit "Servicetoken" 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 finden Sie unter "Zinslimits für GitHub Apps" .

Vorteile von Installationszugriffstoken

  • Eng umgrenzte Token mit präzise definierten Berechtigungssätzen und festgelegten Ablaufzeiten (1 Stunde, oder kürzer, wenn sie manuell über die API widerrufen werden)
  • Dedizierte Ratenlimits, die mit Ihrem Unternehmen mitwachsen
  • Entkoppelt von GitHub Benutzeridentitäten, sodass sie keine
  • Da niemals ein Passwort zugewiesen wird, ist keine direkte Anmeldung möglich

Nachteile von Installationszugriffstoken

  • Zum Erstellen der GitHub AppDatei ist 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. Bestimmen Sie, ob Ihr GitHub App öffentlich oder privat sein soll. Wenn GitHub App nur auf Repositories innerhalb Ihrer Organisation wirken soll, möchten Sie es wahrscheinlich privat halten.
  2. Legen Sie die erforderlichen Berechtigungen GitHub App fest, z. B. schreibgeschützter Zugriff auf Repositoryinhalte.
  3. Erstellen Sie Ihre GitHub App über die Einstellungsseite Ihrer Organisation. Weitere Informationen finden Sie unter Erstellen eines GitHub App.
  4. Notieren Sie sich Ihre GitHub Appid.
  5. Generieren Sie den privaten Schlüssel Ihres GitHub App, laden Sie ihn herunter und speichern Sie ihn sicher. Weitere Informationen findest du unter Generating a private key („Generieren eines privaten Schlüssels“).
  6. Installieren Sie Ihre GitHub App in den Repositories, auf die sie wirken muss. Optional können Sie das GitHub App in allen Repositories Ihrer Organisation installieren.
  7. Identifizieren Sie das installation_id, das die Verbindung zwischen Ihrem GitHub App und den Organisations-Repositorys darstellt, auf die diese zugreifen können. Jedes GitHub App und Organisationspaar hat höchstens ein einziges installation_id. 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 eine Authentifizierung als GitHub App mithilfe eines JWT. Weitere Informationen finden Sie unter Authentifizierung als ein GitHub App.
  8. Generiere ein Installationszugriffstoken über den entsprechenden REST-API-Endpunkt. Weitere Informationen findest du unter Erstellen eines Installationszugriffstokens für eine App. Dies erfordert die Authentifizierung als GitHub App mithilfe eines JWT, weitere Informationen finden Sie unter Authentifizierung als GitHub App und Authentifizierung 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 Ihr Server auf mehrere Repositorys zugreifen muss, können Sie ein neues Konto erstellen GitHub.com und einen SSH-Schlüssel anfügen, der ausschließlich für die Automatisierung verwendet wird. Da dieses Konto GitHub.com nicht von einem Menschen verwendet wird, wird es als Maschinennutzer 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).

Tipp

Unsere Vertragsbedingungen lauten:

          _Konten, die von „Bots“ oder durch andere automatisierte Methoden registriert werden, sind nicht zulässig._

Dies bedeutet, dass du die Erstellung von Konten nicht automatisieren kannst. Wenn du jedoch einen einzelnen Computerbenutzer für die Automatisierung von Aufgaben wie Bereitstellungsskripts in deinem Projekt oder deiner Organisation erstellen möchtest, ist das problemlos möglich.

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][generating-ssh-keys] 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.

Weiterführende Lektüre

  •         [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)

  •         [Konfigurieren von Benachrichtigungen](/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#organization-alerts-notification-options)