Gitosis requires password even though the public key is given

Question

I'm confronted with some problems when trying to configure gitosis on my Archlinux

http://wiki.archlinux.org/index.php/Setting_Up_Git_ACL_Using_gitosis

I referred to this wiki article and successfully installed gitosis.

$ sudo pacman -U gitosis-git-20090525-1-i686.pkg.tar.gz
$ sudo -H -u gitosis gitosis-init < /tmp/id_rsa.pub

And modified /srv/gitosis/.ssh/authorized_keys to include my local user's id_rsa.pub.

But when I run git clone as the local user,

$ git clone gitosis@host:gitosis-admin.git

It says

Initialized empty Git repository in /home/wyx/gitosis-admin/.git/
[email protected]'s password: *****
fatal: 'gitosis-admin.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

So the git clone operation failed. I'm wondering why it tries to initialize an empty git repository in my local user's directory (/home/wyx)? And since I've already added local user's id_rsa.pub in .ssh/authorized_keys, why does it still ask for password?

Aecium

or maybe just restart your console – Parvis

Answer 1

An empty repository was created because that's just how git works: it has to init a repo before it can start pulling remote objects into it. Unfortunately this means you'll have to manually delete the empty repo before you try cloning again.

As for why the clone failed, it looks like you're using the wrong syntax for the remote repository path; git clone doesn't use scp syntax. In fact, if you don't specify a clone protocol, I believe it assumes the git protocol rather than ssh, which would probably be why it asked you for a password. Try this instead:

$ git clone ssh://gitosis@host/~/gitosis-admin.git

Freytag

Thanks for your reply. Finally i find the problem lies in that i use the wrong public rsa key, and ssh:// syntax is another mistake. – Aecium

As of git 1.6+, you don't have to specify the protocol. So user@host:reponame.git will work. – Dey

Answer 2

I also faced the same problem "fatal: '/gitosis-admin.git' does not appear to be a valid repository." I searched a lot for the problem and finally found the solution.

Actually, the default address of gitosis user is "/srv/gitosis" : As in case of my setup having ubuntu server 10.04.

And when we write "git clone [email protected]:gitosis-admin.git", it searches for gitosis-admin.git repository in /srv/gitosis. So when I entered inside the /srv/gitosis, I found out that there is another repository inside it named as repositories which consists of the gitosis-admin.git repository.

So actually by default the gitosis-admin.git was not in the default location. So I have to modify the command path and then it worked fine.

I got the repository cloned onto my local machine. I used the command as:

"git clone [email protected]:repositories/gitosis-admin.git" and it worked fine for me.

See for the gitosis-admin directory in your case and I hope you will be able to solve your problem.

Godbeare

In my case I must change to "git clone [email protected]:/srv/gitosis/repositories/gitosis-admin.git". But it cannot be the right way. Still broken. – Donation

Answer 3

This is what solved the problem for me (on Ubuntu):

git clone [email protected]:/srv/gitosis/repositories/gitosis-admin.git

Craigie

Answer 4

Gitosis creates it's own authorized_keys file. If you already have that file, delete it and allow gitosis-init to recreate it. Once that's done, don't mess with the file.

Dey

This was the problem I ran into. I had already copied my id_rsa.pub into ~gitosis/.ssh/authorized_keys. Blowing that away to let gitosis-init write what it wanted (rather than appending to the existing one) solved the issue for me. – Battaglia

Answer 5

I had the same problem on ubuntu,

It worked with git clone ssh://git@serverName/absolutePath/gitosis-admin.git

Bangkok

Answer 6

I resolved a similar issue. It might not be exactly what is happening in your case but you could try to re-apply the same troubleshooting which I did.

I realized that when I was pushing keys for a new user I was getting this stacktrace, which is the symptom that the hook on gitosis failed to process the new key.

remote: Traceback (most recent call last):
remote:   File "/usr/local/bin/gitosis-run-hook", line 9, in <module>
remote:     load_entry_point('gitosis==0.2', 'console_scripts', 'gitosis-run-hook')()
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 24, in run
remote:     return app.main()
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 38, in main
remote:     self.handle_args(parser, cfg, options, args)
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 81, in handle_args
remote:     post_update(cfg, git_dir)
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 45, in post_update
remote:     config=cfg,
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 95, in set_export_ok
remote:     for (dirpath, repo, name) in walk_repos(config):
remote:   File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 72, in walk_repos
remote:     assert ext == '.git'
remote: AssertionError

The error was showing only ONCE, so I naively dismissed it as a momentary failure.

In practice, Gitosis was working only for my key, but it wasn't working for any of the users which I was trying to support. In the ~/.ssh/authorized_keys I could not find the public key of the user which I thought I had just added. This is why my friend kept being asked for password every time he attempted cloning.

I added debugging to the Gitosis configuration, by adding these two lines to gitosis.conf

[gitosis]
loglevel=DEBUG 

I had to keep adding and removing users to the gitosis.conf file so that the hook would be triggered again. My debug log revealed

remote: DEBUG:gitosis.gitdaemon:Deny 'syncShare'
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d', seeing ['buildtools', 'QA_Dashboard']
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d/buildtools', seeing ['.git', 'conf', 'scripts'] 
remote: Traceback (most recent call last): 
etc ...

A-ha! As the hook performed the "walk" through the repository it had found a .git directory under legacy.d/buildtools and that is exactly where the assert ext == '.git' occurred.

I had used the server to store a simple clone from some other repository. Notice, a plain clone, not a mirror or a bare repository. Like every clone it contained .git directory.

The hook in Gitosis doesn't know what to do with a .git directory. It thinks that it's a repository in an empty name and aborts. Once I wiped out that clone everything resumed working nicely.

Leodora

Answer 7

Editing authorized_keys should not be necessary normally.

I once had an authorization problem, the gitosis server kept asking me password even if I'd placed my public key before. I realized that gitosis gave me a warning "WARNING:gitosis.ssh:Unsafe SSH username in keyfile: '[email protected]'" when I've tried to commit and push my changes to gitosis.

Changing the user@host part in the keyfile and keyfile name solved my problem. somehow gitosis did not like previous one.

Renvoi

Answer 8

I finally got it working like this

git clone ssh://git@host:1337/home/git/repositories/gitosis-admin.git

where 1337 the port ssh is using.

Vincenz

Answer 9

Same problem, and in my case was that I had wrong authorized_keys in .ssh/. I must have messed it up at some point ...

Eva

Answer 10

Having moved to a new Ubuntu machine and run into this question myself, I saw a couple answers on here that got me moving in the right direction, namely using an absolute path to the .git files for each repository.

Experimenting a bit I noticed paths relative to the git user's home directory also worked, which shortened something like:

git@host:/var/git/repositories/project.git

down to

git@host:repositories/project.git

Playing a bit more I tried moving the project files from repositories right into git's home directory; now only the project is required:

git@host:project.git

It's a bit hacky, but I doubt will cause any harm. Would be good to know what changed, as I was hosting gitosis on another Ubuntu (older) and was able to have the projects inside the repositories directory with the last notation from above.

Canvass

Answer 11

To gain more insight into auth issues, gather verbose debug log details: by using a

ssh -vvv gitosis@gitosis_host

direct manual-connect trick (which, phrased most importantly/generally, actually uses the most precise/direct context reference; in this case: actual ssh mechanisms rather than the tool-distant - and thus by necessity less precise - git handling!).

Willams