gitolite configuration - connect error

Question

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:

score 2 · Accepted Answer · answered Mar 18 '13 at 22:52

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

score 0 · Answer 2 · edited May 23 '17 at 12:28

0

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.

edited May 23 '17 at 12:28

Community

1
1

answered Mar 18 '13 at 20:34

VonC

1,262,500
529
4,410
5,250

.... dbg1: ssh_ecdsa_verify: signature correct dbg1: SSH2_MSG_NEWKEYS sent dbg1: expecting SSH2_MSG_NEWKEYS dbg1: SSH2_MSG_NEWKEYS received dbg1: Roaming not allowed by server dbg1: SSH2_MSG_SERVICE_REQUEST sent dbg1: SSH2_MSG_SERVICE_ACCEPT received dbg1: Authentications that can continue: publickey,password dbg1: Next authentication method: publickey dbg1: Offering RSA public key: /home/honza/.ssh/test dbg1: Authentications that can continue: publickey,password dbg1: Next authentication method: password test@192.168.1.10's password: – Meph- Mar 18 '13 at 21:02
@user2107985 ok, how about the protections? – VonC Mar 18 '13 at 21:04
server .ssh/ and .ssh/authorized_keys have 700 client .ssh/ has 700 and .ssh/test has 600 – Meph- Mar 18 '13 at 21:12
@user2107985 ok, you can edit your question with the result of a `ssh -vvvT gittest`, for me and other to have a closer look. – VonC Mar 18 '13 at 21:18
@user2107985 how did you generate your keys? See http://ubuntuforums.org/showthread.php?t=1777348 as an example. – VonC Mar 18 '13 at 21:37
@user2107985 https://bbs.archlinux.org/viewtopic.php?id=122646 is interesting also: "Aargh, I post this and double check the remote sshd_config file; I still had 'AllowedUsers ``'. Everything works as it should. This can be marked as solved." – VonC Mar 18 '13 at 21:46
ssh-keygen -t rsa (and I inserted a path and double enter). Thanks for links, it takes a while to study. – Meph- Mar 18 '13 at 21:50
And how the server knows that 'test' user is a git user not a system user? The SSH public key of test user is in the gitolite home directory and maybe system try to find a 'normal' 'test' user. – Meph- Mar 18 '13 at 22:39
@user2107985 I should have seen it immediately, see jszakmeister's answer – VonC Mar 19 '13 at 06:09

gitolite configuration - connect error

2 Answers2