Have a user, whose public key was successfully added under “gitolite-admin/keydir” and whose rights were successfully configured under “gitolite-admin/conf/gitolite.conf”.
When this very user is cloning an existing, correctly configured repository, his/her identity ( public key ) is not being passed correclty => hence notice a password prompt:
$ git clone git@yourgitserver.com:your-project Cloning into your-project... git@yourgitserver.com's password: fatal: 'your=project' does not appear to be a git repository fatal: The remote end hung up unexpectedly
Here is the way to help out git / gitolite to understand which identity ( key ) to use:
$ vi ~/.ssh/config
host gitolite
user git
hostname yourgitserver.com
identityfile ~/.ssh/mypubkeyNow changing “git@yourgitserver.com” to “gitolite” does the trick:
$ git clone gitolite:your-project Cloning into your-project... remote: Counting objects: 83, done. remote: Compressing objects: 100% (77/77), done. remote: Total 83 (delta 3), reused 0 (delta 0) Receiving objects: 100% (83/83), 156.45 KiB | 49 KiB/s, done. Resolving deltas: 100% (3/3), done.
Notice, public key was successfully accepted => hence there was no password prompt, and the clone was successful.
Note that you can also get this error if you have an ssh key in the remote servers authorized_keys file that isn’t prefixed with the “command” option. This can happen if you installed gitolite on a git user account that already had keys in that file. Simply delete or comment those keys out.
(Gitolite makes a copy of that auth file before it adds new keys, it must be a bug that it left it in)
@Mauvis Thanks a million!
@mauvis – I have 3 levels of ssh users:
1. those who login with ssh
2. those who use gitolite
3. those who use both
If I remove or comment out existing keys they won’t be able to ssh in, so how do both ssh and gitolite users co-exist?
@Mauvis that was just the info i needed thanks
To answer @Iain’s question…
See Appendix 4. http://sitaramc.github.com/gitolite/doc/ssh-troubleshooting.html#_appendix_2_which_key_is_which_running_sshkeys_lint
@Mauvis +1 Thank you!
re Mauvis comment (first one in the list): it is not a bug that the lines are left in. Gitolite always moves all non-gitolite lines up before adding its own stuff every time you push the admin repo. It will NOT remove those lines — that would be dangerous.
Imagine what happens if an admin with only one key installs himself as the gitolite-admin using the same key. If I did what you said, he\’d suddenly lose shell access!
(I know people are supposed to have other means of access, like password, but that\’s not the point).
Just a small correction to your ~/.ssh/config file: the last line should point to your *private* key file, not to your public key file. Otherwise Git will ask you multiple times for your passphrase, fail to unlock the key, and then revert to trying SSH password authentication.
@Konstantin,
“mypubkey” is the private part of { mypubkey.pub, mypubkey }:
But I see how the name could be misleading.
/Toly
@Mauvis Thanks!
I have you say that your comment is better than the blog post