gitolite configuration – connect error

I would like to use gitolite for my git folders on server. I searched many blogs with tutorials, but a didnt able to find some examples with correct connection to server.

So, I added a new user gitolite and I created home directory /home/gitolite. I installed gitolite to /home/gitolite/bin and I did setup with ssh-key.

On my PC I succesfully cloned gitolite-admin and I generated new ssh-keys (test, test.pub), they is saved in .ssh/:

honza@honza-sg:~$ ls .ssh/t*
.ssh/test  .ssh/test.pub

next: copy ‘test.pub’ to keydir and modify gitolite.conf:

honza@honza-sg:~$ ls -l gitolite-admin/keydir/
-rw-rw-r-- 1 honza honza 396 bře 18 16:46 gitolite.pub
-rw-r--r-- 1 honza honza 396 bře 18 20:39 test.pub

honza@honza-sg:~$ cat gitolite-admin/conf/gitolite.conf 
repo gitolite-admin
    RW+     =   gitolite

repo work
    RW+     =   test

I pushed this changes to server:

honza@honza-sg:~/gitolite-admin$ git add .
honza@honza-sg:~/gitolite-admin$ git commit -m 'add test user'
[master bff8df5] add test user
 2 files changed, 2 insertions(+), 10 deletions(-)
 create mode 100644 keydir/test.pub
honza@honza-sg:~/gitolite-admin$ git push
Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 774 bytes, done.
Total 6 (delta 1), reused 0 (delta 0)
remote: Initialized empty Git repository in /home/gitolite/repositories/work.git/
To gitbox:gitolite-admin
   3102ec2..bff8df5  master -> master

I guess, that’s a correct procedure. Now, I need to clone new git repository. In .ssh/config I have this:

honza@honza-sg:~$ cat .ssh/config 
Host gitbox
        User gitolite
        Hostname 192.168.1.10
        Port 22
        IdentityFile ~/.ssh/gitolite
Host gittest
        User test
        Hostname 192.168.1.10
        Port 22
        IdentityFile ~/.ssh/test

And clone command:

honza@honza-sg:~/temp$ git clone gittest:work

Problem is here:

Cloning into 'work'...
test@192.168.1.10's password: 
Permission denied, please try again.
test@192.168.1.10's password: 
Permission denied, please try again.
test@192.168.1.10's password: 
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly

Why did it ask me for a password? When I was generating key, I didn’t insert password (I only twice pressed ‘enter’).

Thanks for help and I’m sorry for my english 🙂

edit:

ssh -vvvT gittest:

honza@honza-sg:~/temp$ ssh -vvvT gittest
OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/honza/.ssh/config
debug1: /home/honza/.ssh/config line 6: Applying options for gittest
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.10 [192.168.1.10] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/honza/.ssh/test" as a RSA1 public key
debug1: identity file /home/honza/.ssh/test 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/honza/.ssh/test-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.1.10" from file "/home/honza/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/honza/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
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: ECDSA d6:32:05:31:ea:3a:30:45:31:99:ca:90:b3:53:cb:75
debug3: load_hostkeys: loading entries for host "192.168.1.10" from file "/home/honza/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/honza/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.1.10' is known and matches the ECDSA host key.
debug1: Found key in /home/honza/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/honza/.ssh/test (0x7fa857d08e60)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/honza/.ssh/test
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
test@192.168.1.10's password: 

  • Is it possible to mirror a private repository on gitlab.com using the SSH protocol?
  • How to prevent that the password to decrypt the private key has to be entered every time when using Git Bash on Windows?
  • SSH - do I have multiple keys for different purposes or one key that represents my system?
  • Heroku permission denied / unable to connect to heroku api
  • gitlab SSH key project cloning issue
  • SSH Key ask to enter passphrase after start-agent
  • ssh key stops functioning after a while
  • Executing 'git pull' from SSH in Dreamhost to GitHub without password
  • 2 Solutions collect form web for “gitolite configuration – connect error”

    You still need to use the gitolite user for login. Gitolite sets up the test user’s key as an authorized key, and it knows what the test user is allowed to access as a result. So this:

    Host gittest
            User test
            Hostname 192.168.1.10
            Port 22
            IdentityFile ~/.ssh/test
    

    Should be this:

    Host gittest
            User gitolite
            Hostname 192.168.1.10
            Port 22
            IdentityFile ~/.ssh/test
    

    You can check the result of ssh -vT gittest, to see why it is asking for a password.
    See a debug session example at “Unable to Git-push master to Github”

    Make sure you have the right protections for your ssh keys, both on honza-sg and on the gitolite server .ssh directory.
    See “Git SSH authentication”: the main issue is generally a writable group on .ssh or any of its parent directory.

    Git Baby is a git and github fan, let's start git clone.