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 referr

Answer 1

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.

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 gitosis@server.com: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 gitosis@server.com: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.

Answer 3

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

git clone gitosis@ns.home:/srv/gitosis/repositories/gitosis-admin.git

Answer 4

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: 'myuser@myserver.pub'" 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.

Answer 5

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.

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.