9 times out of 10 it’s ssh.
I am converting a client from CVS to Git managed with Gitolite. So far the process has been smooth, but here have been a few hiccups along the way. The most common problem is the generation of proper ssh keys that Git can use.
Converting the clients users from CVS to git should be relatively easy if you use ssh. You need to make sure that you take the id_rsa.pub file from each individual who requires access to the projects under gitolite and place them in the gitolite-admin/keydir folder.
Git uses ssh for authentication and we use the ssh key located in the .ssh folder located at the root of the user’s home folder. When a user attempts to access a project controlled by Gitolite, a ssh authentication challenge takes place. The most common problem that I have had is users who tried to create custom keys and ssh was not able to locate the key or in the case with windows users, they exported their putty key.
If you export a putty key, you need to make sure you export into a openSSL format. Even then, I still had issues. On windows installations you typically get a command line bash shell for Git. If you open this shell, you can create the openSSL key using the same utilities you find on Unix/Linux machines along with the mac.
Just remember that if you have crazy issues with Gitolite permissions, it’s typically one of the following errors
- Prompting for firstname.lastname@example.org were gituser is the user created during Gitolite install. This error identifies a problem with the ssh key for that user. The key is corrupt or not recognized.
- Other errors I saw were caused by not use the proper command line arguments when creating the key. This caused key size validation problems. this was fixed with a new set of keys.
- Putty exported keys had the same size verification issues.