What is it ?

Git is a fast, scalable, distributed revision control system.

Quoting excerpts from the README file:

"gitosis" aims to make hosting ``git`` repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. End users do not need shell accounts on the server, they will talk to one shared account that will not let them run arbitrary commands.

For the purpose of this document, the owner of the shared git repository is called 'shared user'. Other users who are granted access to the 'shared user' account are called 'end users'.

Usage & Requirements

gitosis and git packages are installed on CSE login servers and most lab machines, allowing access to shared git repositories via these servers.

End users can then 'clone' a copy from the master and run git related commands on the local copy per usual to manage file or directory objects within the repository. Where git is not installed on a given server, it would not be possible to access shared git repositories set up under gitosis.

Normally repositories are hosted within a given user's login home directory which is auto mounted on a CSE/lab machine, so git commands can use 'localhost' where this is specified as part of the arguments.

Documentation also mentioned that the shared user account doesn't need to have a password, but does need to have a valid shell for SSH to work.

Configuration

Highlighted below are few areas of configuration worth noting:

gitosis relies on SSH keys to allow end users to share git repositories hosted under a shared user account.

Public key entries inserted by gitosis are restricted to allow only certain commands to run.
They are appended to the <shared user>/.ssh/authorized_keys.
Any existing keys in the <shared user>/.ssh/authorized_keys file would be left intact.

Below is a typical default key entry (of type DSA) inserted by gitosis: command="gitosis-serve <username>@<server>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss [ ...<public key code>...] <username>@<server> Note the 'gitosis-serve' command is relative and should be modified to full path '/usr/bin/gitosis-serve' for added security.
command="/usr/bin/gitosis-serve <username>@<server>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss [ ...<public key code>...] <username>@<server> Apart from that, unless you know what you're doing, the inserted key entries must NOT be modified in other ways otherwise security can potentially be unnecessarily compromised due to intentional/unintentional changes.

End user's public key is copied to <shared user>/repositories/gitosis-admin.git/gitosis-export/keydir without the .pub extension.
To grant an end user access to the shared user's repository, just add the end user's public key to the keydir folder, and then give the user permissions by modifying gitosis.conf (see next).

gitosis configuration lives in <shared user>/repositories/gitosis-admin.git/gitosis.conf
Here can specify access control (eg. readonly, read/write) of end users to each shared repository.
EG. [group developers] members = todd bill writable = project1 project2 [group webguys] members = travis chris readonly = project1 In this instance, travis and chris only have read access to the project1 repository, whereas todd and bill have full write access to project1 and project2.

Precautions & Good Practices

As far as possible only public keys associated with local CSE accounts should be used, not those created from remote like from home PCs etc.
This should be true in general not just those end user accounts who intend to use gitosis.

Due to the way course class accounts are set up, they are NOT to be used for hosting shared git repositories.
See further details in Taggi page SSH authorized keys for course class accounts.
Should a shared user account with shared git repositories become at some point a member of a course class account(s) by virtue of class membership, scripts have now been adjusted to ignore any gitosis related public key entries in <shared user>/.ssh/authorized_keys file. Other keys however will continue to be propagated per usual.

Normal group accounts (see taggi page Group accounts for further details) belonging to Utility class are typically set up for file sharing and/or web hosting within a user group and either with nologin (no SSH access) or with SSH access. Those with nologin access are not suitable for hosting shared git repositories since a valid login shell is required for SSH to work. In this case, should you think otherwise and have a burning case to use the group account for shared git repositories, please consult Systems Support to discuss the best way forward.

Each local copy of git repository would be owned by the respective end user, so disk quota would be charged against the end user's account and subjected to whatever constraints and behaviours in the usual way.
The same applies to the shared copy of git repository under gitosis which is owned by the shared user.
In any case, it's important to allocate enough disk space to cover the anticipated usage for both the shared user account and the end user accounts.

For configuration variables that can apply globally such as daemon in the gitosis config file gitosis.conf, extra care should be exercised as all repositories are affected. Where supported, per-repository scope should be used instead wherever possible for better control and minimising unnecessary 'side-effects'.

References

See readme and others in /usr/share/doc/gitosis.
Git related man pages eg. git(1), git-clone(1), gittutorial(7), gittutorial-2(7), etc.

cse taggi

Gitosis