Gitolite One User - Many Keys - Différents noms d'utilisateurs
J'espère que j'ai installé gitolite conformément aux instructions, et tout fonctionne comme prévu.
Je ne suis pas sûr de savoir comment fonctionne la partie noms d'utilisateurs, et parcourir la documentation ne m'a pas aidé - il me manque peut-être quelque chose de simple.
Si j'ai deux machines clientes, destinées à une seule personne réelle, mais sur chacune de ces machines, les noms d'utilisateur sont, disons dave et david. Comment organiser les clés dans keydir et n'importe quel fichier de configuration de sorte qu'elles représentent toutes les deux le même utilisateur? J'obtiens le suffixe, dave @ laptop, dave @ desktop (je pense), mais je ne sais pas comment connecter différents noms d'utilisateur de machine client, car cela semble chercher cela lors de l'authentification (peut-être à cause de la clé publique contenant les informations utilisateur @ hôte ?)
Je peux donner plus de détails si nécessaire - je ne voulais tout simplement pas vous bombarder avec des informations non pertinentes.
Merci beaucoup.
La manière recommandée actuellement selon la documentation
"Le plus simple et le plus compréhensible consiste à placer leurs clés dans différents Sous-répertoires [dans votre/kedir], (alice.pub, home/alice.pub, Laptop/alice.pub, etc.) . "
référence: http://gitolite.com/gitolite/gitolite.html#multi-key
À l'ancienne
Si vous demandez comment vous accomplissez les tâches suivantes:
- David ( ordinateur à la maison )
- David ( ordinateur de travail )
- David ( ordinateur portable )
Avec différentes clés SSH sur chaque ordinateur, vous créez simplement la clé (par exemple: keygen "[email protected]"), puis copiez la clé publique dans votre répertoire gitolite keydir (gitolite-admin/keydir). Lorsque vous faites cela, il vous suffit de nommer la clé [email protected], [email protected] et [email protected]. Ajoutez les clés au référentiel (git add keydir/.), commit (git commit -m "added David's additional keys") et git Push au serveur.
Gitolite est suffisamment intelligent pour savoir que, même s'il s'agit d'une clé différente, le nom d'utilisateur (avant le @) est toujours david et laissera cet utilisateur se connecter et utiliser la liste de contrôle d'accès pour david.
J'espère que cela t'aides
Pour résoudre un scénario dans lequel vous pourriez avoir john_home.pubjohn_work.pub, ouvrez votre référentiel gitolite (référentiel admin) et renommez les clés de votre kedir en [email protected] et [email protected] commit et Push. Désormais, votre utilisateur john peut se connecter à partir de l’un ou l’autre ordinateur et utiliser le même nom d’utilisateur.
N'oubliez pas que pour que cela fonctionne, l'adresse de messagerie dans les clés SSH doit être la même pour toutes les clés de l'utilisateur. Donc, en utilisant l'exemple ci-dessus, dans les clés [email protected], [email protected] et [email protected], toutes devraient avoir l'adresse de messagerie [email protected].
Ci-dessus, c’était la "vieille manière" de faire cela et cela pouvait entraîner une complication si vous avez nommé vos clés de la manière "adresse e-mail" contrairement à ce que j’ai dit ci-dessus. Veuillez ignorer (j'ai laissé le commentaire original pour plus de clarté).
Pour Gitolite v3 au moins , la solution la plus simple consiste à utiliser le système de sous-dossiers documenté ici http://sitaramc.github.com/gitolite/users.html
Gitolite effectuera une recherche récursive dans le keydir et associera tous les fichiers .pub à un seul utilisateur. J'utilise maintenant le système de sous-dossiers avec un ordinateur portable Windows et une machine de développement Linux.
La convention utilisateur @ hôte semble trop compliquée.
Je fais quelque chose comme ça:
keydir | --mfang | | --laptop01 | | | --mfang.pub | | --linux01 | | | --mfang.pub | ... etc
Depuis gitolite v3.5.2-10-g437b497 (septembre 2013, commettez 59c817d0 ), il existe une solution encore plus simple:
ukm , pour "gestion de clé utilisateur" .
La gestion des clés utilisateur permet à certains utilisateurs d’ajouter et de supprimer des clés.
Il peut introduire un niveau de délégation, lorsque l'utilisateur admin de gitolite peut non seulement ajouter de nouvelles clés publiques ssh, mais que d'autres utilisateurs peuvent également le faire.
Cela facilite également l’ajout/la suppression de clés ssh publiques.
Vous pouvez le voir en action dans " contrib/t/ukm.t ":
La documentation Gitolite inclut une section sur ce sujet , mais avecukm, il est plus facile (section " Utilisateurs qui souhaitent gérer plusieurs clés "):
Votre administrateur gitolite crée votre identité gitolite avec une de vos clés comme clé initiale. Cette clé ne peut être gérée que par l'administrateur de gitolite, pas par vous. Cela détermine fondamentalement sous quel nom vous êtes connu de gitolite.
Vous pouvez ajouter de nouvelles clés à cette identité et les supprimer à votre guise .
# 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
";
J'ai réorganisé mon administrateur gitolite keydir à quelques reprises et je n'ai toujours pas vraiment décidé quelle est la meilleure façon d'organiser les choses. Si vous pouvez vous en tenir à certaines conventions, les choses seront certainement plus faciles, mais ce n’est pas toujours possible. Heureusement, la gitolite est flexible.
En général, je préfère pas utiliser un seul répertoire plat contenant toutes les clés, en s'appuyant sur uniquement sur la convention de dénomination "[email protected]" pour que tout soit clair. (Cela semble être impliqué dans d'autres réponses?) Cela peut devenir déroutant si vous avez plusieurs clés sur plusieurs hôtes et plusieurs noms d'utilisateur pour un seul "vrai" utilisateur (ou même le même nom d'utilisateur pour deux utilisateurs différents sur deux hôtes différents). Utiliser des sous-répertoires aide à organiser les choses - en utilisant un arbre de n'importe quelle profondeur, mais en général, je n'utilise qu'un niveau.
Les deux options principales (ou même une combinaison de celles-ci):
- un répertoire par utilisateur "réel", chaque répertoire contenant plusieurs clés pour cet utilisateur (par exemple, généralement un par hôte).
- un répertoire par hôte (autorisé), avec une (ou plusieurs) clé (s) par utilisateur devant fonctionner sur sur cet hôte. Bien que l’utilisateur puisse copier sa clé privée sur un autre hôte , C’est (dans mon cas) découragé. Dans tous les cas, les sous-répertoires portent le nom de l'hôte sur lequel la clé a été générée.
A titre d'exemple d'un sous-répertoire par utilisateur (option n ° 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
Notez que:
- les noms de répertoires (sous keydir) n’ont aucune importance pour gitolite.
- le nom du répertoire doit être unique, tel qu'une adresse électronique ou un autre ID global. Cela permet aux utilisateurs "git" avec potentiellement le même nom d'utilisateur sur différents hôtes.
- une clé telle que "user.pub" ou "[email protected]" peut être partagée par un utilisateur sur plusieurs hôtes; faire cela peut être découragé en fonction de la politique, cependant.
En général, je préfère et utilise l’option n ° 1, saupoudrée de quelques exemples de l’option n ° 2. L'option 2 pourrait éventuellement simplifier l'automatisation de l'intranet si vous avez des serveurs qui vont et viennent (peut-être l'approvisionnement et le recyclage des ordinateurs virtuels) et souhaitez conserver les éléments au niveau de l'hôte plutôt qu'au niveau de l'utilisateur, afin que vous puissiez (par exemple) nettoyer facilement les éléments obsolètes clés sur un hôte mis hors service (par exemple, une machine virtuelle de test à court terme).
Le bon côté de gitolite est que la (ré) organisation du répertoire keydir n’a pas d’impact sur les utilisateurs. Mais vous pouvez facilement (par inadvertance) verrouiller vos utilisateurs (ou vous-même) si vous ne faites pas attention.
Vous vous connectez toujours comme ça:
git clone gitoliteuser@gitoliteserver:reponame
peu importe quel utilisateur vous êtes. Gitolite vous identifie par la clé publique que vous fournissez. Cette clé s'appelle dave.pub, par exemple. Tout ce qui est fait via une connexion ssh avec cette clé publique sera scruté par gitolite selon le lieu où "dave" ou "all" est utilisé dans le fichier de configuration.
Vous êtes libre de définir le nom et l'adresse électronique de manière à ce que vous souhaitiez sur différentes machines et différents référentiels. Les commits auront cette information. Mais quelle branche, quelle arborescence ou quels référentiels vous pouvez lire ou écrire est dictée par la manière dont "dave" est limité dans le fichier de configuration du référentiel - si vous utilisez la même clé publique/privée pour ssh.
J'espère que cela t'aides.
Il y a un point subtil qui manque à tout le monde ici, ou du moins ne répond pas clairement.
Le PO a demandé comment gérer la même PERSONNE à l'aide de deux USERNAMES différents et de deux clés de publication différentes (associées) sur deux plates-formes différentes.
Par exemple. dave@platform_a.pub et david@platform_b.pub représentent tous deux le même utilisateur git réel.
Il serait assez facile d’ajouter dave & david en tant qu’utilisateurs de la ligne "@known" (utilisateurs connus) du fichier gitolite.conf et de placer les deux clés dans le keydir, mais il n’existe aucun moyen de déterminer s’il s’agit de deux. utilisateurs distincts, ou la même personne.
Par exemple. "Git Blame" traiterait Dave et David comme deux utilisateurs distincts.
Au-delà du poste de l'OP, une complication supplémentaire est ce qui se passe si plusieurs Davids travaillent sur le même projet?
Je suppose que les Davids concernés devraient élaborer un système (ou se contenter de se blâmer les uns les autres ;-).
Vous installez gitolite sous un utilisateur sur le serveur; généralement git, et dans votre chaîne de connexion SSH, vous utilisez toujours explicitement git@servername pour vous connecter au compte utilisateur Git. Gitolite examinera ensuite la clé publique que vous proposez, la trouvera dans votre configuration et vous traitera comme si vous étiez l'utilisateur associé.
Gitolite effectue l'authentification avec les commandes forcées ssh. Chaque utilisateur ayant accès à un référentiel gitolite se connecte à l’utilisation sous laquelle gitolite est installé. Les crochets prennent les nouvelles clés dans le keydir et les ajoutent à son fichier de clés autorisées configuré pour utiliser des commandes forcées.
Les utilisateurs sont obligés d'utiliser gitolite Shell avec un paramètre, et ce paramètre est le nom d'utilisateur. La partie suivante du hook approprié prend le chemin du fichier et l'assigne à l'utilisateur, puis supprime tous les répertoires et fichiers avec un / dans le nom. ce qui reste deviendra le nom d'utilisateur tant qu'il se terminera par .pub et qu'un seul signe @ précédant le suffixe .pub sera ignoré tant qu'il y aura au moins un caractère supplémentaire.
my $user = $f;
$user =~ s(.*/)(); # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//; # baz.pub, [email protected] -> baz
Cela fournit une fonctionnalité en tant que telle:
keydir
|--Host1
|--dave.pub
|--david.pub
|--Host2
|--dave.pub
Les répertoires sont arbitraires mais, à des fins d'organisation, les hôtes sont utilisés pour structurer. Vous vous retrouvez avec deux utilisateurs dave et un utilisateur david.
J'utilise une configuration plus semblable à ceci:
keydir
|--steve
|[email protected]@laptop.pub
|[email protected]@desktop.pub
|--services
|--jenkins
|[email protected]
|[email protected]
|--redmine
|[email protected]
|--jira
|[email protected]
Encore une fois, la structure du répertoire n'a pas d'importance. Cela me donne les utilisateurs [email protected], jenkins, redmine et jira. L'utilisateur [email protected] a deux clés ainsi que l'utilisateur jenkins. Si j'avais plus d'un utilisateur, j'aurais probablement un sous-répertoire users contenant le répertoire steve key.