4

I was able to run the following command:

git clone admin@ip address:gitolite-admin.git

When I tried adding a new user using the steps below, the new user was unable to connect:

Steps taken so far:

1.  Copied the public key into the keydir (also tried copying it in a separate directory within the keydir)
2.  I added a repo in the config file for the new userID
3.  git add -A
4.  git commit -m 'adding new user keys and repo'
5.  git push origin master

All these commands run without throwing any errors.
When the user tries to login, he is unable to connect with the following command:

git clone username@IPAddress:newRepoName.git

The connection times out complaining about unable to connect on port 22. Any suggestions to help troubleshoot this (the public key for the user was generated from his computer - same one is being used for logging in as user - different computer was used for admin access). Thanks in advance

Edit: I removed the public key for a (non-admin) user, ran commit and pushed to the server after which I added a new public key for the user, ran add, commit & pushed to server. The response for the admin mentioned that the user was added. However, when the user tries connecting to the server using the command below, the connection attempt is unsuccessful (I can clone the project from my computer - the additional user cannot, neither can any other user so I am guessing I made a mistake in configuring additional users - any thoughts would be quite welcome and thanks for the patience)

git clone git@xx.xxx.xxx.xx:testProject Cloning into 'testProject'... Permission denied (publickey). fatal: The remote end hung up unexpectedly

ali haider
  • 1,120
  • 3
  • 15
  • 26
  • new user may have more than one key on their computer (for two separate git instances) - checking if that's the issue – ali haider Jan 21 '13 at 23:12
  • Username? You always use the same account when ssh'ing a gitolite server. The authentication of the actual user will be done with the public key matched against what has been registered in the ~/.ssh/authorized_keys file on the gitolite side. – VonC Jan 21 '13 at 23:16
  • I actually tried that as well earlier - but it does not connect (complains about "permission denied (public key)"). Any other suggestions would be most welcome. Thank you for your earlier feedback – ali haider Jan 21 '13 at 23:56
  • I tried adding the public key again through the add command as well but it does not seem to have corrected the issue. – ali haider Jan 21 '13 at 23:57

3 Answers3

4

This address won't ever work: git clone username@IPAddress:newRepoName.git

When using gitolite, you always use the same account:

git clone git@IPAddress:newRepoName.git

(if git is the account under which gitolite is installed)

See "adding and removing users" to understand how to declare a new user:

Ie adding his/her public key named after the user id in the gitolite.conf file.

Then the user must have his/her keys in ~/.ssh/id_rsa(.pub), and make any git command with git@IPAddress:newRepoName.git (git, not username)

VonC
  • 2,653
  • 5
  • 29
  • 48
  • thank you for your feedback. This is what I tried before posting the question: (1). get the new user to create the key on their computer (2) have them copy it to their ~/.ssh directory and ensure that they can connect without passwords (3) copy the key to a directory within the keydir (I have even tried copying it directly into the keydir) (4) add a repo to the gitolite.conf file permitting the new user and the admin (5) ran the commands I listed in my original post. – ali haider Jan 22 '13 at 17:05
  • However, the new user is still unable to connect (using git clone git@ip address:repoName.git (I had tried both username and git@ so I guess that was not the issue). Any other useful suggestions would be most welcome. Thank you for your feedback so far. – ali haider Jan 22 '13 at 17:09
  • I am able to clone the repo from my admin box. – ali haider Jan 22 '13 at 17:35
  • @alihaider (2) I confirm a user should not be able to ssh (gitolite should intercept immediately) so you don't need that test: too soon. (3): it must be copied directly within `keydir` of the `gitolite-admin` repo local clone, named after the user id, as stated in http://sitaramc.github.com/gitolite/users.html . Don't forget to push back the `gitolite-admin` repo back to the server. – VonC Jan 22 '13 at 18:42
  • @alihaider you always use `git@`, never ever `username@`. See http://stackoverflow.com/questions/13318715/how-do-programs-like-gitolite-work/13320256#13320256 for the reason behind that usage. – VonC Jan 22 '13 at 18:43
  • thank you for patiently answering and sharing your input. As I mentioned earlier, I have tried git@ as opposed to username@ - only I am able to connect so far. I have also tried moving the keys directly into the keydir (as opposed to placing them in a subdirectory within keydir - I'll try removing and then adding the users again to see if that works). Thanks – ali haider Jan 22 '13 at 21:16
  • As per the edit in my post, I recreated the user but it does connect (I can pull the repo on my computer). The public key for the new user is on the server. – ali haider Jan 23 '13 at 16:53
  • +1 for sharing the info - I am still unable to get the users connected (the users are configured in the gitolite.conf file and their public keys are in the keydir - I ran git add/commit/push after that as well. Thanks – ali haider Jan 28 '13 at 17:44
2

The issue was with the client setup for connecting to the amazon aws instance hosting git. I have accepted VonC's response since he was very responsive to all my questions.Thanks

  1. I had the user connect via ssh (using the ssh certificate file) - the user accepted the key for the connection to their computer.

  2. The user added a config file into their ~./ssh file in the following format:

    Host test.git.com

    HostName amazonHostName

    User adavid

    PreferredAuthentications publickey

    IdentityFile ~./ssh/adavid

The user ran the ssh-add command as well. However, they were not able to connect to the git repository using the short name and had to use the long name for the connection.

Once again - Merci beaucoup VonC!

ali haider
  • 1,120
  • 3
  • 15
  • 26
1

For others having the same problem, check whether AllowGroups is in use for ssh on the server. Might be the git-user on the server isn't in the correct group.

Diagnosis: attempt to ssh to the git-user on the server, and see what turns up in /var/log/auth.log If it says "User git from not allowed because none of user's groups are listed in AllowGroups", you need to check which groups are in AllowGroups and then add the git user to one of those.

kaleissin
  • 163
  • 1
  • 7