Gitlab预先接收挂钩拒绝SSH推送

Question

Current Installation:
Server: Ubuntu Server 16.04
Gitlab Version: 10.7.3
Gitlab Workhorse: 4.1.0
Gitlab App Directory: /opt/gitlab (application resides here)
Gitlab Data Directory: /drive2/repositories (repos created and stored here)

Context:
I slapped together a working Gitlab installation with the data-dir pointing to a separate partition for back-up purposes, because data continuity is a cool idea, right? Repositories that are created through the gitlab web-interface are stored in the data-dir as expected. SSL is fine and dandy so I can use HTTPS to CLONE out of these repos. Furthermore, I am able to PUSH to these repos using HTTPS without any errors.
I have also established SSH keys and authorized the git user (created by the omnibus gitlab installation) to validate against these keys. I have verified that I can successfully tunnel through SSH onto the server as the git user and have correct privileges to write and read the data-dir where repos are stored. Here's where it gets weird:

The Error:
I can successfully use SSH to clone a repo from the server with the following command:

git clone git@some_domain.com:user/repo_name.git

Cool. I'm less disappointed in the server than my parents are in me up until this point. So I go ahead, make a new file to add to the repo, commit (unlike my girlfriend that always drags her feet), and finally PUSH to the remote origin. And here my world crumbles like my motivation on Monday morning before work:

git push -u origin master
*** Edited Out: Push Stats
remote: GitLab: The project you were looking for could not be found.
To some_domain.com:user/repo_name.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 
'git@some_domain.com:user/repo_name.git'

I open the repo's directory on the gitlab server, navigate to the hooks folder which contains a symbolic link back to the gitlab app directory that houses the pre-receive hook file. The contents of the pre-receive hook file here:

#!/opt/gitlab/embedded/bin/ruby --disable-gems
# Fix the PATH so that gitlab-shell can find git-upload-pack and friends.
ENV['PATH'] = '/opt/gitlab/bin:/opt/gitlab/embedded/bin:' + ENV['PATH']
#!/usr/bin/env ruby
# This file was placed here by GitLab. It makes sure that your pushed commits
# will be processed properly.

refs = $stdin.read
key_id = ENV.delete('GL_ID')
protocol = ENV.delete('GL_PROTOCOL')
repo_path = Dir.pwd
gl_repository = ENV['GL_REPOSITORY']

def increase_reference_counter(gl_repository, repo_path)
  result = GitlabNet.new.pre_receive(gl_repository)

  result['reference_counter_increased']
end

require_relative '../lib/gitlab_custom_hook'
require_relative '../lib/gitlab_access'
require_relative '../lib/gitlab_net'

# It's important that on pre-receive `increase_reference_counter` gets executed
# last so that it only runs if everything else succeeded. On post-receive on the
# other hand, we run GitlabPostReceive first because the push is already done
# and we don't want to skip it if the custom hook fails.
if GitlabAccess.new(gl_repository, repo_path, key_id, refs, protocol).exec &&
    GitlabCustomHook.new(repo_path, key_id).pre_receive(refs) &&
    increase_reference_counter(gl_repository, repo_path)
  exit 0
else
  exit 1
end

Is the symbolic link back to the gitlab app folder causing issues to the dynamic directory being built by this file?

I am at a complete loss of why SSH pushes are not working and am as desperate for help as I am desperate for some validation in my life. Why does the CLONE command successfully find the directory, but the PUSH command not? Everything points me to the hook file, but I've never dealt with these and help would be more appreciated than a $5 gift-card three weeks after a birthday.

Thanks StackOverflow!

Answer 1

I have also established SSH keys and authorized the git user (created by the omnibus gitlab installation) to validate against these keys.

You need to be careful as to how you established those SSH keys.

You should only copy the public key to a GitLab User setting SSH page (see " How to create your SSH Keys ").
You should not add that public key yourself directly in the ~git/.ssh/authorized_keys file.

Also, a gitlab-rake gitlab:check on your GitLab server can help detecting such issues.