Search code examples
gitsshgitolite

Git wants a password even though its setup with key authentication


I've got an issue using git. When I'm trying to access a repository, git will automatically prompt for a password, even though auth via password is disabled on the gitserver.

My ssh config is as follows (hostname/repository are anonymized):

host gitserver
  user gitolite
  hostname server.example.com
  identityfile ~/.ssh/gitolite

When i try to clone the repo however its fails, due to a password request:

git clone gitolite@server.example.com:repository
Cloning into 'repository'...
gitolite@server.example.com's password: 

The ~/.ssh folder, as well as its content are set up with permissions 700 as described here (one of the many things i tried).

Anyone got a solution to this?

Edit:

Other attempts to clone failed exactly the same way

git clone gitserver:repository
Cloning into 'repository'...
gitolite@server.example.com's password: 

Edit2:

ssh -Tv gitserver

results in the following output:

debug1: Reading configuration data /home/username/.ssh/config
debug1: /home/username/.ssh/config line 1: Applying options for gitserver
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.example.com [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/gitolite type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/username/.ssh/gitolite-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 00:df:a5:58:af:45:be:eb:62:65:07:5d:85:20:7c:98
debug1: Host 'server.example.com' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/username/.ssh/gitolite
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/username/.ssh/gitolite
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
gitolite@server.example.com's password:

Solution

  • Figured out the reason for the password prompts.

    Apparently one of the earlier commands for gitolite which was supposed to increase supported file sizes in git could not be run, which caused following key updates for gitolite to be stuck in a queue.

    Therefore ~/.ssh/known_hosts was never updated by gitolite on server-side, resulting in the decline of the key.