Git funktioniert über http, aber nicht über ssh

Question

Ich habe ein entferntes Repository, das gut funktioniert, wenn ich über http kommuniziere, aber wenn ich ssh verwende, bekomme ich Fehler, wenn ich versuche zu pushen.

Ziel: das Repo über ssh zum Laufen zu bringen

Alle Ordner und Dateien im Git-Repository und im Git-Arbeitsverzeichnis haben die Berechtigung 771, der Eigentümer ist apache und die Gruppe ist "test" (der Benutzer, mit dem ich mich per SSH anmelde, ist Mitglied von "test"). Ich habe auch versucht, den Besitzer und die Gruppe auf "test" zu ändern, aber das hat nicht geholfen. Ich habe bestätigt, dass das Benutzerkonto in der Lage ist, die Git-Verzeichnisse per SSH zu lesen/schreiben/auszuführen.

Ich habe ein nicht standardisiertes Verzeichnis-Setup, da ich virtualmin verwende:
/home/test (Benutzerheimat)
/home/test/public_html (Web-Root)
/home/test/public_html/git (Gitweb-Verzeichnis)
/home/test/public_html/git/git.git (Repo-Verzeichnis)

Dies verursacht die gleiche Fehlermeldung wie unten (keine solche Datei oder Verzeichnis), wenn ich alle Git-Befehle "lokal" (direkt auf dem Remote-Server), es sei denn, ich angeben --git-dir und --work-tree, jedoch, da http funktioniert und Pushing auf den Remote-Server sollte nicht das Remote-Arbeitsverzeichnis wissen müssen, ich sehe nicht, wie dies das Problem sein würde (und auch nicht sehen, wie es zu beheben, wenn es war).

Falls es relevant ist, verwende ich außerdem eine Passwort-Authentifizierung und keine Schlüssel.

Hat jemand eine Idee, wie ich dieses Problem lösen / weiter diagnostizieren kann?

Der Fehler

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/'

Mehr Infos

git push origin (WENN HTTP verwendet wird, um 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

(Ich bin etwas verwirrt, warum es hier so einen großen Unterschied zwischen http und ssh gibt; http fragt mich zweimal nach meinem Passwort und fängt dann an, entfernte Köpfe zu holen, während ssh mich einmal nach meinem Passwort fragt und dann beginnt, Objekte zu zählen).

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)

Und falls es von Nutzen ist, meine lokale Konfigurationsdatei:

[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

Und Remote-Konfigurationsdatei:

[core] 
   repositoryformatversion = 0
   filemode = true
   bare = false
   worktree = /home/test/public_html
   sharedRepository = true

---

Weitere Untersuchungen

Nach Jans Kommentaren habe ich das Problem ein wenig weiter untersucht. Ich nahm an, dass nur das "Test"-Konto beim Push über ssh verwendet würde (und Apache über http-Push), aber ich denke, es muss beides sein.

Ich bin das nicht funktionierende Repo noch einmal durchgegangen und habe die Eigentumsverhältnisse wie im funktionierenden Repo festgelegt (einige Dateien/Ordner sind apache.test, andere sind test.test und die Konfigurationsdatei ist Root.test).

Ich habe nicht alles überprüft, aber die Dateien im Repo-Verzeichnis und alle Dateien und Ordner unter objects, refs und info haben alle die gleichen Eigentumsrechte und Berechtigungen in der Arbeits- und der Nicht-Arbeitsumgebung, und die Benutzerkonten sind auf die gleiche Weise eingerichtet (ich habe bei der Fehlersuche zuvor 777 ausprobiert).

Der Hauptunterschied, der mir einfällt, ist, dass ich in der nicht funktionierenden Repo mit http begann und dann zu ssh wechselte, während ich in der funktionierenden Repo direkt zu ssh überging und die Repo vorher leer war. Vielleicht gibt es irgendwo eine seltsame Datei mit falschen Berechtigungen, die alles kaputt macht, oder es gibt etwas Bizarres, das in den eigentlichen Dateien vor sich geht, das ich durch die Verwendung verschiedener Protokolle durcheinander gebracht habe, oder vielleicht ist es auch nur beschädigt worden, weil ich gestern stundenlang versucht habe, es zum Laufen zu bringen.

Answer 1

Ich habe ein brandneues Remote-Repository unter einem anderen Benutzerkonto eingerichtet und es funktioniert jetzt einwandfrei. Alle Einstellungen sind mehr oder weniger die gleichen (Berechtigungen sind weniger streng dieses Mal), so bin ich nicht sicher, was das Problem war.

Answer 2

Wenn Sie im Internet nach dem genauen Wortlaut der Fehlermeldung suchen, die Sie erhalten, erhalten Sie viele Treffer. Ein kurzer Blick auf die Treffer zeigt, dass es sich offenbar um ein Berechtigungsproblem handelt.

Sie sagen, Sie haben das Repository im Besitz von apache.test . Läuft Apache jedoch tatsächlich als apache.test ? Wenn nicht, werden die neuen Verzeichnisse, die der von Apache betriebene Git-Server erstellt, einer anderen Gruppe gehören (was auch immer die primäre Gruppe des Servers ist) und die test Benutzer kann dort nicht schreiben, obwohl Sie Git angewiesen haben, das Projektarchiv für Gruppen beschreibbar zu machen.

Sie haben mehrere Möglichkeiten:

1. Verwenden Sie suExec um das git cgi auszuführen als test.test und lassen Sie die Gruppenschreibberechtigung fallen.
2. Verwenden Sie die primäre Gruppe des Webservers als besitzende Gruppe
3. Machen Sie das Repo für jeden beschreibbar ( core.sharedRepository = everybody )
4. Es sollte möglich sein, die SGID des Repos der richtigen Gruppe zuzuordnen, indem man core.sharedRepository à 2664 aber ich bin mir da nicht so sicher.

Ich persönlich würde die suExec bevorzugen.