On Wed, 2009-06-17 at 04:48 -0700, thomas wrote: > Hi John, > > On 17 Jun., 13:21, Johan Sørensen <[email protected]> wrote: > > Hi John, > > > > On Tue, Jun 16, 2009 at 10:49 PM, John Koleszar<[email protected]> wrote: > > > > > Hi, > > > > > I'm considering setting up Gitorious at work, but I don't want to use > > > public key authentication. We already have centralized user management > > > and authentication through LDAP and Kerberos, and using a shared user > > > and public keys wouldn't go over well with our IT group (there's no way > > > to enforce non-empty passphrases or that passphrases are strong or > > > rotated regularly, for example) > > > > > In principle, this seems like it should be reasonably easy -- basically > > > just set the users' shell to be the gitorious wrapper that is normally > > > invoked by ssh. Probably need to wrap the wrapper to pass the userid on > > > the giorious command line and chdir to the repository directory. I > > > haven't looked at what is actually written to the authorized_keys file. > > > > The gitorious script (the one in script/gitorious, which does the auth > > checking) is invoked from the authorized_keys file using the command > > straining feature of the sshd. Basically the key is written as: > > command="gitorious > > johan",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty > > ssh-rsa <base64key> > > > > which invokes the gitorious script with the associated user as an > > argument ("johan" in this case). I'm not too well known in the world > > of LDAP+SSH authentication, but could something similar be done there? > > > > JS > > we have running gitorious at work too and have running the gitorious > script without public keys. For this we created a special user, who > has restricted shell: > In /etc/passwd > anongit:x:anongit_uid:groupid_of_www-data::/home/anongit:/usr/local/ > bin/gitorious_ro > > The gitorious_ro is just a copy of script/gitorious, where we > restricted write permissions to all repositories (see > http://gitorious.org/~tschamm/gitorious/tschamms-clone ). > > So i think the only thing you should change is the users push url > (e.g. git clone u...@server:project/repos.git) and the shell > restrictions (perhaps you can make usage of ForceCommand in /etc/ssh/ > sshd_config). >
Indeed, ForceCommand sounds like a better way than trying to change the default shell on only this chroot. Thanks for the tip. This should work almost exactly like the current authrorized_keys method. I just need to write a script that takes the user id from the environment and passes it to the gitorious script. Should be easy. What do I need to do on the webapp side? One mostly cosmetic thing is the clone/push URLs. Are they generated from a template or something that I could update? Another cosmetic thing would be to install gitorious in a suburl. I see that Thomas does this in his clone, but it wasn't from the commit log which commit provided this functionality. Have to look into that some more. Anything else I should think about? Thanks for your help. John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Gitorious" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/gitorious?hl=en -~----------~----~----~----~------~----~------~--~---
