7

I am installing gitolite on a CentOS 5.9 server. I have created the git user, then after su - git I have managed to get my public key into the ~/.ssh/ directory, I have successfully cloned the gitolite repo from github and have run gitolite/install -ln. Next step is to run gitolite setup. 

git@hostname [~]# gitolite setup -pk $HOME/.ssh/micha.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
FATAL: fingerprinting failed for '/tmp/Q3pnE4WVbu'

Google search and a search here on SO have not helped me resolve this FATAL error, and I am now stymied.

Am I supposed to have customised the gitolite.conf file previous to running the setup? I have been following the instructions from http://gitolite.com/gitolite/progit.html as they are a little easier for noob like me to understand than the normal gitolite documentation. However these instructions make no mention of customising the .conf file.

UPDATE: I have tried generating a new key and it still fails: 

git@hostname [~]# ssh-keygen -t rsa -C "Gitolite Admin Access (not interactive)" -P "" 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/git/.ssh/id_rsa): /home/git/.ssh/micha
/home/git/.ssh/micha already exists.
Overwrite (y/n)? y
Your identification has been saved in /home/git/.ssh/micha.
Your public key has been saved in /home/git/.ssh/micha.pub.
The key fingerprint is:
33:b6:62:8b:b9:58:07:7a:71:6a:02:a5:ff:7e:c3:3a Gitolite Admin Access (not interactive)
git@hostname [~]# gitolite setup -pk $HOME/.ssh/micha.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
FATAL: fingerprinting failed for '/tmp/pUKqewb66w'

I have also tried replacing $HOME with the full path, just in case the su - git had confused it. Is there some problem with my ssh install? Not sure how there would be as I am using ssh to connect to this server.

UPDATE: It turns out gitolite was retaining the public keys I had tried to set up with previously that had failed. I then removed the all the repos, the gitolite source directory, the symlink in ~/bin and the .gitolite directory and started the install process again. I cloned the gitolite repo from github, generated a new key after deleting all the other keys that I had tried to use before. I then ran gitolite install -ln and finally 

git@hostname [~]# gitolite setup -pk $HOME/admin.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
FATAL: fingerprinting failed for '/tmp/tsIx4cKWHj'

Still failing.

mwotton
  • 2,170
  • 18
  • 36

9 Answers9

8

if you are taking the pub key from puttykeygen etc.. it will be in multi line with headers like

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "test@example.com"
startofkeylines
....
endofkey==
---- END SSH2 PUBLIC KEY ----

Remove the --- begin and end lines, and the Comment: line. Make all the key lines in one line. and prefix with ssh-rsa, like this:

ssh-rsa startofkeylines....endofkey==

This is what worked for me.

Kinjal Dixit
  • 7,777
  • 2
  • 59
  • 68
  • 2
    Alternatively, if you load a PPK file or generate a new key in PuTTYgen, there is a correctly formatted public key in the box with the heading: "Public key for pasting into OpenSSH authorized_keys file". Using this eliminates the potential for corrupting the public key as you edit it manually. – mwotton Nov 02 '14 at 22:57
3

gitolite is fingerprinting all keys in the .ssh directory - including the authorized_keys file. Remove any unneeded or corrupt keys from the .ssh directory and the authorized_keys file.

mwotton
  • 2,170
  • 18
  • 36
  • Excellent. +1. I have documented your answer in mine, with a reference to the gitolite code explaining that behavior. – VonC Apr 24 '13 at 05:18
  • Thanks :) I have accepted your answer as it contains both points of failure and the solutions along with a better technical explanation. – mwotton Apr 24 '13 at 07:33
  • Hi! when you say "remove any corrupt keys from .ssh directory " you mean the .ssh directory of our user? (from we manage the repo) or the .ssh directory of the gitolite user server? – Rubendob Nov 11 '14 at 10:15
  • It should be the folder of the gitolite user - there should not be a normal user for a gitolite user. Gitolite manages the authentication of gitolite users, the system does not. – mwotton Nov 11 '14 at 12:58
2

I ran into the same problem. Turned out that during copy-paste I included a newline into one of my keys. Took me some time to spot it...

Hans
  • 31
  • 3
2

You wrote, "It turns out gitolite was retaining the public keys I had tried to set up with previously that had failed."

I had the same problem. I was getting the error:

FATAL: fingerprinting failed for 'keydir/jsmith.pub'

I deleted the failing key on the client side, and did a git push, but still the same issue. Thus I had to logon to the gitolite server and run the following:

rm ~/.gitolite/keydir/jsmith.pub
gitolite setup

This fixed the problem. This works because per the gitolite documentation, "The pubkey files from this push are checked-out into ~/.gitolite/keydir". Well if there is some FATAL error that happens, then the pub keys won't be put in their proper place. So it's possible you could have even formatted your ssh keys properly, and it still won't get written.

user64141
  • 5,141
  • 4
  • 37
  • 34
1

