issue with gitlab access to repositories over ssh

Question

Sorry this will be quite a detailed post if only to clarify everything for me. everything seems to be configured correctly and running:

bundle exec rake gitlab:check RAILS_ENV=production

gives nothing but greens lights. adding an ssh key seems to work fine and we can push fine with https://

When we try and connect with the client we get:

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

exploring this further yields:

$ GIT_TRACE=1 git push -u origin master
trace: built-in: git 'push' '-u' 'origin' 'master'
trace: run_command: 'ssh' '-p' '2222' '[email protected]' '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.

and running this with debugging info yields nothing interesting apart from an exit code of 1.

looking at the log on the server while we try and connect we get this (it is running on arch linux):

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

Now my supposition is that the failing dbus in line:

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

may be causing the problem but I can't figure it out and I've pretty much reached the limits of my knowledge.

There are of course a lot of configuration files but I think I've looked into all of them, any ideas or tests are very welcome.

The authentication seems to succeed as running:

ssh -vvT [email protected]

gives:

......
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 [email protected]
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 [email protected] 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: added more details in response to the comment.

Answer 1

I am currently having the exact same problem. After some experimenting I have found the following: The gitlab user is supposed to be not able to login, so its shell in /etc/passwd is set to /bin/false. For SSH access, there is a forced command defined in ~gitlab/.ssh/authorized_keys that executes the gitlab-shell with the key as an argument to make basic git operations accessible to the connecting user.

Now I have found that while the users shell in /etc/passwd is set to /bin/false, the forced command mechanism doesn't work at all, and ssh connections hang up. A workaround is to just give the user a default login shell, so that forced commands get executed.

But, to be honest, I have no idea whether or not this is how it is supposed to work, especially, whether forced commands are supposed to only work when the user has a functional login shell (i.e. a default that is more liberal than the forced command. I'd have liked to leave the shell set to /bin/false, so that when the config in the authorized_keys file is right, the user get's the gitlab-shell, if not, the user get's nothing. Now, a config error will give the user more rights than I intended.)