1

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 [email protected]:/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.

Anthony Geoghegan
  • 12,605
  • 7
  • 59
  • 62
  • 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 07 '19 at 11:23

1 Answers1

3

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
Anthony Geoghegan
  • 12,605
  • 7
  • 59
  • 62
  • 1
    Thank you for sharing with the community in this way. The use case is common and the explanation useful. – Cbhihe Jan 05 '19 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 07 '19 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_reset`in its default `/etc/sudoers` file. – Cbhihe Jan 07 '19 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 07 '19 at 14:44
  • Thanks for posting this @AnthonyGeoghegan, you're a life saver! – Jav Jan 19 '21 at 03:48