How to avoid typing passphrase for git pull executed under www-data

I stuck on the operation when I need to execute Git pull command running from PHP script. (user is added into www-data group) without passphrase typing. I found that this can be solved using command:

eval "$(ssh-agent)"


But this command is working only under my own user (for example george). But if i try to execute following command under www-data in git cloned repository :

  • How does commit signing work?
  • Git upload project full site
  • How do I prevent some branches from ever being fetched by others?
  • Can I change the default directory on my local drive for all Git activity?
  • Adding a git commit message using vi on OS X
  • How to check out a version with tig or command line?
  • sudo -u george git pull

    I always obtain following messsage

    Enter passphrase for key '/home/george/.ssh/id_rsa': 

    Note: I add user to www-data group and to visudo users too. But i don’t know, how to solve password passing or avoiding to passphrase typing.

    Many thanks for any help.

  • Qt Creator, build dir with branch name
  • Finding diff between two git repositories
  • Why does git status show branch is up-to-date when changes exist upstream?
  • Configure the git commit used for Change Markers
  • git permission denied but for different user
  • Merging two repos with gitolite
  • One Solution collect form web for “How to avoid typing passphrase for git pull executed under www-data”

    There are several ways to achieve what you want:

    1. The most “correct”, in my eyes, way is:

      1. Generate a special SSH key for your www-data user, and make sure this key is not encrypted with a password — because it’s this passphrase which is asked for by the SSH client to decrypt the key which is then used for authentication.
      2. Deploy that key remotely (highly depends on your setup) so that it could be used for read access.
      3. Next, you have to make this key readable by the www-data user, and only that user (!), — that is, the key file must be owned by www-data and has 0600 (-rw-------) permission bits set on it.

        There are several ways to achieve this:

        • Since the SSH client looks for the key file under the ~/.ssh directory (that is, the .ssh directory under the home directory of the user), you have several options:
          • If your www-data user has real home directory on the file system (you could know by running getent passwd www-data), you could create the .ssh directory in there and place the key in it.
          • In your pulling script, override the HOME environment variable (and export its new value) before running git, so that the SSH client resolves the home directory to some other place. The rest should be set up as described above.
        • The SSH client supports per-user configuration, where one can specify where the key should be searched for and even specify different keys for different servers. Refer to the ssh_config(5) manual page.
        • SSH clients typically support specifying the location of the key file on the command line. The OpenSSH client binary, typically used on common Linux-and BSD-based OSes, supports the -i command line option (stands for “identity”). So another way to go is to write a wrapper script which just calls ssh -i /path/to/the/key/file and put the path to that script into the (exported) environment variable GIT_SSH so that Git calls your script instead of just ssh.
    2. Using sudo is another option (though I dislike it) but most probably the new process running with modified credentials does not inherit certain environment variables existing in your session which tell the SSH client how to contact a running instance of ssh-agent which has your decrypted key cached (yes, the existence of this agent is why you’re only required to type your passphrase once in an interactive login session).

      So you could read up on how ssh-agent works and how to make sudo preserve the environment variables related to it when running your Git binary with modified credentials.

      I’m not exactly sure it will work as there still might be a permissions problem with accessing the Unix-domain socket (or a fifo? — I can’t recall at the moment) offered by a running instance of ssh-agent for contacting it, so you’ll need to do some research.

    3. Use a program like sshpass to feed the password to the SSH client.

      This could be done either directly or by wrapping the SSH client itself (see above).

      Note that this approach stinks as it implies the password will be stored somewhere in a clear text in some script. So you have to make sure this script is protected in the same way the unencrypted key would be protected in the first case.

    Yet another option would be to offer access to your repository using a read-only unauthenticated protocol (git:// or file:// schema — whichever is applicable). The idea is that a repository might be accessed in a number of ways, and even different URLs (with different schemas — meaning protocols) might be used for fetches and pushes for the same named remote.

    Git Baby is a git and github fan, let's start git clone.