Gitosis требует пароль, хотя открытый ключ

Question

Я сталкиваюсь с некоторыми проблемами при попытке настроить гитоз на моем Archlinux

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

Я ссылался на эту статью в вики и успешно установил gitosis.

$ sudo pacman -U gitosis-git-20090525-1-i686.pkg.tar.gz
$ sudo -H -u gitosis gitosis-init

И изменил /srv/gitosis/.ssh/authorized_keys для включения id_rsa.pub моего локального пользователя.

Но когда я запускаю git clone как локальный пользователь,

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

Там написано

Инициализированный пустой репозиторий Git в /home/wyx/gitosis-admin/.git/
gitosis@10.132.140.73 пароль: *****
фатальный: gitosis-admin.git не является репозиторием git
фатальный: удаленный конец неожиданно зависает

Итак, операция git clone завершилась неудачно. Мне интересно, почему он пытается инициализировать пустой репозиторий git в каталоге моего локального пользователя (/ home / wyx)? И так как я уже добавил id_rsa.pub локального пользователя в .ssh / authorized_keys, почему он все еще запрашивает пароль?

Answer 1

Был создан пустой репозиторий, потому что именно так работает git: он должен инициировать репо, прежде чем он сможет начать втягивать в него удаленные объекты. К сожалению, это означает, что вам придется вручную удалить пустое хранилище, прежде чем снова попытаться клонировать.

Что касается причины сбоя клона, похоже, вы используете неправильный синтаксис для пути к удаленному репозиторию; git clone не использует синтаксис scp. На самом деле, если вы не укажете протокол клонирования, я полагаю, что он использует протокол git, а не ssh, что, вероятно, было причиной, по которой он запрашивал пароль. Попробуйте вместо этого:

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

Answer 2

Я также столкнулся с той же проблемой «фатально:« /gitosis-admin.git »не является допустимым хранилищем». Я много искал проблему и, наконец, нашел решение.

На самом деле адрес пользователя gitosis по умолчанию - "/ srv / gitosis": как и в случае моей установки с сервером Ubuntu 10.04.

И когда мы пишем "git clone gitosis@server.com: gitosis-admin.git", он ищет gitosis-admin.git репозиторий в / srv / gitosis. Поэтому, когда я вошел в / srv / gitosis, я обнаружил, что внутри него есть другой репозиторий, называемый репозиторием, который состоит из репозитория gitosis-admin.git.

Так что на самом деле по умолчанию gitosis-admin.git не был в местоположении по умолчанию. Таким образом, я должен изменить командный путь, и тогда он работал нормально.

Я скопировал хранилище на мою локальную машину. Я использовал команду как:

"git clone gitosis@server.com: repositories / gitosis-admin.git", и у меня это работало нормально.

См. Каталог gitosis-admin в вашем случае, и я надеюсь, что вы сможете решить вашу проблему.

Answer 3

Вот что для меня решило проблему (в Ubuntu):

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

Answer 4

Gitosis создает свой собственный файл authorized_keys. Если у вас уже есть этот файл, удалите его и позвольте gitosis-init воссоздать его. Как только это будет сделано, не связывайтесь с файлом.

Answer 5

Я решил похожую проблему. Возможно, это не совсем то, что происходит в вашем случае, но вы можете попробовать применить то же устранение неисправностей, что и я.

Я понял, что когда я нажимал клавиши для нового пользователя, я получал эту трассировку стека, что является признаком того, что ловушка на жито не смогла обработать новый ключ.

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

Ошибка показала только ONCE , поэтому я наивно отклонил это как кратковременный сбой.

На практике Gitosis работал только для моего ключа, но не работал ни для одного из пользователей, которых я пытался поддерживать. В ~/.ssh/authorized_keys я не смог найти открытый ключ пользователя, который, как мне показалось, я только что добавил. Вот почему моего друга постоянно спрашивали пароль каждый раз, когда он пытался клонировать.

Я добавил отладку в конфигурацию Gitosis, добавив эти две строки в gitosis.conf

[gitosis]
loglevel=DEBUG 

Мне приходилось продолжать добавлять и удалять пользователей в файле gitosis.conf, чтобы перехват снова запускался. Мой журнал отладки показал

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-ха! Когда хук выполнил «обход» через репозиторий, он обнаружил каталог .git в legacy.d/buildtools, и именно там произошел assert ext == '.git'.

Я использовал сервер для хранения простого клона из какого-то другого хранилища. Обратите внимание, простой клон, а не зеркало или голое хранилище. Как и любой клон, он содержал каталог .git.

Хук в Gitosis не знает, что делать с каталогом .git. Он думает, что это хранилище с пустым именем и прерывает работу. Как только я уничтожил этот клон, все снова заработало.

Answer 6

У меня была такая же проблема на Ubuntu,

Работает с git clone ssh://git@serverName/absolutePath/gitosis-admin.git

Answer 7

Редактирование авторизованных ключей обычно не требуется.

Однажды у меня возникла проблема с авторизацией, сервер gitosis продолжал спрашивать меня пароль, даже если я ранее разместил свой открытый ключ. Я понял, что gitosis дал мне предупреждение «ПРЕДУПРЕЖДЕНИЕ: gitosis.ssh: Небезопасное имя пользователя SSH в ключевом файле:« myuser@myserver.pub »», когда я попытался зафиксировать и отправить свои изменения в gitosis.

Изменение части user @ host в файле ключей и имени файла ключей решило мою проблему. почему-то житоз не понравился предыдущий.

Answer 8

Чтобы лучше понять проблемы с аутентификацией, соберите подробные данные журнала отладки: с помощью

ssh -vvv gitosis@gitosis_host

Прямой трюк с ручным подключением (который сформулирован наиболее важно / обычно, на самом деле использует самую точную / прямую контекстную ссылку; в данном случае: реальные механизмы ssh, а не инструментальные - и, следовательно, по необходимости менее точные - обработка git !).

Answer 9

Переехав на новую машину с Ubuntu и сам разбираясь с этим вопросом, я увидел здесь пару ответов, которые заставили меня двигаться в правильном направлении, а именно использовать абсолютный путь к файлам .git для каждый репозиторий.

Немного поэкспериментировав, я заметил, что пути относительно домашнего каталога пользователя git также работали, что сокращало что-то вроде:

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

до

git@host:repositories/project.git

Играя немного больше, я попытался переместить файлы проекта из репозиториев прямо в домашний каталог git; сейчас требуется только проект:

git@host:project.git

Это немного смешно, но я сомневаюсь, что это причинит какой-либо вред. Было бы полезно узнать, что изменилось, так как я размещал gitosis в другой Ubuntu (более старой версии) и мог размещать проекты в каталоге репозиториев с последней записью сверху.

Answer 10

Та же проблема, и в моем случае было то, что у меня неправильно авторизованные_ключи в .ssh /. Должно быть, я все испортил в какой-то момент ...