Verwalten von Bereitstellungsschlüsseln

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.

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.

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

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

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

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

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

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

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

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

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

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

1. Führe die ssh--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.

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

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

• Host .com-repo-0 – der Alias des Repositorys.
• 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 [email protected]:OWNER/repo-1.git

Wenn Ihr Server auf Repositorys in einer oder mehreren Organisationen zugreifen muss, können Sie eine App verwenden, um den benötigten Zugriff zu definieren, und dann die Installationszugriffstoken mit präzise definiertem Bereich über diese 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 Apps Hauptakteure auf sind, werden die Installationszugriffstoken von -Benutzenden 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 Apps („Ratenlimits für -Apps“).

• 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
• Von den Benutzeridentitäten von entkoppelt, damit sie keine Arbeitsplätze mit Lizenz belegen
• Da niemals ein Passwort zugewiesen wird, ist keine direkte Anmeldung möglich

• Zum Erstellen der 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.

1. Entscheiden Sie, ob Ihre App öffentlich oder privat sein soll. Wenn Ihre 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 App zu (z. B. Lesezugriff auf Repositoryinhalte).
3. Erstellen Sie Ihre App über die Einstellungsseite Ihrer Organisation. Weitere Informationen finden Sie unter Erstellen einer App.
4. Verzeichnen Ihrer App id.
5. Generieren Sie den privaten Schlüssel Ihrer 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 App in den Repositorys, für die sie benötigt wird. Optional können Sie die App in allen Repositorys in Ihrer Organisation installieren.
7. Ermittlen Sie die installation_id der Verbindung zwischen Ihrer App und den Organisationsrepositorys, auf die sie zugreifen kann. Jedes 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 App unter Verwendung eines JWT. Weitere Informationen finden Sie unter Authentifizieren als 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 App mit einem JWT erforderlich. Weitere Informationen finden Sie unter Authentifizieren als 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 -App.

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

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

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

1. Führe die ssh--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.

• Configuring notifications („Konfigurieren von Benachrichtigungen“)