Script to perform a git pull via ssh and bypass passphrase requirements?

Question

I'm trying to set up continuous integration with Bamboo. I want to configure a task that ssh's into our stage server, cd's into the proper directory and performs a git pull.

I've been able to set up the ssh task, but doing the git pull has been difficult.

Steps I've taken:

• Configured an ssh task to cd into the project directory and run the following script:

  #!/bin/bash
  echo "pulling from master"
  git pull origin master
  

• The script runs, but the logs show a Permission denied (publickey). error after it tries to pull.

• I switched my remote-url from HTTPS to ssh and created a publickey. Now when I try to do a manual pull it asks for the key's passphrase.

• Used ssh-agent to cache the passphrase for a session.

• Realized that this cache only persists until I close my session so I followed the steps from this article (https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git) to start ssh-agent with every new session. Namely I added this script to my .bashrc:

  SSH_ENV=$HOME/.ssh/environment
  
  # start the ssh-agent
  function start_agent {
      echo "Initializing new SSH agent..."
      # spawn ssh-agent
      /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
      echo succeeded
      chmod 600 "${SSH_ENV}"
      . "${SSH_ENV}" > /dev/null
      /usr/bin/ssh-add
  }
  
  if [ -f "${SSH_ENV}" ]; then
       . "${SSH_ENV}" > /dev/null
       ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
          start_agent;
      }
  else
      start_agent;
  fi
  

and added this to the .ssh/config file:

Host myStashInstance.org
 IdentityFile ~/.ssh/id_rsa

• The article said that I should be prompted to enter the passphrase and the agent would start up but that hasn't happened. I still need manually start ssh-agent.

I would like to know what the next steps would be to getting ssh-agent to start when I start a new session so I can continue figuring out how to finish configuring this job. (Also open to suggestions for other avenues to pursue if I'm completely on the wrong path.)

Answer 1

To summarize, you're running into the following issue:

• The Bamboo Agent runs on server A
• Server B is your staging server
• As part of the build running on server A, you want to SSH into B and do a git pull there.
• Authentication to the Git repo requires you to either enter a password or a passphrase (even when using ssh-agent).

There are several ways this could be solved:

Option 1: Run Bamboo Agent on the Staging Server

To simplify this environment, install the Bamboo Agent on your Staging Server. Enter the Git URL and credentials in the Bamboo build plan and let Bamboo take care of the work.

Bamboo will pull the Git repo, you can then run whatever steps you want and deploy to your staging server process.

Option 2: Deploy to the Staging Server

Instead of doing the Git operation on your staging server, do it on server A. Enter the Git URL and credentials in the Bamboo build plan and let Bamboo take care of the work.

Once your project is checked out on server A, run whatever build steps you want to do there, then package (zip/tar/jar/...) the build results and copy them over to the Staging Server. Maybe you don't need to use Git on the Staging Server at all.

Option 3: Use the .netrc file for Git authentication

This is the least secure of the options. Switch back your remote URL to HTTPS, then create a ~/.netrc file on the staging server and add an entry for your Git server in there, providing username and password, as described here: https://confluence.atlassian.com/display/STASH/Permanently+authenticating+with+Git+repositories#PermanentlyauthenticatingwithGitrepositories-Usingthe.netrcfile

Example:

machine mygitserver
login mario
password SECRET

Caution, this requires you to store your password in plain text in the .netrc file. Only use this method if you can live with this risk. If the password used for this account changes, you will have to change it in this file as well. You probably want to use a technical/service account for this, not a real user account. Lock down this account as much as possible.

One of these three options should help you to solve your problem.