How to Recover Access to Gitosis After Being Locked Out

Submitted by Jeet Sukumaran on

Site Section: 

Keywords: 

If ever you are careless enough to accidentally delete or mess up your public key in a Gitosis "gitosis-admin" repository, and you are stupid enough to push the changes through (guilty on both counts, twice), then you will realize that you have effectively locked yourself out of all access to the all those repositories. There are two obvious ways out of your predicament:

  1. Have somebody else with administrative access restore your access. Thank them. Do some penance and move on. And never do what you did again.
  2. Rebuild the gitosis directory from scratch. This involves backing up all the repositories, key files and configuration files, setting up gitosis all over again, and then copying all the files back and pushing the changes through in the first commit.

Without a doubt the first solution is the best choice. Nothing gets disturbed, except perhaps your ego and dignity, but you should have had the first deflated when you realized the consequences of your carelessness+stupidity, and if you have not lost the second at this stage of your life, you evidentally have not tried tequila.

The second solution seems rather drastic. And it not only is drastic, it is drastically wrong! Sure you will have restored access to yourself, but now will be in a horribly worse morass: you will need to contact each and every user and let them know that their local repos are now longer descendents or associated in any way with the primary repository, and that they will have to clone it fresh, and, oh yeah, sorry about the loss of versioning history. Talk about loss of ego or dignity (not to mention loss of all versioning history of the administrative repository).

There is, however, a third solution that allows you to recover access by yourself (i.e., without relying on other administrators), yet retain the integrity of the original repository. The trick is to use the file protocol to clone the gitosis-admin repository directly on the gitosis host, restore your key and/or fix the problem that was blocking your access, and then push the changes back to the original gitosis-admin repository. For this, you will not only need direct (ssh) access to the host, but read/write access to the gitosis user account (typically, "git"). Of course, "sudo"-power works just as well. If these conditions are fulfilled, you can recover from your mistakes all the more experienced, though perhaps not any wiser.

So how do we go about it?

  1. Log into the remote machine hosting gitosis: 

    $ ssh remoteserver

  2. Typically the gitosis administrator account is "git" (if the account name is different, you will have to modify the account name in following and all subsequent examples, of course). Furthermore, typically the account is set up without a password.If the account does actually have a password assigned and you know it, then you can skip this step. But otherwise, we will have to set a known password for the account, and this is where the sudo power comes in: 

    $ sudo passwd git
Password:
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

  3. Now we use the direct file protocol to clone the gitosis administrative repository to some temporary location: 

    $ cd /tmp
$ git clone git@phyllomedusa:/home/git/repositories/gitosis-admin.git
Initialized empty Git repository in /tmp/gitosis-admin/.git/
git@host.com's password: 
remote: Counting objects: 119, done.
remote: Compressing objects: 100% (118/118), done.
remote: Total 119 (delta 38), reused 3 (delta 0)
Receiving objects: 100% (119/119), 13.73 KiB, done.
Resolving deltas: 100% (38/38), done.

    Note that you will be prompted for the gitosis administrator's ("git") password. This is what we set in the previous step.

  4. Now fix whatever you broke: restore your key file(s), access privileges, etc. etc.

  5. All done? Are you sure? Ok, now commit and push back your changes: 

    $ git commit -a -m "It's not the number of times you fall, but the number of times your break your neck"
Created commit 7ea26fd: no, really updated pubkey this time
 1 files changed, 1 insertions(+), 27 deletions(-)
 rewrite keydir/jeet.pub (100%)

$ git push --all
git@host.com's password: 
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 782 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To git@phyllomedusa:/home/git/repositories/gitosis-admin.git
   2e2dde1..7ea26fd  master -> master

  6. And that's it! Assuming your changes are effective in fixing what you broke, all should be well in the land of Gitosis. If not, repeat the last two steps until you get it right. When things are working as they should, you probably want to clean up after yourself:

    $ rm -rf /tmp/gitosis-admin

6 Comments

$ git clone

Submitted by Anonymous (not verified) on

$ git clone git@phyllomedusa:/home/git/repositories/gitosis-admin.git gives me the same problems as with remote access. $ git clone /home/git/repositories/gitosis-admin.git works however!

Alternative way

Submitted by Henning (not verified) on

In such a case I found it way faster to just edit `~git/.gitosis.conf' on the server. After you fixed your mistake there you should be able to user the remote git repo again. The `.gitosis.conf' in the git-user's home directory gets overwritten if you do a commit to the admin repo anyways, so you can't break anything there for long.

You can also edit the

Submitted by Felix Bender (not verified) on

You can also edit the ~/.ssh/authorized_keys in your gitosis application directory and fix your key, and then push the gitosis-admin project again (with key fixed of course) again.

Thank you

Submitted by Kuba (not verified) on

Great stuff, thank you for writing this. Just as previously mentioned, good idea to set the gitosis password back to the original.

Add new comment