GitLab requires git@localhost password to push to a repo

Question

I'm trying to get GitLab up and running on my server. I followed the installation instructions at the gitlab github page and everything went well.

The issue is, when I create a repo and try to

sudo git push -u origin master

I am prompted for 'git@localhost's password: '

The git user doesn't have a password, so this is a problem.

Other people who have run into this problem suggested adding git to AllowedUsers in my sshd conf but I don't have an AllowedUsers field in there, so that doesn't seem to be an issue.

I'm still pretty new to ssh stuff so I believe its some sort of ssh key issue, though I tried to add all relevant ssh keys to /home/git/.ssh/authorized_keys and verified that there are no line breaks in the file.

Just FYI, my install completely passes the test provided in the gitlab wiki:

sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

Any suggestions much appreciated!

EDIT

So, I finally got around this by just committing to a repo from a different machine. As it was, I was SSHed into the same machine that gitlab was running on. As soon as I tried to commit from a machine other than the host, it worked great. So, that may be a solution for some people (it is for us, since we develop on seperate machines than our servers).

This is still an open-ended issue for anyone trying to host and develop on the same machine who has run into this.

Solution 1

---

TL;DR

Keys store on both gitlab DB and gitolite side. You should use the factory build gitolite-admin.git folder, don't use your backup! And rebuild the Keys for gitolite later with the update keys command. (update those keys already saved inside the gitlab db to gitolite)

sudo -u gitlab -H bundle exec rake gitlab:gitolite:update_keys RAILS_ENV=production

---

Most likely it's because there is something issue about the gitolite keys not save properly. Those keys (for login) are actually keep separately by gitlab & gitolite. For pull/push is actually using the keys saved inside gitolite. (git/repositories/gitolite-admin.git/index, git/.gitolite/keydir, git/.ssh/authorized_keys)

gitlab normally should help on saving those imported keys on web to the gitolite files. However, for some reasons it failed. As the keys are not saved properly inside gitolite, the client/server fail to use the keys and fallback to password.

You have to check and fix those keys saved inside gitolite to correct the problems.

check out for more https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/X0z_9l7L7A8

Solution 2

I received the same password prompt. My issue was that I had restricted ssh usage to only a couple of users. I added the git user to the AllowUsers list sshd_config, and everything worked great.

Solution 3

If the installation went well, that means your gitlab is able to clone the gitolite-admin repo without issue.
But you say it passes the status check, which means you are using, for ssh connection, an account named 'gitlab'.

That also means that any client will have to ssh with that same account 'gitlab', not 'git'.
So if your ssh key has been added through the gitlab interface, then you can git clone/git push to a remote name origin which would have the address 'gitlab@server'

To debug some more, check out some other tips mentioned in "Setup Git Remote SSH (git-upload-pack / git-receive-pack)":

If you cannot push locally (on the server itself, that is on 'localhost'), try at least a:

ssh -vvvT gitlab@localhost

It shouldn't require any password, since /home/gitlab/.ssh/id_rsa and /home/gitlab/.ssh/id_rsa.pub both exist.

Solution 4

This started happening to me quite a lot lately - for work projects git would ask me my email and password. When entered it continues ok but it's annoying.

I can fix this for any given application that I have access to with:

git config remote.origin.url [email protected]:user_org_or_co/repo_name_itself

e.g.

git config remote.origin.url [email protected]:smithw/bookmarkapp

Solution 5

I ran into the same issue recently, and discovered that the issue for me was that SELinux was preventing sshd from accessing to the authorized_keys file in gitlab's data directory /var/opt/gitlab/.

To fix this, edit /etc/selinux/targeted/contexts/files/file_contexts.homedirs and add the line:

/var/opt/gitlab/\.ssh/.*    system_u:object_r:ssh_home_t:s0

Then run:

$ restorecon -Rv /var/opt/gitlab

Source : https://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login

View more solutions

Comments

[DevinR]

Hi VonC, thanks for your help here. Just to verify, I am SSHed into the server machine under an account other than gitlab (the username is devin). ssh -vvvT gitlab@localhost does require a password, unfortunately. I haven't tried adding a key through the interface, as I haven't noticed an option to do that on gitlab. Let me know if you have any further suggestions. Thanks!

[VonC]

@DevinR if you try ssh without having added yuor public key first, it is normal that ssh asks for a password: it looks for your pub key in ~gitlab/.ssh/authorized_keys and doesn't find it. You need to generate a public/private key (as in stackoverflow.com/a/10921120/6309) and copy the public key in your gitlab account page.

[DevinR]

I have now generated a user on gitlab and added my ssh key there. I also added the key to /home/gitlab/.ssh/authorized_keys and /home/git/.ssh/authorized_keys. Unfortunately I'm still having the same problem. Thanks again for your help.

[VonC]

@DevinR you shouldn't need to add anything to the gitlab authorized_keys file: that is the job of gitolite, called by gitlab when you added your public key through the interface. One thig that got me was the lack of a ~gitlab/.gitconfig file, that is a git global config for gitlab. Try, as gitlab, on the server, to type: git config --global user.name gitlab and git config user.email [email protected] (the actual email address isn't important): that will avoid gitolite to barf at the lack of identification (no username, no email) when doing its operation: then try again to add a new key.

[kara deniz]

"give your server a power cycle" seems excessive - just reboot sshd.

[imme]

Nice, with the verbosity flags (-vvv) I was able to see that the ssh programs didn't have read-access to the private key file .. w/ msg: could not open key file '/home/XxX/.ssh/id_rsa': Permission denied

[VonC]

@immeëmosol yes, it is how I debug ssh connection. But I usually start with ssh -Tv (to be a bit less verbose), and add one or two more 'v' if needed.

[pal4life]

This looked promising but still asking for password with the server address now