Git работает по http, но не по ssh

У меня есть удаленный репозиторий, который работает нормально при общении по http, но если я использую ssh, он выдает ошибки при попытке push.

Цель: заставить репозиторий работать по ssh

Я могу напрямую подключиться к удаленной машине без проблем, все папки и файлы в git-репозитории и рабочем каталоге git имеют разрешения 771, владелец - apache, группа - 'test' (в которую входит пользователь, к которому я подключаюсь по ssh с именем 'test'). Я также попробовал изменить владельца и группу на 'test', но это не помогло. Я подтвердил, что учетная запись пользователя может читать/писать/исполнять из каталогов git по ssh.

У меня нестандартная настройка каталогов из-за использования virtualmin:
/home/test (дом пользователя)
/home/test/public_html (web root)
/home/test/public_html/git (каталог gitweb)
/home/test/public_html/git/git.git (директория репозитория)

Это вызывает такое же сообщение об ошибке, как и ниже (нет такого файла или директории), когда я выполняю любые команды git 'локально' (непосредственно на удаленном сервере), если я не указываю --git-dir и --work-tree, однако, поскольку http работает, и при проталкивании на удаленный сервер не должно быть необходимости знать удаленную рабочую директорию, я не вижу, как это может быть проблемой (и также не вижу, как это исправить, если это так).

Также, если это имеет значение, я использую аутентификацию паролем, а не ключами.

Есть ли у кого-нибудь мысли о том, как я могу решить / дополнительно диагностировать эту проблему?

Ошибка

git push origin:

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 (WHEN USING HTTP to 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 origin:

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 по ssh будет использоваться только учетная запись 'test' (а при http push будет использоваться apache), но я думаю, что это должно быть и то, и другое.

Я вернулся к нерабочему репозиторию и установил права собственности, как в рабочем репозитории (некоторые файлы/папки - apache.test, другие - test.test, а файл конфигурации - root.test).

Я не проверил абсолютно все, но файлы в дире репозитория, а также все файлы и папки в разделах objects, refs и info имеют одинаковые права собственности и разрешения как в рабочем, так и в нерабочем репозитории, а учетные записи пользователей настроены одинаково (я пробовал 777 при поиске неисправностей ранее).

Основное различие, о котором я могу думать, заключается в том, что в нерабочем репозитории я начал использовать http, а затем переключился на ssh, в то время как в рабочем репозитории я сразу перешел к использованию ssh, а до этого репозиторий был пуст. Возможно, где-то есть странный файл с неправильными разрешениями, который всё ломает, или что-то странное происходит внутри фактических файлов, которые я расстроил, используя разные протоколы, или, возможно, они просто испортились из-за моих вчерашних многочасовых попыток заставить их работать.