it-swarm.com.de

Gitolite One User - Viele Schlüssel - Unterschiedliche Benutzernamen

Ich habe Gitolit hoffentlich nach den Anweisungen eingerichtet, und alles funktioniert wie geplant. 

Ich bin etwas unsicher, wie der Benutzernamen-Teil funktioniert, und das Durchsuchen der Dokumente hat mir nicht weitergeholfen - vielleicht fehlt mir etwas einfaches. 

Wenn ich zwei Client-Maschinen habe, die von einer realen Person verwendet werden, aber auf jeder dieser Maschinen sind die Benutzernamen, sagen wir Dave und David. Wie kann ich die Schlüssel in keydir und einer beliebigen Konfigurationsdatei so organisieren, dass sie denselben Benutzer repräsentieren? Ich bekomme die Suffix-Sache, dave @ laptop, dave @ desktop (denke ich), nur nicht, wie man unterschiedliche Client-Rechnernutzernamen verbindet, da dies beim Authentifizieren danach zu suchen scheint (vielleicht aufgrund des öffentlichen Schlüssels, der Informationen zum Benutzer @ Host enthält.) ?)

Ich kann bei Bedarf weitere Details angeben - ich wollte Sie nicht mit irrelevanten Informationen bombardieren. 

Vielen Dank.

38
Adam

Der aktuell empfohlene Weg gemäß der Dokumentation

"Am einfachsten und verständlichsten ist es, ihre Schlüssel in verschiedenen Unterverzeichnissen [in Ihrem/kedir] abzulegen (alice.pub, home/alice.pub, Laptop/alice.pub usw.). . "

referenz: http://gitolite.com/gitolite/gitolite.html#multi-key

Der alte Weg

Wenn Sie fragen, wie Sie Folgendes erreichen:

  1. David ( Heimcomputer )
  2. David ( Arbeitscomputer )
  3. David ( Laptop )

Mit verschiedenen SSH-Schlüsseln auf jedem Computer erstellen Sie einfach den Schlüssel (z. B. keygen "[email protected]") und kopieren dann den öffentlichen Schlüssel in Ihr Verzeichnis gitolite keydir (gitolite-admin/keydir). Wenn Sie dies tun, benennen Sie einfach den Schlüssel [email protected], [email protected] und [email protected]. Fügen Sie die Schlüssel zum Repository hinzu (git add keydir/.), commit (git commit -m "added David's additional keys") und git Push zum Server zurück.

Gitolite ist intelligent genug, um zu wissen, dass der Benutzername (vor dem @) immer noch david ist und dass sich der Benutzer anmelden kann und die ACL für david verwendet.

Hoffe das hilft

Um ein Szenario zu beheben, in dem Sie john_home.pubjohn_work.pub möglicherweise geöffnet haben, öffnen Sie Ihr gitolite repo (Admin-Repo) und benennen Sie die Schlüssel in Ihrer kedir in [email protected] und [email protected] commit und Push um. Jetzt kann sich Ihr Benutzer john von beiden Computern aus anmelden und denselben Benutzernamen verwenden.

Damit dies funktioniert, muss die E-Mail-Adresse in den SSH-Schlüsseln für alle Benutzerschlüssel identisch sein. Wenn Sie das obige Beispiel verwenden, sollten in den Schlüsseln [email protected], [email protected] und [email protected] alle die E-Mail-Adresse [email protected] enthalten.

Oben wurde der "alte Weg" ausgeführt, was zu einer Komplikation führen kann, wenn Sie Ihre Schlüssel in "E-Mail-Adresse" angegeben haben, im Gegensatz zu dem, was ich oben angegeben habe. Gitolite NICHT Ihren Schlüssel auf die richtige E-Mail-Adresse überprüfen. Bitte ignorieren (ich habe den ursprünglichen Kommentar der Klarheit halber gelassen).

51
Steve Ross

Für Gitolite v3 mindestens Die einfachste Lösung ist die Verwendung des hier beschriebenen Unterordnersystems http://sitaramc.github.com/gitolite/users.html

Gitolite sucht rekursiv durch das keydir und ordnet alle .pub als einen Benutzer zu. Ich verwende das Unterordnersystem jetzt mit einem Windows-Laptop und einem Linux-Entwicklungscomputer und funktioniert einwandfrei.

Die User @ Host-Konvention scheint viel zu kompliziert zu sein.

Ich mache so etwas:

 keydir 
 | --mfang 
 | | --laptop01 
 | | | --mfang.pub 
 | | --linux01 
 | | | --mfang.pub 
 | ... etc 
11
fangstar

Seit gitolite v3.5.2-10-g437b497 (September 2013, 59c817d0 ), gibt es eine noch einfachere Lösung:

ukm , für "Benutzerschlüsselverwaltung" .

Durch die Benutzerschlüsselverwaltung können bestimmte Benutzer Schlüssel hinzufügen und entfernen.

