Ssh – sudo -u git clone

gitsshsudo

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 ?

Best Answer

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"

Related Solutions

Unknown Option Flag when running with sudo

The --no-csv-summary flag was added in version 0.9, from March 2015. Your version is 0.6. The current version as of August 2016 is 1.0.2.

You may need to add the official GoAccess debian repository:

$ echo "deb http://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/goaccess.list 
$ wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key add -
$ sudo apt-get update 
$ sudo apt-get install goaccess

Or build from source, for which you can find a guide here.

How to use any command (such as git) with a normal user’s ssh keys but sudo file permissions

If you have a ssh agent running, do:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

That basically tells the git command started by root (or the ssh command started by that git command) to use your ssh agent (how to connect to it, which root should be able to as it has every right).

If you don't have a ssh agent running, you can start one beforehand with:

eval "$(ssh-agent)"

(and add keys to it as needed with ssh-add).

Alternatively, you can use

sudo -E git clone...

To pass every environment variable across sudo, not just $SSH_AUTH_SOCK.

I would not got with @NgOon-Ee's suggestion in comment to add $SSH_AUTH_SOCK to the env_keep list. In general, you don't want to pollute root's environment, as that's the user you start services as. For instance sudo sshd to start a sshd service would mean all ssh sessions started through that service would inherit your $SSH_AUTH_SOCK, polluting users environment with something they can't and shouldn't use. Even for other target users than root, passing that variable across would not make sense as the target user couldn't make use of that authentication agent.

Now, that only addresses key authentication. If you also wanted root to inherit your settings in your ~/.ssh/config, you could not do that with ssh environment variables, but you could do that with git environment variables. For instance, defining a sugit function as:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

That is, tell git to use a ssh command that uses your ssh config file and agent and username instead of root's.

Or maybe even better, tell git to run ssh as the original user:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}

Best Answer

Related Solutions

Unknown Option Flag when running with sudo

How to use any command (such as git) with a normal user’s ssh keys but sudo file permissions

Related Question