2

I stupidly formatted my laptop hard drive with the ssh keys for gitolite, I have root access to my server and have followed this answer Gitolite access repair and have successfully made a copy of my repo in the tmp folder and fixed the file

My problem is that i get an error when doing "gl-admin-push" here is the error:

Unable to determine correct path for gitolite scripts from the authkeys file.

Perhaps you haven't installed gitolite yet?

Or perhaps this is an HTTP mode install?  If so, please set the GL_BINDIR
environment variable to the full path of the gitolite scripts, then re-try
this command.  For example (if you followed doc/http-backend.mkd precisely):

GL_BINDIR=/var/www/gitolite-home/bin /home/git/bin/gl-admin-push 

My gitolite install was working fine before I locked myself out (facepalm)

Anny Ideas of how I can get out of this mess ?

Community
  • 1
  • 1
Purplefish32
  • 647
  • 1
  • 8
  • 24
  • And what is the value of your `GL_BINDIR` environment variable? – VonC Feb 20 '12 at 11:44
  • It was a problem in authorized_keys, i was missing the command before my public key. eg : command="/home/git/bin/gl-auth-command myusername",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty - Works now – Purplefish32 Feb 20 '12 at 12:09
  • Good catch. I have added it as an answer below, with references for more visibility – VonC Feb 20 '12 at 12:14

2 Answers2

2

I have had the exact same problem.

Fix was to update the authorized_keys file on the server for my git user (the one working with gitolite) in his ~/.ssh/ folder with the command=".." line VonC mentioned, plus the ssh-pubkey for the user I wanted to add by hand.Just so the entry was consistent with the other already existing entries.

Also I had to remove the ~/ssh/old_authkeys file, since gitolite seemed to reference it all the time and thus deleting the updated authorized_keys file in the process. (Ok, I just moved it, in case I'd need it again...)

Because of that second part, I feel qualified to make an extra post. ;)

EDIT:
Seems like authorized_keys is moved to old_authkeys every time I update my gitolite config with new repo or group settings. :|

EDIT2:
Source of all the problems was... not being logged in as the user called git I have in use for gitolite like in

git@server:repo

when trying to access the server repo's from the server, but as, i.e. myuser.
This resulted in messed up configurations and the time after time reverted authorized_keys file.
Once I set up ssh-keys for user git (and not for myuser), logged in as git (not as myuser), I fixed the settings via

git clone /local/path/on/server/to/gitolite-admin
(then I set the right permissions in the gitolite config)
gl-admin-push

and all was done... when logged in as git user also gl-admin-push worked without an error.

Afterwards the regular usage of git clone git@server:repo-git add .-git commit-git push git@server:repo was possible.

Another case of user-rights causing big trouble.

// This gained knowledge comes with the wisdom that it will never be worth the time spent on it.

sjas
  • 18,644
  • 14
  • 87
  • 92
2

The OP Purplefish32 realized that this message can also occur if the user executing the the gl-admin-push hasn't its public key properly registered.

That key needs to be set with the gitolite force-command script.

command="/home/git/bin/gl-auth-command myusername",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

This is consistent with what that script does:

# if GL_BINDIR was not passed in, find it
[ -z "$GL_BINDIR" ] &&
    GL_BINDIR=`  perl -ne 'print($1), exit if /^command="(.+?)\/gl-(time|auth-command) /' < $HOME/.ssh/authorized_keys`
# GL_BINDIR still not known?  we have a problem...
[ -z "$GL_BINDIR" ] && {
    echo "

Unable to determine correct path for gitolite scripts from the authkeys file.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250