GitLab requires git@localhost password to push to

问题:

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.

回答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

回答2:

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.

回答3:

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.

回答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 [e-mail]:user_org_or_co/repo_name_itself

e.g.

git config remote.origin.url [e-mail]:smithw/bookmarkapp

回答5:

Make sure your gitlab profile has your public ssh key. Sign into gitlab, go to your profile and select the button "Add Public Key". Copy and paste you "keyfile".pub contents in the in the Key box. There were some versions of gitlab that had a bug that when you did add your public key, it did not update the authorized_keys file. Verify (but do not manually add) that your public key is in the authorized_keys file after you add it to your profile. If this is not the issue, then perhaps one of the earlier answers will help.

回答6:

on the git server edit /etc/ssh/sshd_config

uncomment the following lines under the authentication section or add them:

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

give your server a power cycle and then fire up gitlab

回答7:

I ran into a problem that exhibited similar symptoms. My issue was that I have two computers behind a router. The router is set to port forward SSH traffic (port 22) to computer 1. Gitlab is installed on computer 2. I am using a domain and a public facing IP to connect. When I push, the SSH traffic is directed to computer 1. There is a git user on computer 1 simply from having installed git. Computer 1 prompts me for the git user's password.

My install also passed all the ready checks.

I'm not sure if you're having the same issue, but the symptoms are the exact same so I figured this might help.

回答8:

Your git and gitlab users are passwordless?

How the sshd_config is?

check if this line is in the file: PermitEMptyPassword Yes

Anyway I guess it unsafe, in my installation, I put this 'Yes', clone and then keep the old config... When Cloning the ssh_key is saved by user git, and it will not ask password anymore..

But by now, i run into another error, when Im going to push, for every new User, we have to reconfig ssh for permit empty push and then keep back the config.

(I still haven't tested this method, because I found out that my gitlab isn't creating the repos in git user :/ )

回答9:

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.

回答10:

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.

回答11:

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.

回答12:

This means that the gitlab ssh server was not properly configured.

Edit /etc/ssh/sshd_config and assure that:

PasswordAuthentication no
ChallengeResponseAuthentication no

This should enforce ssh key only logins which is also a good security measures. Many newer distros do already have this enabled by default.

Don't ask me if you get locked outside, clearly SO is not the place where to ask how to configure and use a private/public key pair.

回答13:

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

回答14:

For anyone having this issue with Bitnami or any other configuration who wants to resolve it quickly, just use the full path instead.

git clone git@server_adress:/full/path/to/project.git

edited: I forgot to mention , it is very important to check if you have added the SSH keys to git-lab via the web page..