Git quiere una contraseña a pesar de su configuration con authentication de key

Tengo un problema al usar git. Cuando bash acceder a un repository, git solicitará automáticamente una contraseña, aunque la authentication a través de la contraseña esté desactivada en gitserver.

Mi configuration de ssh es la siguiente (nombre de host / repository están anonimizados):

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

Cuando trato de clonar el repository, sin embargo, falla, debido a una request de contraseña:

 git clone [email protected]:repository Cloning into 'repository'... [email protected]'s password: 

La carpeta ~ / .ssh, así como su contenido están configurados con permissions 700 como se describe aquí (una de las muchas cosas que probé).

Alguien tiene una solución para esto?

Editar:

Otros bashs de clonar fallaron exactamente de la misma manera

 git clone gitserver:repository Cloning into 'repository'... [email protected]'s password: 

Edit2:

 ssh -Tv gitserver 

resultados en el siguiente resultado:

 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 [email protected]'s password: 

Si desea utilizar la key privada utilizada por gitolite, la url ssh debe ser:

 git clone gitserver:repository 

Eso utilizará la key privada ~/.ssh/gitolite , que lo identificará como git en el server gitolite.

Descubierto el motivo de las requestes de contraseña.

Aparentemente, uno de los commands anteriores para gitolita, que se suponía que boostía los tamaños de files admitidos en git, no se pudo ejecutar, lo que provocó que las siguientes actualizaciones key para gitolite quedaran atrapadas en una queue.

Por lo tanto, ~/.ssh/known_hosts nunca fue actualizado por gitolite en el lado del server, lo que ocasionó la disminución de la key.