Would you mind sharing what you passed to GIT_SSH, out of curiosity?
Sure thing.
I have a private repo that requires accessing via an SSH key. Here is what I do in my playbook:
name: Upload the SSH key
copy: src=id_rsa_deployment dest=/tmp/id_rsa_deployment mode=600name: Configure SSH script
template: src=git_ssh.j2 dest=/tmp/git_ssh.sh mode=700name: Clone the git repo using GIT_SSH
git: repo=ssh://git@bitbucket.org/username/someprivaterepo.git dest=/home/username/project depth=1
environment:
GIT_SSH: /tmp/git_ssh.sh
And the git_ssh.j2 content is as follows:
We should probably put this in the git module documentation.
Does anyone else have a different way of doing this they may also want to share?
We do the same thing here, I could see this being a new option in the git module to reduce boilerplate:
I would really like to see this, how about sending a patch?
I think this is better than a param to pass GIT_SSH as nobody knows how that works 
Excerpts from John Jarvis's message of 2013-05-02 10:47:47 -0400:
We do the same thing here, I could see this being a new option in the git
module to reduce boilerplate:- name: Upload the SSH key
copy: src=path/to/git-identity dest=/path/to/git-identity mode=600- name: Clone the git repo using GIT_SSH
git: repo=ssh://git@bitbucket.org/username/someprivaterepo.git
dest=/path/to/project
git_key=/path/to/git-identity
I would love this also.
Does anyone happen to know if there's any simple way to do something
along this lines when the SSH key in question is locked with
a passphrase (not just in Ansible, but more generally when you can't
unlock the key interactively)?
I imagine there'd have to be either an ssh-agent dance or a sshpass
dance, but I'd love to be proven wrong.
I suppose using an unlocked key and removing it after use would be
enough, really.
Perhaps the proposed patch could even take care of copying the key over,
storing it temporarily, and killing it after the git clone is done?
That might be insane...
Would probably be best to have your git repos mirrored publically, in all fairness.
Having your deploys reliant on the cloud servers seems a bit sketchy.
Excerpts from Michael DeHaan's message of 2013-05-02 12:19:53 -0400:
Would probably be best to have your git repos mirrored publically, in all
fairness.
If only! Unfortunately, I'm not in a position to make the code
in question available outside of our shop.
Having your deploys reliant on the cloud servers seems a bit sketchy.
We're pulling from an on-site git repository which allows ssh key access
only. I know that the right answer in this case is a passphrase-less
key with read-only access to the repository, but my curiosity can't help
but wonder if there's a way to have a setup with a key passphrase.
Maybe have a look at keychain: you could add the passphrase to keychain in
a first task, register it's output (keychain --noask --eval id_dsa
2>/dev/null) with needed environment variables, then run your git module
with those variables set in the environment.
That *might* work.
Serge
I’ve got private repos with SSH keys with pass phrases… I use agent forwarding to make it work. That way the key is only ever on the machine of the person doing the deploy.
It works for both direct and sudo access. There is a slight hitch that I haven’t bothered to overcome yet: the github remote key has to be accepted first (ie. test the github access from the account doing the deploy so it shows up in known_hosts).
I’m happy to give more details if this sounds interesting to anyone.
-scott
Maybe this can help (didn't test it yet):
https://github.com/ansible-contrib/ansible-plugins/blob/stable/library/known_host
Serge
I don't know if Ansible supports SSH agent forwarding through paramiko or
ssh, but it would be cool to make a local agent with the keys that you need
temporary available in the remote host. As soon as the git module is done
you could close the agent to limit any potential risk.
Nice, thanks Serge, I’ll try it out when I get a chance.
Regards,
-scott
I use connection=ssh to make agent forwarding work.
Regards,
-scott
Seems to be the cleanest approach and shares the least data with the host.