Using su/sudo when accessing remote Git repositories over SSH

Question

Suppose that there is a remote Git repository R on a Linux server. R is owned by a user U for which a remote login via SSH is not allowed at all (eg root ). Neither password-based nor key-based authentication is available for that user. What is allowed, however, is logging on as a different user and then using su or sudo to issue commands as U .

Is it possible to combine these two methods so that Git will use su or sudo on the remote server in order to access the repository?

Alternatively, is there another method to access R without changing its access permissions or enabling SSH logins for U ?

PS: I don't mind having to type passwords manually eg at an su prompt, as long as Git handles the rest.

EDIT:

It seems from the comments that I need to clarify my reason for wanting to do something like this. The files tracked by R are system files that are in use by the server in question - R is not a bare repository. That means that the repository cannot really be moved, not without a lot of trickery.

Getting Git to use sudo would allow R to be accessed using the same security model that protects these files, rather than through a separate avenue that would have to be configured and synchronized separately.

Answer 1

Oh, you can do

git config remote.origin.uploadpack "sudo -u U git-upload-pack"

to get git fetch to use sudo for the remote called origin .

You'd need to ensure sudo is set up to allow this user to execute this command with no password, as I see no way to prompt for password.

Source:

I found myself wanting to do a somewhat similar thing, and found this nugget thoroughly buried in man git-config

I should point out that this does only half the job as I needed only git fetch to work. I imagine you could do a similar thing with remote.origin.receivepack in order to get git push to work but I have not tried that.

Answer 2

What is easier is to establish another listener than the sshd dameon: setup an Apache, which:

• can run as root (as explained in " How do I run Apache as root? ", that is not a good idea/practice, because any new vulnerabilities found in Apache, which can then be exploited as... root )
• can redirect the git queries to the git-http-backend script, which allows for git commands over http (called smart http , documented here )

That way, you don't have to worry about sudo and su .

And you can couple that with an authentication step if you want.

<Location /git>
  AuthType Basic
  AuthName "Private Git Access"
  AuthUserFile "/etc/git-auth-file"
  Require valid-user
</Location>

You even can add authorization with gitolite .

Answer 3

Git comes already with some server-features to make repositories accessible for client users. One serving solution which seems to fit your needs best is using the git-shell .

The git-shell allows you tie ssh-users up with git-repositories. After successful authentification these users end up in the git-shell which prohibits shell-operations but - if accessed through a git client - gives full access to the hosted repositories.

The only thing you must do is:

1. Go to the /etc/passwd on your server

2. Find the line of the user you want give git-access (probably its name is git )

   Warning: Do not change the entry of your current user! You won't be able to log in via shell anymore!

3. Change the shell-reference of that user from (fe) /bin/bash to /usr/bin/git-shell (the specific paths depend on the configuration of your system).

The set-up-procedure for such a scenario is in detail described in the pro git book .

---

To enhance gits simple serving features (in the future) with rights management, you may use gitolite - which uses the gitolite-shell (and replaces the git-shell) to provide it's magic superpowers.

Answer 4

A very simple solution would be to git clone the repo into the "different user" (which I'll call U2)'s directory, and then use ssh access against that repo. git is a decentralized VCS, so there's no such thing as an "owning" repo. All repositories are on equal footing.

You could either occasionally manually push changes from the U2 repo back into the U repo using sudo from the remote machine or you could even setup a post-commit hook which automatically pushes changes to the U2 repo back to the original U repo. The post-commit hook would work fine as long as no one else is directly modifying the U repo.

If you do have someone directly modifying the U repo, then someone will need to pull in the changes either in the U2 repo or the U repo and merge them on a regular basis. Depending on the scope of these changes, the merges could be trivial or complex. However, I'd recommend just disallowing anyone to directly modify the U repo unless you have a good reason for it. In this particular scenario, the U2 repo becomes the de facto authoritative repo, anyway. So in some sense you could drop the original U repo all together.

This is in fact the other simple approach to take which is to simply make the U repo directly accessible to the U2 user by moving it. I know you said in your question that you didn't want to modify the original permissions, but this sounds like a silly and very non-standard arrangement for the repo. The whole point of a git repo is to make it available for changes, and if you can't do that simply, then I would say your initial configuration is flawed.