У меня есть удаленный репозиторий, который работает нормально, когда я общаюсь по http, но если я использую ssh, он выдает ошибки при попытке отправки.
Цель: заставить репо работать над ssh
Я могу без проблем подключиться к ssh напрямую на удаленный компьютер, все папки и файлы в рабочем каталоге git repo и git имеют разрешения 771, владелец - apache, а группа - «test» (пользователем, которым я пользуюсь ssh-ing. с «тест» является членом). Я также попытался изменить владельца и группу на «тест», но это не помогло. Я подтвердил, что учетная запись пользователя может читать / писать / выполнять из каталогов git через ssh.
У меня нестандартная настройка каталога из-за использования virtualmin:
/ home / test (дом пользователя)
/ home / test / public_html (корень сети)
/ home / test / public_html / git (каталог gitweb)
/home/test/public_html/git/git.git (каталог репозитория)
Это вызывает то же сообщение об ошибке, как показано ниже (такого файла или каталога нет), когда я выполняю какие-либо команды git «локально» (непосредственно на удаленном сервере), если только я не укажу --git-dir и --work-tree, однако Так как http работает, и отправка на удаленный сервер не должна знать удаленный рабочий каталог, я не понимаю, как это может быть проблемой (а также не вижу, как это исправить, если это было).
Также, если это уместно, я использую аутентификацию по паролю, а не по ключам.
У кого-нибудь есть мысли о том, как я могу решить / дополнительно диагностировать эту проблему?
Ошибка
происхождение git push:
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 309 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
error: unable to create temporary sha1 filename ./objects/1d: No such file or directory
fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To test@test.local:/home/test/public_html/git/git.git/
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'test@test.local:/home/test/public_html/git/git.git/'
Подробнее
git push origin (КОГДА ИСПОЛЬЗУЕТ HTTP для http://test@test.local/git/git.git/):
Password:
Password:
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 425f5c3810b1c9e4ecc7ee7df3cd1bb8818b2115
to 65d2358df3035689116339a14f504f34a6212a27
sending 3 objects
done
Updating remote server info
To http://test@test.local/git/git.git/
425f5c3..65d2358 master -> master
(Я немного сбит с толку, почему здесь так много различий между http и ssh; http дважды запрашивает мой пароль, а затем начинает получать удаленные заголовки, тогда как ssh запрашивает мой пароль один раз, а затем начинает считать объекты.)
происхождение git pull:
Already up-to-date
git remote show origin:
* remote origin
Fetch URL: test@test.local:/home/test/public_html/git/git.git/
Push URL: test@test.local:/home/test/public_html/git/git.git/
HEAD branch: master
Remote branches:
master tracked
release tracked
Local branches configured for 'git pull':
master merges with remote master
release merges with remote release
Local refs configured for 'git push':
master pushes to master (fast-forwardable)
release pushes to release (up to date)
И если он мне нужен, мой локальный конфигурационный файл:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = test@test.local:/home/test/public_html/git/git.git/
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "release"]
remote = origin
merge = refs/heads/release
И удаленный конфигурационный файл:
[core]
repositoryformatversion = 0
filemode = true
bare = false
worktree = /home/test/public_html
sharedRepository = true
Дальнейшее расследование
После комментариев Яна я немного углубился в проблему. Я предполагал, что во время push over ssh будет использоваться только «тестовая» учетная запись (и apache используется через http push), но я думаю, что это должно быть и то, и другое.
Я вернулся через нерабочее хранилище и установил владельца так же, как и в рабочем хранилище (некоторые файлы / папки - apache.test, другие - test.test, а файл конфигурации - root.test).
Я не проверял абсолютно все, но файлы в директории репозитория, а также все файлы и папки в объектах, ссылках и информации имеют одинаковые права владения и разрешения как в рабочем, так и в нерабочем состоянии, а учетные записи пользователей настраиваются в таким же образом (я пробовал 777 в моем устранении проблем ранее).
Основное отличие, которое я могу себе представить, заключается в том, что в нерабочем репо я начал использовать http, а затем переключился на ssh, тогда как в рабочем репо я сразу перешел к использованию ssh, и до этого репо было пустым. Возможно, где-то есть какой-то странный файл с неправильными разрешениями, который нарушает все, или что-то странное происходит в реальных файлах, которые я расстроил, используя разные протоколы, или, возможно, он просто испортился из-за моих попыток заставить его работать вчера.