As I mentioned before, that means the ssh key hasn't been properly generated.

Try:

ssh-keygen -t rsa -f "${H}/.ssh/micha" -C "Gitolite Admin access (not interactive)" -q -P ""

The OP mwotton reports clearing the ~/.ssh from any prior ssh keys was the solution.
This is because the ssh-authkeys.fp_file() function is called with a find:

chomp( my @pubkeys = `find keydir/ -type f -name "*.pub" | sort` );

So it can grab previous (possibly corrupted) keys that already were in ~/.ssh.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • If I run this on the server, this will generate the pair. I then need to transfer the private key to my workstation. Is there a way to tell my local git client to use that key file just for this remote? – mwotton Apr 23 '13 at 02:54
  • I did see that earlier answer too, but since it had initialized the repos, I figured that the key must have been ok. In earlier attempts, it had failed with the fingerprint error even before the repos were inited, so I tried a few different options with the key and got this far. – mwotton Apr 23 '13 at 02:56
  • @mwotton you simply copy `micha` and `micha.pub` on your local `%HOME%\.ssh` (windows) or `~/.ssh (unix)`, and declare a config file which will allow you to use that special account for gitolite-admin repo (while creating a new pair of keys for using gitolite as a user): see http://stackoverflow.com/a/10909791/6309 – VonC Apr 23 '13 at 05:14
  • OK, so I specify the key in the config file in the .git folder within the repo. However I am still having problems - question has been updated. – mwotton Apr 23 '13 at 06:00
  • @mwotton what? in the `.git` folder? That `config` file has nothing to do with git: it is an ssh config file, in `~/.ssh` (in the **client** side): see http://stackoverflow.com/questions/10906633/users-are-asked-for-password-while-using-gitolite/10909791#10909791 as a complete example. – VonC Apr 23 '13 at 06:02
  • ok I'll sort that out separately. I am still trying to get the gitolite setup command to work. – mwotton Apr 23 '13 at 06:55
  • @mwotton right. What gives a `ssh-keygen -l -f '$HOME/.ssh/micha'`? does it follow the right pattern. – VonC Apr 23 '13 at 06:58
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/28708/discussion-between-mwotton-and-vonc) – mwotton Apr 23 '13 at 06:59
  • running that command (without the quotes - it would not work with the quotes) gave: 2048 33:b6:62:8b:b9:58:07:7a:71:6a:02:a5:ff:7e:c3:3a /home/git/.ssh/micha.pub – mwotton Apr 23 '13 at 07:03
  • @mwotton ok, that fingerprint command is actually applied to any key found in the `gitolite-admin/keydir` directory (https://github.com/sitaramc/gitolite/blob/master/src/triggers/post-compile/ssh-authkeys#L49-L60). Is there any other key in there that might be "corrupted"? – VonC Apr 23 '13 at 07:12
  • I do not seem to have a gitolite-admin directory - at least not one with a subdirectory called keydir. The only directory remotely close is `gitolite-admin.git` folder, and it seems to be a bare repo directory. – mwotton Apr 23 '13 at 07:22
  • @mwotton it should be bare indeed. You would need to clone it to see its content. – VonC Apr 23 '13 at 07:23
  • I ran through additional steps ass added to the question. Still failing so I looked at the contents of the file in the tmp directory that had failed, then grep'ed a string from that file. It located the string in the authorized_keys file in the ~/.ssh directory. I cleared that file and ran the setup again - it WORKED! – mwotton Apr 24 '13 at 04:14
1

I have tried all the key regeneration, gitolite reinstalation, clearing all key files, etc, all without success, untill I started looking at Git history for gitolite.

The problem was that master branch on the github & google.code repos was broken. I checked out last stable version v3.6.4 at the finger print problem dissapeared. I think I can spot one recent commit that nreaks this.

Darek
  • 11
  • 1
1

The issue I encountered was that openssh, in or around version v6.8 changed the default cipher for a fingerprint (ssh-keygen -lf path-to-key) so one must now explicitly pass the cipher type (-E md5) to get the legacy behavior. Reviewing the CHANGES file reveals that v3.6.5 of gitolite will 'handle new style ssh fingerprinting correctly (thanks to Robin Johnson)'. An upgrade of gitolite resolved the issue for me.

Hugh Esco
  • 67
  • 1
  • 6
0

For me, I got it working by not running the gitolite command as the root user. I created a git user account (and found out that it needs to be an account that can be logged into ... that is, no /bin/false in /etc/passwd).

Howard Abrams
  • 186
  • 2
  • 5
  • 1
    It's somewhat risky to run something like gitolite as `root`. Usually this indicates a permissions error. If you're sure your perms are correct, how about creating the `git` user with the ability to log in? – mwotton Nov 02 '14 at 22:59
0

I upgraded gitolite from v2 to v3, runs install and setup the admin key

then force push the config repository, all issues are now fixed.

c9s
  • 1,888
  • 19
  • 15