4

I'm on Ubuntu server 14.04.

I am using apache web server which runs as the www-data. I need to do git clone from a script (a web hook). This script will run with www-data user privilages.

Running git clone as a regular user in the /var/www/html directory I run in to permission problems which is good since I only want the www-data user to be able to write there.

The www-data user has its home set to /var/www and it's ssh keys are in /var/www/.ssh .

If I run:

sudo git clone git@my.git.server:user/repo.git

It works as expected - the ssh public key for my user is listed as in authorized_keys @ my.git.server.

However I need to run from a bash script and with normal privileges.

So I copied the public ssh key for the www-data user to the authorized_keys file at my.git.server. In theory that should mean the www-data user can initiate git clone over ssh removing the need for passwords and being pretty secure.

So to test it I think I need to run something like:

sudo -u www-data -H git clone git@my.git.server:user/repo.git

My understanding is that would let me assume the identity of the www-data user, set my home directory so that ~/.ssh is in the working directory when the git clone over ssh is issued.

The issue I have is the following error output when I try to execute that command:

Cloning into 'repo'...
fatal: 'user/repo.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Like I said if I run as sudo - no issue. Only when I try to run as www-data. It feels like there's an issue with the way the command is being interpreted that forces it to read the path / repo name incorrectly ?


Following on from l0b0's response, the output is as follows:

james-c@WebHost-1:~$ sudo ssh -v git@my.git.server 2>&1 | grep 'identity file'
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
james-c@WebHost-1:~$ sudo -u www-data ssh -v git@my.git.server 2>&1 | grep 'identity file'
debug1: identity file /var/www/.ssh/id_rsa type 1
debug1: identity file /var/www/.ssh/id_rsa-cert type -1
debug1: identity file /var/www/.ssh/id_dsa type -1
debug1: identity file /var/www/.ssh/id_dsa-cert type -1
debug1: identity file /var/www/.ssh/id_ecdsa type -1
debug1: identity file /var/www/.ssh/id_ecdsa-cert type -1
debug1: identity file /var/www/.ssh/id_ed25519 type -1
debug1: identity file /var/www/.ssh/id_ed25519-cert type -1

Not exactly sure what I'm looking for here ?

  • Have you verified you can log in to the remote machine as the www-user? – Faheem Mitha Jul 10 '14 at 15:06
  • Yes I can log in with the following: sudo -u www-data -H ssh git@my.git.server with no issues. – James C Jul 10 '14 at 15:08
  • Just wondering if there is some sort of syntactic sugar I can use with { } or '' "" etc to encapsulate the URI for the repository ? – James C Jul 10 '14 at 15:12
  • Are you able to clone if you first become www-data with sudo -u www-data -i and then try the clone command? The "fatal: 'user/repo.git' does not appear to be a git repository" message looks like the error might be on the git server side. – Jesusaur Aug 2 '16 at 19:09
  • Is the repository already checked out by root maybe? If www-data can't write to the .git directory in the checked-out repository, it will not recognise it as valid. – Kusalananda Apr 7 '17 at 8:55
2

I encountered the same issue, it seems like the environment is preserved when switching users this way. This causes the wrong git config to be loaded, which fails due to permission problems.

In my case I circumvented the problem by using the following command

sudo -u deploydeputy /bin/bash -c "export HOME=/home/deploydeputy && git clone git@github.com:inventid/cdn.git /tmp/cdn"
  • Needless to say this was a while ago now - thanks for the reply though Rogier. Much apreciated! – James C Nov 20 '17 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.