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

Question

I can clone a project as follows:

$ git clone [email protected]:root/myproject.git ~/bla

But now I wish to clone it to /var/www. So I try

$ git clone [email protected]:root/myproject.git ~/var/www

But alas, I do not have permission to write to /var/www. Sudo to the rescue!

$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:

What's this? I am being asked for a password? We shouldn't need no stinking passwords!

I am obviously sending the root user's ssh keys with the request, and as they have not been imported to the git repository, I am being denied. In the past, my solution has been to temporarily change permissions of the folder or first clone it somewhere I have access and then move it using sudo, but would like to learn the right way to do so.

So... How do I use git with my normal user's ssh keys but sudo file permissions?

Solution

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 "$@"
}

Comments

[Admin]

this will be problematical if your user home directory is encrypted or remote mounted such that the user-being-sudo'd-to cannot read the key materials

[Admin]

@thrig Thanks, but fortunately it isn't.

[Ng Oon-Ee]

This won't help if there's anything in .ssh/config needed (e.g. a ProxyCommand). Also the right way for this solutions would be to use visudo and add SSH_AUTH_SOCK to env_keep

[user1032531]

Thanks Stephane, Appreciate your solution, but kind of surprised there is not a more intuitive one.

[Stéphane Chazelas]

@NgOon-Ee, see edit.

[Ng Oon-Ee]

Fair point in env_keep, but I would still prefer that in the (IMO most common) single user configuration. Sudo is used fairly rarely in modern Linux, and perhaps shouldn't even be used here (maybe I'll write up that answer as an alternative).

[Jeffrey Van Alstine]

I ran into some problems with using git over https with git lfs (it wants to put in the password for every single file downloaded), so I tried swapping to an ssh connection but couldn't sudo clone in my production environment. All I needed was that sudo -E. Now it's working like a dream with my ssh key.