Problem mit gitlab Zugriff auf Repositories über ssh

Question

Sorry das wird eine ziemlich detaillierte Post wenn nur um alles für mich zu klären. alles scheint korrekt konfiguriert zu sein und zu laufen:

bundle exec rake gitlab:check RAILS_ENV=production 

gibt nichts außer grünen Lichtern. Hinzufügen eines SSH-Schlüssel scheint gut zu funktionieren, und wir können mit https fein drücken: //

Wenn wir versuchen, eine Verbindung mit dem Kunden erhalten wir:

$ git push -u origin master 
fatal: Could not read from remote repository. 

Please make sure you have the correct access rights 
and the repository exists. 

Erkundung dieser weiteren ergibt:

$ GIT_TRACE=1 git push -u origin master 
trace: built-in: git 'push' '-u' 'origin' 'master' 
trace: run_command: 'ssh' '-p' '2222' 'gitlab@myserver.net' 'git-receive-pack '\''/root/test1.git'\''' 
fatal: Could not read from remote repository. 

Please make sure you have the correct access rights 
and the repository exists. 

und diese läuft mit info Debuggen ergibt nichts interessantes abgesehen von einem Exit-Code von 1.

am Protokoll auf dem Server suchen, während wir versuchen, verbinden wir diese bekommen (es auf Arch Linux läuft):

$ journalctl -f 

Jan 21 21:42:59 michaelarch sshd[2633]: Accepted publickey for gitlab from 192.168.1.1 port 58207 ssh2: ECDSA XX:e3:XX:aa:XX:0a:XX:37:XX:ad:XX:4f:XX:ab:ab:XX 
Jan 21 21:42:59 michaelarch sshd[2633]: pam_unix(sshd:session): session opened for user gitlab by (uid=0) 
Jan 21 21:42:59 michaelarch systemd[1]: Starting user-1001.slice. 
Jan 21 21:42:59 michaelarch systemd[1]: Created slice user-1001.slice. 
Jan 21 21:42:59 michaelarch systemd[1]: Starting User Manager for 1001... 
Jan 21 21:42:59 michaelarch systemd[1]: Starting Session 20 of user gitlab. 
Jan 21 21:42:59 michaelarch systemd-logind[461]: New session 20 of user gitlab. 
Jan 21 21:42:59 michaelarch systemd[1]: Started Session 20 of user gitlab. 
Jan 21 21:42:59 michaelarch systemd[2635]: pam_unix(systemd-user:session): session opened for user gitlab by (uid=0) 
Jan 21 21:42:59 michaelarch systemd[2635]: Failed to open private bus connection: Failed to connect to socket /run/user/1001/dbus/user_bus_socket: No such file or directory 
Jan 21 21:42:59 michaelarch systemd[2635]: Mounted /sys/kernel/config. 
Jan 21 21:42:59 michaelarch systemd[2635]: Mounted /sys/fs/fuse/connections. 
Jan 21 21:42:59 michaelarch systemd[2635]: Stopped target Sound Card. 
Jan 21 21:42:59 michaelarch systemd[2635]: Starting Default. 
Jan 21 21:42:59 michaelarch systemd[2635]: Reached target Default. 
Jan 21 21:42:59 michaelarch systemd[2635]: Startup finished in 23ms. 
Jan 21 21:42:59 michaelarch systemd[1]: Started User Manager for 1001. 
Jan 21 21:42:59 michaelarch sshd[2636]: Received disconnect from 192.168.1.1: 11: disconnected by user 
Jan 21 21:42:59 michaelarch sshd[2633]: pam_unix(sshd:session): session closed for user gitlab 
Jan 21 21:42:59 michaelarch systemd-logind[461]: Removed session 20. 
Jan 21 21:42:59 michaelarch systemd[1]: Stopping User Manager for 1001... 
Jan 21 21:42:59 michaelarch systemd[2635]: Stopping Default. 
Jan 21 21:42:59 michaelarch systemd[2635]: Stopped target Default. 
Jan 21 21:42:59 michaelarch systemd[2635]: Starting Shutdown. 
Jan 21 21:42:59 michaelarch systemd[2635]: Reached target Shutdown. 
Jan 21 21:42:59 michaelarch systemd[2635]: Starting Exit the Session... 
Jan 21 21:42:59 michaelarch systemd[1]: Stopped User Manager for 1001. 
Jan 21 21:42:59 michaelarch systemd[1]: Stopping user-1001.slice. 
Jan 21 21:42:59 michaelarch systemd[1]: Removed slice user-1001.slice. 

