keydir entries not propagating to authorized_keys

Question

I'm trying to set up a gitolite instance, and running into a problem where I follow the usual procedure to add a user (i.e. add public key file to keydir/xxx.pub; commit and push upstream) but then I'm finding that I can't clone repositories using the key I added.

I've verified that the commit I've made (adding the public key) to gitolite-admin is successfully pushed upstream (i.e. to the bare gitolite-admin repo within the gitolite installation).

I've noticed that no corresponding change was made to the authorized_keys file of the "gitolite" user, which seems wrong to me - I would expect to see the public key added there, and I suspect this is why the authentication is not working.

Where else can I look to troubleshoot this?

Answer 1

I ran today into same "hook not starting" issue with gitolite:

commit ef9ab68412cbee93c24eb920dbabbb6daa8b1c08
Date:   Tue Jun 11 11:53:30 2019 +0530

I had issue that a user had more than one line (newline at the end) in the .pub file (but still one key). Simply removing the extra newline and pushing did not work. I had to modify the gitolite.conf (removed some spaces in it). Then after the push, the user was added into authorized keys file.

Answer 2

OK, I think I see the sequence of events that led to this:

1) Edit local clone of gitolite-admin (add xxxxxx.pub and edit gitolite.conf) 2) Push to master - fails with remote: check GL_GITCONFIG_KEYS in the rc file for how to allow it 3) Fix corresponding configuration in .gitolite.rc 4) Attempt step (2) again; succeeds 5) Observe that .ssh/authorized_keys has not been updated. 6) Make another edit to gitolite-admin (trivial change; only adding a comment) 7) push gitolite-admin to master 8) all keys are set up properly in .ssh/authorized_keys.

The issue was that on failure in (2), the commit was pushed successfully upstream, but the hook that updates authorized_keys failed to run for the reason given; on trying to repeat the push (step 4), git observed that the push was a no-op, and the hook was not run. Making a trivial change to gitolite-admin (6) and pushing again (7) forced git to perform an actual push operation and exercise the hook.

This is a rather old version of gitolite (v1.5.7) which I must use for practical reasons, so I don't know if the latest version will also behave this way.

Answer 3

I've noticed that no corresponding change was made to the authorized_keys file of the "gitolite" user, which seems wrong to me - I would expect to see the public key added there, and I suspect this is why the authentication is not working.

That is indeed the origin of the issue.

You can see logs in ~/.gitolite/logs

But make sure you have added that user as a member of one of the repos in gitolite-admin/conf/gitolite.conf file, to see if the issue persists.

You can follow ssh troubleshooting and run (directly on the server):

• gitolite compile to see if there are any error messages
• gitolite sshkeys-lint, to check, for each key in the admin directory's keydir, what access is available.