Warum kann ich einen SSH-Schlüssel nicht für mehr als ein Github-Repo verwenden?

Lesezeit: 5 Minuten

Benutzer-Avatar
kramer65

Ich habe einen Server, der mit dem Inhalt von zwei Git-Repos eingerichtet werden muss, die ich bei Github hoste. Ich möchte nun den ssh-Schlüssel des Servers als Bereitstellungsschlüssel zu beiden Projekten auf github hinzufügen.

Leider bekomme ich eine Fehlermeldung Key is already in usedie gem diese Github-Seite liegt daran, dass ich einen Bereitstellungsschlüssel nicht mehr als einem Repo hinzufügen kann.

Ich frage mich aber wirklich; warum ist das ein problem? Warum kann ein Server nicht auf mehrere Repos zugreifen? Welches Risiko versuchen sie hier zu mindern?

Das ist nicht ganz die richtige Charakterisierung dessen, was auf der von Ihnen verlinkten GitHub-Seite steht. Eigentlich du kann Verwenden Sie denselben SSH-Schlüssel für viele verschiedene GitHub-Repositories. Was Sie nicht tun können, ist, einen SSH-Schlüssel für viele Repositories zu verwenden und als das, was sie einen “Bereitstellungsschlüssel” nennen, noch verwenden gleich ssh-Schlüssel wie einige Sonstiges Benutzer.

Was hier vor sich geht, ist, dass der SSH-Server von GitHub eingehende Schlüssel in einen von zwei Typen klassifiziert:

  • Ein Kontoschlüsseldie eine eingehende Verbindung als authentifiziert Sie. Sie haben dann Berechtigungen für einen breiten (oder schmalen) Bereich von Repositories, wie durch die Einstellungen für „Konten mit Zugriff“ jedes Repositorys gesteuert. Das heißt, der Schlüssel selbst ist, wie sie wissen, dass Sie sind kramer65 (oder wie auch immer Ihr Kontoname dort tatsächlich steht).
  • EIN Schlüssel bereitstellenwodurch eine eingehende Verbindung als Zugriff authentifiziert wird ein bestimmtes Depot. Das heißt, es ist kein “Konto” beteiligt: ​​Es ist nur ein Schlüssel, der an ein bestimmtes Repository angehängt ist.

Es gibt auch “Maschinenbenutzer”, aber das ist eine Art Konto; Ich bin mir nicht sicher, ob GitHub diese überhaupt intern von regulären Kontoschlüsseln unterscheidet. Da diese eher Konto- als Deploy-Key-ähnlich sind, können Sie ihnen Zugriff auf viele verschiedene Repositories gewähren. (Das ist wahrscheinlich das, was Sie wollen.)

Ich frage mich aber wirklich; warum ist das ein problem? Warum kann ein Server nicht auf mehrere Repos zugreifen? Welches Risiko versuchen sie hier zu mindern?

Sie sind nicht wirklich schützen irgendwas hier. Sie lassen Sie einfach auf GitHub diesen einen zusätzlichen Schlüssel speichern, und für (Ihre) Bequemlichkeit tun Sie es, ohne sich die Mühe zu machen, ein Konto zu erstellen. Aus (ihrer) Bequemlichkeit hängen sie diesen einen zusätzlichen Schlüssel dann an genau ein Repository an, wodurch ihr ssh-Server – oder wirklich, was direkt dahinter steht, nachdem sich der Schlüssel authentifiziert hat, dh die „Login-Shell“ – das eine erlaubte Repository nachschlagen kann ohne zuerst durch eine “Konto”-Tabelle zu leiten. Wenn der eingehende Schlüssel ein Schlüssel für ein Konto (oder einen Computerbenutzer) ist, muss sein SSH-Server oder was direkt dahinter steht, in dieser sekundären Tabelle nachsehen, um den Satz zulässiger Repositories zu finden.

Sehen https://developer.github.com/guides/managing-deploy-keys/#deploy-keys für Details.