Jetzt ist meine Vermutung, dass die fehlerhafte dbus in Zeile:

Jan 21 21:42:59 michaelarch systemd[2635]: Failed to open private bus connection: Failed to connect to socket /run/user/1001/dbus/user_bus_socket: No such file or directory 

kann das Problem verursachen, aber ich kann es nicht verstehen und ich habe die Grenzen meines Wissens erreicht.

Es gibt natürlich viele Konfigurationsdateien, aber ich denke, ich habe sie alle untersucht, Ideen oder Tests sind sehr willkommen.

Die Authentifizierung scheint wie Laufen erfolgreich zu sein:

ssh -vvT gitlab@myserver.net 

gibt:

...... 
debug1: Server accepts key: pkalg ecdsa-sha2-nistp521 blen 172 
debug2: input_userauth_pk_ok: fp XX:e3:XX:aa:af:0a:ca:37:08:ad:XX:4f:XX:ab:ab:XX 
debug1: read PEM private key done: type ECDSA 
debug1: Authentication succeeded (publickey). 
Authenticated to myserver.net ([11.123.5.462]:22). 
debug1: channel 0: new [client-session] 
debug2: channel 0: send open 
debug1: Requesting no-more-sessions@openssh.com 
debug1: Entering interactive session. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
debug2: callback start 
debug2: fd 3 setting TCP_NODELAY 
debug2: client_session2_setup: id 0 
debug2: channel 0: request shell confirm 1 
debug2: callback done 
debug2: channel 0: open confirm rwindow 0 rmax 32768 
debug2: channel 0: rcvd adjust 2097152 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: shell request accepted on channel 0 
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 
debug2: channel 0: rcvd eow 
debug2: channel 0: close_read 
debug2: channel 0: input open -> closed 
debug2: channel 0: rcvd eof 
debug2: channel 0: output open -> drain 
debug2: channel 0: obuf empty 
debug2: channel 0: close_write 
debug2: channel 0: output drain -> closed 
debug2: channel 0: rcvd close 
debug2: channel 0: almost dead 
debug2: channel 0: gc: notify user 
debug2: channel 0: gc: user detached 
debug2: channel 0: send close 
debug2: channel 0: is dead 
debug2: channel 0: garbage collecting 
debug1: channel 0: free: client-session, nchannels 1 
Transferred: sent 3780, received 2908 bytes, in 0.0 seconds 
Bytes per second: sent 76566.5, received 58903.5 
debug1: Exit status 1 

EDIT: mehr Details als Antwort auf den Kommentar hinzugefügt.

Answer 1

Ich habe derzeit genau das gleiche Problem. Nach einigem Experimentieren habe ich folgendes gefunden: Der gitlab-Benutzer soll sich nicht anmelden können, daher wird seine Shell in/etc/passwd auf/bin/false gesetzt. Für den SSH-Zugriff gibt es einen erzwungenen Befehl, der in ~ gitlab/.ssh/authorized_keys definiert ist und die gitlab-Shell mit dem Schlüssel als Argument ausführt, um grundlegende git-Operationen für den verbindenden Benutzer zugänglich zu machen.

Jetzt habe ich festgestellt, dass, während die Benutzer Shell in/etc/passwd auf/bin/false festgelegt ist, der erzwungene Befehl Mechanismus überhaupt nicht funktioniert, und ssh Verbindungen auflegen. Eine Problemumgehung besteht darin, dem Benutzer nur eine Standardanmelde-Shell zu geben, sodass erzwungene Befehle ausgeführt werden.

Aber um ehrlich zu sein, habe ich keine Ahnung, ob das so funktionieren soll oder nicht, vor allem, ob erzwungene Befehle nur funktionieren sollen, wenn der Benutzer eine funktionierende Login-Shell hat (dh ein Standard ist liberaler als der erzwungene Befehl Ich hätte die Shell lieber auf/bin/false belassen, so dass der Benutzer, wenn die config in der Datei authorized_keys richtig ist, die gitlab-Shell bekommt, wenn nicht, bekommt der Benutzer nichts Jetzt gibt ein Config-Fehler dem Benutzer mehr Rechte, als ich beabsichtigt habe.)