Gitosis nécessite un mot de passe, même si la clé publique est donnée

Question

je suis confronté à des problèmes en essayant de configurer gitosis sur mon Archlinux

http://wiki.archlinux.org/index.php/Setting_Up_Git_ACL_Using_gitosis

Je renvoie à cet article wiki et gitosis installé avec succès.

$ sudo pacman -U gitosis-git-20090525-1-i686.pkg.tar.gz
$ sudo -H -u gitosis gitosis-init < /tmp/id_rsa.pub

Et modifié /srv/gitosis/.ssh/authorized_keys pour inclure id_rsa.pub de mon utilisateur local.

Mais quand je lance git clone comme l'utilisateur local,

$ git clone gitosis @ host: gitosis-admin.git

Il dit

Initialisé dépôt Git vide dans /home/wyx/gitosis-admin/.git/
gitosis@10.132.140.73 mot de passe: *****
fatale: 'gitosis-admin.git' ne semble pas être un dépôt git
fatale: L'extrémité distante a raccroché inopinément

Ainsi l'opération de clone git échoué. Je me demande pourquoi il essaie d'initialiser un dépôt git vide dans le répertoire de mon utilisateur local (/ home/wyx)? Et comme j'ai déjà ajouté id_rsa.pub de l'utilisateur local dans .ssh/authorized_keys, pourquoi demande-t-il toujours un mot de passe?

Answer 1

Un référentiel vide a été créé car c'est exactement comme ça que git fonctionne: il doit initier un repo avant de pouvoir commencer à y insérer des objets distants. Malheureusement, cela signifie que vous devrez supprimer manuellement le repo vide avant de recommencer le clonage. En ce qui concerne les raisons pour lesquelles le clone a échoué, il semble que vous utilisiez la mauvaise syntaxe pour le chemin du référentiel distant; git clone n'utilise pas la syntaxe scp. En fait, si vous ne spécifiez pas un protocole de clonage, je crois qu'il suppose le protocole git plutôt que ssh, ce qui serait probablement la raison pour laquelle il vous a demandé un mot de passe. Essayez ceci:

 
$ git clone ssh://gitosis@host/~/gitosis-admin.git 

Answer 2

Gitosis crée propre fichier authorized_keys est tout. Si vous avez déjà ce fichier, supprimez-le et autorisez gitosis-init à le recréer. Une fois cela fait, ne plaisante pas avec le fichier.

Answer 3

J'ai également fait face au même problème "fatal: '/gitosis-admin.git' ne semble pas être un référentiel valide." J'ai beaucoup cherché pour le problème et finalement trouvé la solution.

En fait, l'adresse par défaut de l'utilisateur de la gitose est "/ srv/gitosis": Comme dans le cas de mon installation avec le serveur 10.04 d'ubuntu. Et lorsque nous écrivons "git clone gitosis@server.com: gitosis-admin.git", il recherche le dépôt gitosis-admin.git dans/srv/gitosis.Donc, quand je suis entré dans le/srv/gitosis, j'ai découvert qu'il y avait un autre dépôt à l'intérieur nommé dépôts qui se compose du dépôt gitosis-admin.git. En fait, par défaut, gitosis-admin.git n'était pas dans l'emplacement par défaut. Je dois donc modifier le chemin de commande, puis cela a bien fonctionné. J'ai récupéré le référentiel cloné sur ma machine locale. J'ai utilisé la commande en tant que:

"git clone gitosis@server.com: repositories/gitosis-admin.git" et cela a bien fonctionné pour moi.

Voir pour le répertoire gitosis-admin dans votre cas et j'espère que vous serez en mesure de résoudre votre problème.

Answer 4

J'ai finalement obtenu ce travail comme celui-ci

git clone ssh://git@host:1337/home/git/repositories/gitosis-admin.git 

où 1337 le ssh port utilise.

Answer 5

C'est ce que résolu le problème pour moi (sur Ubuntu):

git clone gitosis@ns.home:/srv/gitosis/repositories/gitosis-admin.git 

Answer 6

J'ai eu le même problème sur ubuntu,

Il a travaillé avec git clone ssh://git@serverName/absolutePath/gitosis-admin.git

Answer 7

Modification authorized_keys ne devrait pas être nécessaire normalement.

J'ai déjà eu un problème d'autorisation, le serveur de gitose ne cessait de me demander un mot de passe même si j'avais déjà placé ma clé publique. J'ai réalisé que la gitose m'a donné un avertissement "ATTENTION: gitosis.ssh: Nom d'utilisateur SSH dangereux dans le fichier de clés: 'myuser@myserver.pub'" quand j'ai essayé de commettre et de pousser mes changements à la gitose.

