Gitosis требует пароль, даже если предоставляется открытый ключ

Ответ 1

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

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

$ git clone ssh://[email protected]/~/gitosis-admin.git

Ответ 2

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

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

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

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

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

"git clone [email protected]: репозитории /gitosis -admin.git", и он отлично работал у меня.

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

Ответ 3

Это то, что решило проблему для меня (на Ubuntu):

git clone [email protected]:/srv/gitosis/repositories/gitosis-admin.git

Ответ 4

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

Ответ 5

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

Он работал с git clone ssh://[email protected]/absolutePath/gitosis-admin.git

Ответ 6

Редактирование authorized_keys не обязательно должно быть необходимым.

У меня когда-то была проблема авторизации, сервер gitosis продолжал спрашивать пароль, даже если бы я поместил свой открытый ключ раньше. Я понял, что gitosis дал мне предупреждение "ПРЕДУПРЕЖДЕНИЕ: gitosis.ssh: Небезопасное имя пользователя SSH в ключевом файле:" [email protected] ", когда я попытался зафиксировать и нажать мои изменения на гитоз.

Изменение пользовательской части хоста в ключевом файле и имени ключевого файла решило мою проблему. так или иначе гитоз не понравился предыдущий.

Ответ 7

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

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

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 ...

А-ха! Поскольку крюк выполнил "прогулку" через репозиторий, он нашел каталог .git под legacy.d/buildtools, и именно там произошел assert ext == '.git'.

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

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

Ответ 8

Наконец-то я начал работать так:

git clone ssh://[email protected]:1337/home/git/repositories/gitosis-admin.git

где используется 1337 порт ssh.

Ответ 9

Такая же проблема, и в моем случае было то, что у меня были неправильные authorized_keys в .ssh/. Я, должно быть, испортил это в какой-то момент...

Ответ 10

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

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

[email protected]:/var/git/repositories/project.git

до

[email protected]:repositories/project.git

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

[email protected]:project.git

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

Ответ 11

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

ssh -vvv [email protected]_host

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