(Es gibt keinen theoretischen Grund, warum sie einen Bereitstellungsschlüssel nicht zulassen könnten automatisch Erstellen Sie einen ansonsten anonymen “Maschinenbenutzer”, der dann automatisch zu jedem Repository hinzugefügt oder daraus entfernt wird, wie Sie möchten. Allerdings kauft das Sie nichts, da Maschinenbenutzer bereits existieren und dieselbe Funktion ausführen. Sie können versuchen, es als Sicherheitsmerkmal zu verwenden, weil es Sie wissen lässt: “Hey, dieser Schlüssel bedeutet mir schon etwas” … aber wenn Sie diesen Schlüssel haben und nicht soll Um diesen Schlüssel zu haben, können Sie jetzt herausfinden, was dieser eine Schlüssel tatsächlich entsperrt, was, wenn überhaupt, etwas Anti-Sicherheit ist. Andererseits, wenn Sie sind diesen Schlüssel haben sollen und einfach vergessen haben, welches Ihrer Repositories er freischaltet, das macht das System sehr schwierig für Sie. Dies ist jedoch typisch für jedes Sicherheitssystem: Je sicherer Sie es machen, desto unpraktischer ist es, es tatsächlich zu verwenden.)

  • Lassen Sie mich kurz die Antwort geben: Es liegt an einer technischen Einschränkung, um die sich ein normaler Benutzer nicht kümmern sollte.

    – BillyTom

    31. Januar 2018 um 9:24 Uhr


  • Das Teilen von Bereitstellungsschlüsseln (normalerweise in Build-/CI-Systemen verwendet) zwischen Projekten ist aus Sicherheitssicht eine schlechte Idee, da ein kompromittierter Build-Job Zugriff auf all diese Repos erhalten könnte

    – Jarek T

    21. Februar 2019 um 10:15 Uhr

  • Dieser Workflow wird zu einem Problem, wenn automatisierte Systeme und Git-Submodule verwendet werden. Sie können denselben Bereitstellungsschlüssel nicht in mehr als einem Repo verwenden, daher besteht die Problemumgehung darin, diesen Schlüssel zu ihrem Benutzerkonto (oder einem dedizierten Computerkonto) hinzuzufügen. Die meisten Benutzer nehmen den geringsten Weg des Widerstands und fügen es ihrem eigenen Konto hinzu, was zu einem größeren Sicherheitsrisiko führt. GitHub sollte den Benutzer lieber wählen lassen und das Risiko pro Repository übernehmen …

    – tkeeler

    10. März 2020 um 20:40 Uhr

  • @tkeeler: wahrscheinlich wahr, aber ich kann weder GitHub noch Benutzer kontrollieren… 🙂

    – Torek

    10. März 2020 um 20:46 Uhr

  • @YarekT diese Situation ist eigentlich umgekehrt (der Deployer klont keine anderen App-Repos, die er dann bereitstellt), das App-Repo zieht den “Bereitstellungsassistenten”. Deshalb hieß es “Assistent” und nicht “Einsatz”. Ersteres haben wir tatsächlich auch schon (wobei es Deployment-Keys verwaltet), aber die Apps müssen sich auf ein zentralisiertes Setup verlassen, das sich vom Deployer selbst unterscheidet. Ich nehme an, ein Hack dazu wäre, den Deployer einen Bereitstellungsschlüssel für den Bereitstellungsassistenten verwenden, diesen lokal abrufen und dann den aktualisierten Code auf die Zielcomputer übertragen, anstatt sie direkt abrufen zu lassen.

    – Jon

    24. Mai 2021 um 15:38 Uhr


Eine kürzere Antwort: Die Art und Weise, wie GitHub möchte, dass Sie mit dieser Situation umgehen, besteht darin, ein separates GitHub-Konto zu erstellen, um den Server darzustellen (GitHub nennt dies einen “Maschinenbenutzer”, weitere Informationen hier), fügen Sie diesem Konto den SSH-Schlüssel hinzu und fügen Sie das Konto als Mitarbeiter zu den Repositorys hinzu, auf die Sie zugreifen möchten. Sie müssen den SSH-Schlüssel als Bereitstellungsschlüssel entfernen, bevor GitHub Ihnen erlaubt, ihn dem neuen Computerbenutzer hinzuzufügen.

  • Wenn Sie jedoch auf Organisationsrepos zugreifen möchten und diese Organisation für den Teamplan oder den Enterprise-Plan bezahlt, ist dies keine so gute Möglichkeit, dieses Problem zu lösen, da Sie mehr bezahlen müssen

    – Lukas Samcharadse

    18. November 2021 um 11:01 Uhr

1138930cookie-checkWarum kann ich einen SSH-Schlüssel nicht für mehr als ein Github-Repo verwenden?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy