J'installe gitolite sur un serveur Centos 5.9. J'ai créé l'utilisateur git, puis après SU - Git Code> J'ai réussi à obtenir ma clé publique dans le répertoire ~ / .ssh /, j'ai cloné avec succès le repo gitolite de github et avoir exécuté
gitolite / install -ln code>. L'étape suivante consiste à exécuter la configuration gitolite.
git@hostname [~]# gitolite setup -pk $HOME/admin.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
FATAL: fingerprinting failed for '/tmp/tsIx4cKWHj'
9 Réponses :
comme i mentionné avant , cela signifie que la clé SSH n'a pas été générée correctement.
Essayez: < / p> le op mwotton afin qu'il puisse saisir des touches précédentes (éventuellement corrompues) qui étaient déjà dans
C'est parce que le ssh-authkeys.fp_file () code>
fonction est appelé avec une trouvaille : p> ~ / .ssh code>. p> p>
Si j'exécute cela sur le serveur, cela générera la paire. J'ai alors besoin de transférer la clé privée à mon poste de travail. Existe-t-il un moyen de dire à mon client Git local d'utiliser ce fichier de clé juste pour cette télécommande?
J'ai vu cette réponse plus tôt aussi, mais comme elle avait initialisé les reposer, j'ai pensé que la clé doit avoir été correcte. Dans des tentatives antérieures, il avait échoué avec l'erreur d'empreintes digitales, même avant que les repos n'ait été inités, j'ai donc essayé quelques options différentes avec la clé et l'avez aussi loin.
@MWotton vous suffisez simplement copier micha code> et
micha.pub code> sur votre local
% home% \. SSH code> (Windows) ou
~ /. ssh (UNIX) code> et déclarer un fichier de configuration qui vous permettra d'utiliser ce compte spécial pour Gitolite-admin Repo (tout en créant une nouvelle paire de clés pour utiliser gitolite comme utilisateur): voir
OK, donc je spécifie la clé dans le fichier de configuration dans le dossier .git dans le repo. Cependant, j'ai toujours des problèmes - la question a été mise à jour.
@Mwotton quoi? Dans le dossier .git code>? Le fichier
config code> n'a rien à voir avec GIT: il s'agit d'un fichier de configuration SSH, dans
~ / .ssh code> (dans le côté Client B>): Voir Stackoverflow.com/Questtions/10906633/... comme exemple complet.
Ok je vais trier ça séparément. J'essaie toujours d'obtenir la commande de configuration de gitolite à fonctionner.
@mwotton à droite. Qu'est-ce qui donne un ssh-keygen -l -f '$ home / .ssh / micha' code>? Est-ce que cela suive le bon modèle.
Laissez-nous Continuer cette discussion en chat
Exécution de cette commande (sans les citations - il ne fonctionnerait pas avec les citations) donnée: 2048 33: B6: 62: 8B: B9: 58: 07: 7A: 71: 6A: 02: A5: FF: 7e: C3: 3A /home/git/.ssh/micha.pub
@Mwotton OK, cette commande d'empreintes digitales est appliquée à n'importe quelle touche trouvée dans le répertoire gitolite-admin / keydir code> ( GITUB.COM/SITARAMC/GITOLITE/BLOB/MASTER/SRC/TRIGGERS/... ). Y a-t-il une autre clé qui pourrait être "corrompue"?
Je ne semble pas avoir un répertoire gitolite-admin - au moins pas un avec un sous-répertoire appelé KeyDir. Le seul répertoire à distance close est gitolite-admin.git code> dossier, et il semble être un répertoire repo à repique nud.
@Mwotton, il devrait être nu en effet. Vous auriez besoin de le cloner pour voir son contenu.
J'ai couru à travers des étapes supplémentaires du cul ajouté à la question. Échec encore de sorte que j'ai examiné le contenu du fichier dans le répertoire TMP qui avait échoué, puis grep'ed une chaîne de ce fichier. Il a localisé la chaîne dans le fichier agréé_keys dans le répertoire ~ / .ssh. J'ai effacé ce fichier et a rendu la configuration à nouveau - cela a fonctionné!
gitolite est d'empreinte digitale toutes les clés du répertoire .sSH - y compris le fichier autorisé_keys. Supprimez toutes les touches inutiles ou corrompues du répertoire .sSH et du fichier autorisé_keys. P>
Excellent. +1. J'ai documenté votre réponse dans les miens, avec une référence au code de gitolite expliquant ce comportement.
Merci :) J'ai accepté votre réponse car elle contient à la fois des points d'échec et des solutions avec une meilleure explication technique.
Salut! Lorsque vous dites "Supprimer toutes les touches corrompues du répertoire .SSH", vous voulez dire le répertoire .ssh de notre utilisateur? (de nous gérons le repo) ou le répertoire .sSH du serveur utilisateur gitolite?
Il devrait s'agir du dossier de l'utilisateur gitolite - il ne devrait pas y avoir un utilisateur normal pour un utilisateur gitolitive. La gitolite gère l'authentification des utilisateurs de gitolite, le système ne le fait pas.
J'ai couru dans le même problème. S'est avéré que lors de la copie-pâte, j'ai inclus une nouvelle ligne dans l'une de mes clés. M'a pris un peu de temps pour le repérer ... p>
Si vous prenez la clé de pub de PuttyKegen etc .. Il sera dans plusieurs lignes avec des en-têtes comme supprimer les lignes de début et de fin, ainsi que le commentaire: ligne: . Faites toutes les lignes clés d'une ligne. et préfixe avec SSH-RSA, comme ceci: p> C'est ce qui a fonctionné pour moi. P> P>
Sinon, si vous chargez un fichier PPK ou générer une nouvelle clé de PutTygen, il existe une clé publique correctement formatée dans la boîte avec la route: «Clé publique pour coller dans OpenSSH Authored_Keys File». L'utilisation de cela élimine le potentiel de corrompre la clé publique lorsque vous le modifiez manuellement.
Pour moi, je l'ai eu en train de travailler par / bin / faux code> dans
/ etc / passwd code>). p>
C'est un peu risqué d'exécuter quelque chose comme la gitolite comme root code>. Cela indique généralement une erreur d'autorisations. Si vous êtes sûr que vos permanentes sont correctes, que diriez-vous de créer l'utilisateur code> git code> avec la possibilité de vous connecter?
Vous avez écrit, "il s'avère que gitolite était conservé les clés publiques que j'avais essayées de créer auparavant qui avait échoué."
J'ai eu le même problème. J'avais l'erreur: p>
fatale: l'empreinte digitale a échoué pour "KeyDir / jsmith.pub" em> p> J'ai supprimé la clé de défaillance du côté client et a fait un git poussé, mais toujours le même problème. Ainsi, je devais me connecter au serveur gitolite et exécuter ce qui suit: p> ceci corrigé le problème. Cela fonctionne car la documentation de gitolite, "Les fichiers Pubkey de cette poussée sont décotés dans ~ / .gitolite / keydir". Eh bien, s'il y a une erreur fatale qui se passe, les touches de pub ne seront pas placées à leur place. Il est donc possible que vous ayez peut-être même formaté vos clés SSH correctement, et cela ne sera toujours pas écrit. p> p>
J'ai essayé toute la régénération clé, la réintégrée de gitolite, le nettoyage de tous les fichiers clés, etc., tout sans succès, jusqu'à ce que j'ai commencé à regarder l'histoire de Git pour la gitolite. P>
Le problème était que la branche principale sur les repos github & google.code était cassée. J'ai vérifié la dernière version stable V3.6.4 au problème d'impression du doigt dissocié. Je pense que je peux repérer un commettre récent qui ne va-t-il pas. P>
J'ai mis à niveau la gitolite de V2 à V3, exécute installer et configurer la clé d'administration p>
force puis forcer le référentiel de configuration, tous les problèmes sont maintenant fixes. P>
Le problème que j'ai rencontré était que OpenSSH, dans ou autour de la version V6.8 modifiée le chiffrement par défaut pour une empreinte digitale (SSH-Keygen -LF Path-to-Key), il faut maintenant explicitement passer le type de chiffrement (-E MD5 ) obtenir le comportement hérité. Examiner le fichier de modifications révèle que la v3.6.5 de gitolite gérera correctement l'empreinte de style SSH (merci à Robin Johnson). Une mise à niveau de gitolite a résolu le problème pour moi. p>