Es kann eine Delegierungsebene eingeführt werden, wenn nicht nur der gitolite-Administratorbenutzer neue öffentliche ssh-Schlüssel hinzufügen kann, sondern auch andere Benutzer.

Es erleichtert auch das Hinzufügen/Entfernen öffentlicher SSH-Schlüssel.

Sie können es in Aktion in " contrib/t/ukm.t " sehen:

Gitolite-Dokumentation enthält einen Abschnitt zu diesem Thema , aber mitukmist es einfacher (Abschnitt " Benutzer, die mehrere Schlüssel verwalten möchten "):

Ihr gitolite-Administrator erstellt Ihre gitolite-Identität mit einem Ihrer Schlüssel als Anfangsschlüssel. Dieser Schlüssel kann nur vom gitolite-Administrator verwaltet werden, nicht von Ihnen. Es bestimmt im Wesentlichen, unter welchem ​​Namen Sie Gitolit kennen.

Sie können dieser Identität neue Schlüssel hinzufügen und sie nach Belieben entfernen .

# The admin can add multiple keys for the same userid.
try "
ADDOK u5 admin u4\@example.org
ADDOK u5 admin u4\@example.org\@home
ADDOK u5 admin laptop/u4\@example.org
ADDOK u5 admin laptop/u4\@example.org\@home
";
4
VonC

Ich habe mein gitolite admin keydir ein paar Mal reorganisiert und habe immer noch nicht wirklich entschieden, wie die Dinge am besten organisiert werden können. Wenn Sie sich an einige Konventionen halten können, wird es sicherlich einfacher, aber das ist nicht immer möglich. Glücklicherweise ist Gitolit flexibel.

Im Allgemeinen ziehe ich nicht vor, ein einzelnes, flaches Verzeichnis zu verwenden, das alle Schlüssel enthält, wobei ich ausschließlich auf die Namenskonvention "[email protected]" angewiesen bin, um die Dinge klar zu halten. (Dies scheint in anderen Antworten impliziert zu sein?) Dies kann verwirrend sein, wenn Sie mehrere Schlüssel auf mehreren Hosts und mehrere Benutzernamen für einen einzelnen "echten" Benutzer haben (oder sogar den gleichen Benutzernamen für zwei verschiedene Benutzer auf zwei verschiedenen Hosts). Die Verwendung von Unterverzeichnissen hilft, Dinge zu organisieren - mit einem Baum von beliebiger Tiefe, aber normalerweise verwende ich nur eine Ebene.

Die zwei Hauptoptionen (oder sogar eine Kombination davon):

  1. ein Verzeichnis pro "realer" Benutzer, wobei jedes Verzeichnis mehrere Schlüssel für dieses Benutzers enthält (z. B. normalerweise einen pro Host). 
  2. ein Verzeichnis pro (autorisiertem) Host mit einem (oder mehreren) Schlüsseln pro Benutzer, der auf diesem Host arbeitet. Obwohl der Benutzer seinen privaten Schlüssel auf einen anderen Host kopieren kann, wird dies (in meinem Fall) nicht empfohlen. In jedem Fall werden die Unterverzeichnisse nach dem Host benannt, auf dem der Schlüssel ursprünglich generiert wurde.

