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, whe

Answer 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

Answer 2

I had the a similar problem: Gitlab server is inside a docker container and every time when I tried to push changes, I had: git@localhost's password:

the root cause was using "localhost" as a name. Right way is to check out the IP of the GitLab's container by: $ docker inspect <container_id>

find the row: "IPAddress": "172.17.0.2",

test it by: ssh -T git@172.17.0.2 the answer should be like this. "Welcome to GitLab, @user_name!"

now it's necessary to fix repository's URL: $ git remote set-url origin git@172.17.0.2:user_name/repo-name.git

after that the push command should work properly.

Answer 3

I got mixed up with this one time. When you use sudo git, that means the git is being launched as root. The question would be -- did you create SSH key for root and put it inside Gitlab?

I am guessing that you created your SSH key without sudo (which is for your normal account), put the SSH publickey into Gitlab, and then run sudo git.

You can try running git without the sudo. And if you have folder permission issues, which made you use sudo in the first place, try giving your user account access to that folder. Or perhaps try the git normally in a folder that you have write permission.

Answer 4

There is a ticked for that here.

To determine the cause of the problem check the logs on the server via sudo grep sshd /var/log/auth.log.

Until 13 December 2013 commit b24d5d, the problem was caused on the Vagrant development machine due to excess of permissions for .ssh/. You must have:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

or ssh refuses to make the rsa connection and sudo grep sshd /var/log/auth.log says:

Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys    

The problem has been solved by setting sshd to non sctrict mode for development, allowing it to run correctly even it permissions are too free.

Answer 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

Answer 6

This may be too simple, but I had the same problem. I'm guessing it's because it picked up localhost as the domain name.

It worked out when I logged in from another computer back to my localhost machine, and then tried to commit. It's pretty dumb but worth trying.