Gitosis requires password even though the public k

2019-03-17 14:36发布

问题:

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/
gitosis@10.132.140.73'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?

回答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


回答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.



回答3:

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

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


回答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.



回答5:

I had the same problem on ubuntu,

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



回答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.



回答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: '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.



回答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.



回答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 ...



回答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.



回答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!).