Als Beispiel für ein Unterverzeichnis pro Benutzer (Option # 1):

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |--will.rodgers
 |    |--wrodgers.pub
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |...etc

Beachten Sie, dass:

  • die Verzeichnisnamen (unter keydir) spielen für gitolite keine Rolle. 
  • der Verzeichnisname sollte universell eindeutig sein, z. B. eine E-Mail-Adresse oder eine andere globale ID. Dadurch können Benutzer mit möglicherweise demselben Benutzernamen auf verschiedenen Hosts "git" werden.
  • ein Schlüssel wie "user.pub" oder "[email protected]" kann von einem Benutzer auf mehreren Hosts gemeinsam genutzt werden. Dies kann jedoch auf Grund politischer Maßnahmen entmutigt werden.

Im Allgemeinen bevorzuge ich Option # 1, die mit einigen Beispielen für Option # 2 besprüht wird. Option 2 könnte die Intranet-Automatisierung möglicherweise vereinfachen, wenn Server auf dem Server sind (z. B. Bereitstellung und Wiederverwendung von VMs), die auf Host-Ebene und nicht auf Benutzerebene verwaltet werden sollen. So können Sie beispielsweise veraltete Objekte einfach bereinigen Schlüssel auf einem außer Betrieb genommenen Host (z. B. Kurzzeittest-VM).

Das Schöne an gitolite ist, dass die (Neu-) Organisation des keydir-Verzeichnisses die Benutzer nicht beeinträchtigt. Sie können jedoch (unbeabsichtigt) leicht Ihre Benutzer (oder sich selbst) ausschließen, wenn Sie nicht aufpassen.

3
michael

Sie verbinden sich immer so:

git clone [email protected]:reponame

egal welcher Benutzer Sie sind. Gitolite identifiziert Sie anhand des von Ihnen angegebenen öffentlichen Schlüssels. Dieser Schlüssel heißt zum Beispiel dave.pub. Alles, was über eine ssh-Verbindung mit diesem öffentlichen Schlüssel gemacht wird, wird von gitolite geprüft, je nachdem, wo in der Konfigurationsdatei "dave" oder "all" verwendet wird. 

Sie können den Namen und die E-Mail-Adresse beliebig auf verschiedenen Computern und unterschiedlichen Repositories festlegen. Die Commits werden diese Informationen haben. Welcher Zweig, Baum oder welche Repositorys Sie lesen oder schreiben können, hängt davon ab, wie "dave" in der Konfigurationsdatei des Admin-Repos eingeschränkt ist - wenn Sie denselben öffentlichen/privaten Schlüssel für ssh verwenden. 

Hoffe das hilft. 

1
Adam Dymitruk

Es gibt einen subtilen Punkt, an dem jeder hier zu fehlen scheint oder zumindest nicht klar antwortet.

Das OP hat gefragt, wie mit ein und derselben PERSON gearbeitet werden soll, wobei zwei verschiedene USERNAMES und zwei unterschiedliche (zugehörige) Pub-Tasten für zwei verschiedene PLATFORMS verwendet werden.

Z.B. [email protected]_a.pub und [email protected]_b.pub repräsentieren denselben echten git-Benutzer.

Es wäre leicht genug, sowohl Dave als auch David als Benutzer in der Zeile "@known" (bekannte Benutzer) in der Datei gitolite.conf hinzuzufügen und beide Schlüssel in das Schlüsselverzeichnis zu schreiben. Es gibt jedoch keine Möglichkeit zu erkennen, ob dies zwei sind separate Benutzer oder dieselbe Person.

Z.B. "git blame" würde Dave und David als zwei getrennte Benutzer behandeln.

Abgesehen vom OP-Posten ist es eine weitere Schwierigkeit, was passiert, wenn mehrere Davids an demselben Projekt arbeiten?

Ich denke, die betroffenen Davids müssten ein System ausarbeiten (oder sich gegenseitig beschuldigen ;-).

1
Dave E

Sie installieren gitolite unter einem Benutzer auf dem Server. In der Regel git und in Ihrer SSH-Verbindungszeichenfolge verwenden Sie [email protected] immer explizit, um eine Verbindung zum Git-Benutzerkonto herzustellen. Gitolite prüft dann, welchen öffentlichen Schlüssel Sie anbieten, findet diesen in Ihrer Konfiguration und behandelt Sie, als ob Sie der zugehörige Benutzer wären.

1
Brian Campbell

Gitolite führt die Authentifizierung mit erzwungenen ssh-Befehlen durch. Jeder Benutzer, der Zugriff auf ein gitolite-Repository hat, meldet sich bei der Verwendung an, unter der gitolite installiert ist. Die Hooks nehmen neue Schlüssel im keydir und fügen sie ihrer Datei mit den autorisierten Schlüsseln hinzu, die für die Verwendung erzwungener Befehle konfiguriert ist.

Die Benutzer sind gezwungen, gitolite Shell mit einem Parameter zu verwenden, und dieser Parameter ist der Benutzername. Der folgende Abschnitt des relevanten Hooks nimmt den Dateipfad und weist ihn dem Benutzer zu. Dann werden alle Verzeichnisse und Dateien mit einem / im Namen entfernt. Was davon übrig bleibt, wird zum Benutzernamen, solange es mit .pub endet, und es wird ein einzelnes @-Zeichen vor dem .pub-Suffix ignoriert, sofern mindestens ein zusätzliches Zeichen vorhanden ist.

my $user = $f;
$user =~ s(.*/)();                # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//;    # baz.pub, [email protected] -> baz

Dies bietet Funktionalität als solche:

keydir
  |--Host1
       |--dave.pub
       |--david.pub
  |--Host2
       |--dave.pub

Die Verzeichnisse sind willkürlich, aber aus organisatorischen Gründen werden die Hosts zur Strukturierung verwendet. Sie erhalten am Ende zwei dave-Benutzer und einen david-Benutzer.

Ich verwende eine Konfiguration mehr wie folgt:

keydir
  |--steve
       |[email protected]@laptop.pub
       |[email protected]@desktop.pub
  |--services
       |--jenkins
            |[email protected]
            |[email protected]
       |--redmine
            |[email protected]
       |--jira
            |[email protected]

Wieder spielt die Verzeichnisstruktur keine Rolle. Dies gibt mir die Benutzer [email protected], jenkins, redmine und jira. Der [email protected]-Benutzer hat zwei Schlüssel sowie den jenkins-Benutzer. Wenn ich mehr als einen einzelnen Benutzer hätte, hätte ich wahrscheinlich ein Unterverzeichnis für Benutzer, das das Steve-Schlüsselverzeichnis enthält.

0
Steve Buzonas