Yrurtj

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.

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 most GNU/Linux distributions ship 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