0

I use etckeeper to keep my various OS configurations under version control. Until now, I was content to just use a local Git repository to keep track of changes but it occurred to me that I wasn’t making the most of this feature and I decided that it would be useful to configure a remote repository to keep copies of these repositories so that the /etc configurations are available from other machines.

On the remote server, I created a bare repository (ensuring only the git user can access its contents):

sudo -u git -H git init --bare ~git/repos/anthony-etc.git
chmod -R 700 ~git/repos/anthony-etc.git/

The SSH daemon on the remote server was configured to allow users (including the git user) to use only keys for authentication – and I had already uploaded my personal public key to the .authorized_keys of the git user on the server.

On the local machine, I added this as remote repository:

sudo git remote add origin git@example.com:/home/git/repos/anthony-etc.git/

Since only a super user can modify files in the /etc directory (including its .git sub-directory), all the Git commands are run using sudo.

Before attempting to push using SSH, I checked to see if I could use my current SSH authentication agent:

$ sudo ssh-add -l
Could not open a connection to your authentication agent.

This failed when being run using sudo and I was wondering how I could configure sudo to work with the SSH authentication agent that I’m already using as a non-super user.

  • FAO downvoter: I posted this question and answer as I thought it could be helpful to others and there is always the chance that someone else might post another answer with an alternative (better or more secure) solution. If you can suggest a way to make this question clearer or more useful, I'd be happy to hear it. – Anthony Geoghegan Feb 7 at 11:23
2

The reason it did not work was because the SSH_AUTH_SOCK variable used to store the filename of the SSH agent’s Unix domain socket was not in the environment when running commands via sudo.

By default, the env_reset option is enabled in the sudo security policy and many GNU/Linux distributions make this explicit by shipping with the following line in their /etc/sudoers configuration file:

Defaults    env_reset

This ensures that commands are run in a minimal environment with most of the invoking user’s environment variables removed in the restricted environment.

Specific variables can be white-listed so that they are preserved in the environment. For safety, I use the visudo command to edit the sudoers configuration file. Also, rather than modifying /etc/sudoers directly, I add custom modifications to a separate file in the /etc/sudoers.d/ directory. To do this, I run sudo visudo -f /etc/sudoers.d/custom so that the configuration contains the following line:

Defaults    env_keep += "SSH_AUTH_SOCK"

Now, running sudo ssh-add -l shows that I can connect to the authentication agent and I can go ahead and update the remote repository:

sudo git push --set-upstream origin master
  • 1
    Thank you for sharing with the community in this way. The use case is common and the explanation useful. – Cbhihe Jan 5 at 18:14
  • Thanks @Cbhihe I figured this would be helpful to others but I was also hoping that someone else might post an answer with an alternative (better or more secure) solution. – Anthony Geoghegan Jan 7 at 10:07
  • I am not sure you could improve on the security side. What you are doing with sudoers seems completely legit. As an aside, current Arch linux does not include Defaults env_resetin its default /etc/sudoers file. – Cbhihe Jan 7 at 14:15
  • Thanks @Cbhihe I've only used Red Hat and Debian-based distributions so I've clarified my answer a little. – Anthony Geoghegan Jan 7 at 14:44

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.