La modification de la partie utilisateur @ hôte dans le fichier de clés et le nom du fichier de clés a résolu mon problème. en quelque sorte, la gitose n'a pas aimé la précédente.

Answer 8

Même problème, et dans mon cas, c'était que j'avais des fausses touches autorisées dans .ssh /. Je dois avoir foiré à un moment donné ...

Answer 9

Après avoir déménagé à une nouvelle machine Ubuntu et rencontrer moi-même cette question, j'ai vu quelques réponses ici qui m'ont fait bouger dans la bonne direction, à savoir en utilisant un absolu chemin d'accès aux fichiers .git pour chaque référentiel.

L'expérimentation un peu j'ai remarqué des chemins relatifs au répertoire git accueil de l'utilisateur a également travaillé, ce qui raccourci quelque chose comme:

git@host:/var/git/repositories/project.git 

jusqu'à

git@host:repositories/project.git 

Jouer un peu plus j'essayé de déplacer le projet les fichiers des dépôts directement dans le répertoire personnel de git; maintenant seul le projet est requis:

git@host:project.git 

C'est un peu hacky, mais je doute que cela causera des dommages. Serait bon de savoir ce qui a changé, car j'hébergeais la gitose sur un autre Ubuntu (plus ancien) et pouvions avoir les projets dans le répertoire des dépôts avec la dernière notation ci-dessus.

Answer 10

J'ai résolu un problème similaire.Ce n'est peut-être pas exactement ce qui se passe dans votre cas, mais vous pouvez essayer de réappliquer le même dépannage que j'ai fait. Je me suis rendu compte que lorsque je poussais des touches pour un nouvel utilisateur, je recevais ce stacktrace, qui est le symptôme que le hook sur gitosis n'a pas réussi à traiter la nouvelle clé.

remote: Traceback (most recent call last): 
remote: File "/usr/local/bin/gitosis-run-hook", line 9, in <module> 
remote:  load_entry_point('gitosis==0.2', 'console_scripts', 'gitosis-run-hook')() 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 24, in run 
remote:  return app.main() 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 38, in main 
remote:  self.handle_args(parser, cfg, options, args) 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 81, in handle_args 
remote:  post_update(cfg, git_dir) 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 45, in post_update 
remote:  config=cfg, 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 95, in set_export_ok 
remote:  for (dirpath, repo, name) in walk_repos(config): 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 72, in walk_repos 
remote:  assert ext == '.git' 
remote: AssertionError 

L'erreur montrait que UNE FOIS, donc je naïvement rejeté comme un échec momentané. En pratique, Gitosis ne fonctionnait que pour ma clé, mais elle ne fonctionnait pas pour aucun des utilisateurs que j'essayais de supporter. Dans le ~/.ssh/authorized_keys je ne pouvais pas trouver la clé publique de l'utilisateur que je pensais que je venais d'ajouter. C'est pourquoi mon ami continuait à se faire demander son mot de passe chaque fois qu'il tentait de le cloner.

j'ai ajouté le débogage à la configuration Gitosis, en ajoutant ces deux lignes à gitosis.conf

[gitosis] 
loglevel=DEBUG 

je devais continuer à ajouter et supprimer des utilisateurs dans le fichier gitosis.conf de sorte que le crochet serait déclenché à nouveau. Mon journal de débogage a révélé

remote: DEBUG:gitosis.gitdaemon:Deny 'syncShare' 
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d', seeing ['buildtools', 'QA_Dashboard'] 
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d/buildtools', seeing ['.git', 'conf', 'scripts'] 
remote: Traceback (most recent call last): 
etc ... 

A-ha! Comme le crochet effectué la "promenade" à travers le référentiel, il avait trouvé un répertoire .git sous legacy.d/buildtools et c'est exactement où le assert ext == '.git' s'est produit.

J'avais utilisé le serveur pour stocker un simple clone provenant d'un autre référentiel. Remarquez, un clone simple, pas un miroir ou un dépôt nu. Comme chaque clone, il contenait le répertoire .git.

Le hook dans Gitosis ne sait pas quoi faire avec un répertoire .git. Il pense que c'est un référentiel dans un nom vide et abandonne. Une fois que j'ai éliminé ce clone, tout a bien fonctionné.

Answer 11

Pour obtenir un meilleur aperçu des questions auth, d'obtenir des détails verbeux du journal de débogage: en utilisant un

ssh -vvv gitosis@gitosis_host

directe trick manuel de connexion (qui, formulée le plus important/en général, utilise en fait la plus précise/référence directe au contexte, dans ce cas: mécanismes ssh réels plutôt que l'outil distant - et donc par nécessité moins précise - git handling!).