Verwaltung öffentlicher SSH-Schlüssel in Repositories von Github-Organisationen

Ich habe mich gefragt, ob jemand eine gute, saubere und sichere Möglichkeit hat, den Zugriff auf das GitHub-Organisations-Repository auf seinen Servern zu verwalten?

Es scheint, dass Sie Pub-Schlüssel nur an Ihr persönliches Konto anhängen und den Zugriff nicht nur auf eine Organisation beschränken können.

Wir haben einen Beta-Server, auf dem wir mehrere Projekte ablegen, also ist das Bereitstellen von Schlüsseln nicht ideal, da sie eindeutig sein müssen. Es wäre schön, der Organisation globalen Zugriff zu geben, aber ich möchte dem Server, auf dem wir Freiberufler haben, keinen vollen Zugriff auf mein persönliches Konto geben (Der Server bekommt Zugriff auf die Organisation, was gut ist, aber auch zu meinen persönlichen Projekten und jeder anderen Organisation, der ich angehöre, was schlecht ist).

Die beiden Problemumgehungen, die ich sehe, bestehen darin, entweder einen Dummy-Github-Benutzer einzurichten, der durchzugehen scheint, was dumm erscheint, oder die ssh-Agentenweiterleitung zu aktivieren, was sich wie ein Sicherheitsrisiko anfühlt (ich bin nicht der beste Serveradministrator).

Ein Freund schlug vor, den Server als Remote zum Pushen einzurichten, aber es scheint eine Lösung für ein Pflaster zu sein.

Ich würde mir vorstellen, dass es eine einfachere Möglichkeit gibt, den Zugriff auf das Repo einer Organisation einzurichten, da ich denke, dass dies ein grundlegendes Bedürfnis für alle wäre.

Ich bin ganz Ohr, wenn jemand etwas teilen möchte, das für seine Github-Organisation funktioniert/arbeitet.

Ich werde wahrscheinlich einfach in den sauren Apfel beißen und einen Dummy-Github-Benutzer erstellen und Schluss machen, ich muss die Arbeit erledigen.

Eine Alternative zur Antwort von sergey_mo (und als direkte Antwort auf die letzte Frage von Michał Szajbe) besteht darin, mehrere SSH-Schlüssel zu erstellen, wie von Chalien auf Githib dokumentiert:

https://gist.github.com/jexchan/2351996

Ich verstehe nicht, warum das Hinzufügen eines Dummy-Kontos für die automatische Bereitstellung so schlecht ist, solange Sie Ihren eigenen Beta-Server als Staging-Bereich betreiben, bevor Sie auf GitHub pushen. Das heißt, wenn Sie möchten, dass der Betacode privat ist.

Der übliche GitHub-Weg wäre, alle Mitarbeiter hinzuzufügen und einfach ein stabiles Projekt und einen Beta-Fork zu haben. Sie würden die aktuelle Beta-Version zum Testen automatisch auf Ihren Beta-Server ziehen (dort ist kein ssh-Schlüssel erforderlich) und wenn Ihre Tests erfolgreich sind, ziehen Sie die Zusammenführungen aus dem Beta-Fork in das stabile Projekt.

Kleiner Hinweis zu CI:
Wenn Sie beispielsweise Jenkins verwenden und es benötigen, um auf mehr als ein Projekt zuzugreifen, müssen Sie Folgendes tun:
1. öffentlichen Schlüssel zu einem Github-Benutzerkonto hinzufügen
2. fügen Sie diesen Benutzer als Eigentümer (um auf alle Projekte zuzugreifen) oder als Mitarbeiter in jedem Projekt hinzu.

Viele öffentliche Schlüssel für einen Systembenutzer funktionieren nicht, da GitHub den ersten übereinstimmenden Bereitstellungsschlüssel findet und Fehler wie zurücksendet “FEHLER: Berechtigung für Benutzer/repo2 für Benutzer/repo1 verweigert”

http://help.github.com/ssh-issues/

Sie können dies umgehen, indem Sie Ihre Anwendungen von verschiedenen Benutzern ausführen lassen (ein Benutzer pro Anwendung). Ich meine Serverbenutzer, nicht Github-Benutzer. Auf Multi-App-Servern ist es sowieso eine gute Praxis.

Jeder Benutzer hat dann sein eigenes SSH-Schlüsselpaar, sodass Sie viele eindeutige Bereitstellungsschlüssel haben (einen pro Github-Repo).

Ich verwende diesen Ansatz, wann immer es möglich ist. Es gibt jedoch Situationen, in denen mehr als eine App von einem einzelnen Benutzer ausgeführt wird und dies wahrscheinlich nicht mit den Bereitstellungsschlüsseln von github möglich ist. Ich suche auch nach einer guten Lösung für solche Fälle.