Re: [ansible-project] Git module - SSH connection with keys

[Michael DeHaan]

On Thu, Feb 7, 2013 at 8:42 PM, C. Morgan Hamill <cha...@wesleyan.edu> wrote:
> Howdy all,
>
> Re: this previous discussion, I've been thinking about patching the git
> module to allow the
> specifying of a user, a private key, and a password to unlock the key for
> git to use when
> communicating with a remote over SSH.

Generally this was written for deployment purposes.

Just curious on your use case:

(A) So in your organization the repo is locked down?

(B) Or you are automating developer machine setups?

I can see both being useful, but I'm guessing A, right?

(If you are pulling off a repo that is non-secured and it is just for
deployment purposes, I'd probably just clone read only)


>
> It seems to me that whether I handle this by launching `ssh-agent` and
> adding the key to it,
> or by passing appropriate flags to `GIT_SSH` before invoking `git`, I've got
> to somehow pass
> the password to unlock the key at some point.

I'm going to add some cool tricks to pass environment variables to
/everything/ really soon, and this may be exactly what you want.

Can you hold off a few days maybe? It would allow for GIT_SSH
trivially, without modifying the module.

[C. Morgan Hamill]

On Friday, February 8, 2013 8:33:59 AM UTC-5, Michael DeHaan wrote:

Generally this was written for deployment purposes.

Just curious on your use case:

(A) So in your organization the repo is locked down?

(B) Or you are automating developer machine setups?

I can see both being useful, but I'm guessing A, right?

Correct.
 

(If you are pulling off a repo that is non-secured and it is just for
deployment purposes, I'd probably just clone read only)

Which reminds me that the "correct" way to do this is either to allow
authentication-less read-only clones, or to set up read-only https
access to the repos with basic auth.

Which of course means scratch all this.

I'm going to add some cool tricks to pass environment variables to
/everything/ really soon, and this may be exactly what you want.

Well, I certainly want that generally, but I imagine in this scenario,
even if I do `GIT_SSH="ssh -i <keyfile>" or somesuch, I've still got to
provide a password to unlock the keyfile, and doing that programatically
seems to remain an issue.

Which brings to a couple of ancillary questions, actually:

Is there any consensus on requiring target-host-side software in
modules? My (non-)issue could be solved by the use of expect, or
perhaps sshpass, on the target-side. I'd imagine that those kind of
things ought to be kept out of the included modules, though, correct?
Barring inevitabilities like the git module needing git, obviously.

On that note, what about dependencies on python modules outside of
the standard library? I assume it's preferred if the module is
self-contained, no?

And one final question, if you don't mind: has any thought been put into
a means to pass requests for input on the target-side (i.e., ssh asking
for a password) back to the user for interactive input? I should probably
see how the ssh-askpass stuff is implemented.

Can you hold off a few days maybe?   It would allow for GIT_SSH
trivially, without modifying the module.

I certainly can, especially because I've likely found a way around the
issue.

Also, just a quick thanks for ansible (and your work on cobbler, also); I
work in a shop particularly fond of leaving repetitive tasks unautomated,
and the simplicity of ansible's model is just about the only chance I have
of rectifying that. Keep up the excellent work!
--
Morgan Hamill
 

[Michael DeHaan]

Environment control support is available in Ansible 1.1 and later.

Look up the "environment:" keyword in the docs.

On Wed, May 1, 2013 at 6:07 AM, David Wu <david...@gmail.com> wrote:

I ran into the same problem (needing to clone a git repo that is only privately accessible via a key).  I'm wondering if the feature for passing an environment variable is implemented in the most current version of ansible yet?

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Wu]

Thanks!  In case anyone is in the same boat in the future, here is the link to the relevant section in the docs:  http://ansible.cc/docs/playbooks2.html#setting-the-environment-and-working-with-proxies.

I was able to clone a private repo by setting the GIT_SSH environment variable.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/Tumb7svuGwg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

[C. Morgan Hamill]

Would you mind sharing what you passed to GIT_SSH, out of curiosity?
--
Morgan

[David Wu]

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=600

- name: Configure SSH script

  template: src=git_ssh.j2 dest=/tmp/git_ssh.sh mode=700

- name: Clone the git repo using GIT_SSH

  git: repo=ssh://g...@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:

#!/bin/sh

exec /usr/bin/ssh -o StrictHostKeyChecking=no -i /tmp/id_rsa_deployment "$@"

[Michael DeHaan]

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?

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[John Jarvis]

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://g...@bitbucket.org/username/someprivaterepo.git dest=/path/to/project git_key=/path/to/git-identity

In any case it's definitely a common pattern and it would be helpful to add it to the docs.

[Michael DeHaan]

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 :)

[C. Morgan Hamill]

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://g...@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...
--
Morgan

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[C. Morgan Hamill]

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.
--
C. Morgan Hamill
<cha...@wesleyan.edu>

[Serge van Ginderachter]

On 2 May 2013 19:09, C. Morgan Hamill <cha...@wesleyan.edu> wrote:

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​

[Scott Anderson]

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

[Serge van Ginderachter]

On 2 May 2013 20:00, Scott Anderson <scottan...@gmail.com> wrote:

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). 

​Maybe this can help (didn't test it yet):

https://github.com/ansible-contrib/ansible-plugins/blob/stable/library/known_host​

​Serge​

[Jesús García Crespo]

On Thu, May 2, 2013 at 4:58 AM, Michael DeHaan <mic...@ansibleworks.com> wrote:

Does anyone else have a different way of doing this they may also want to share?

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.

 

--
Jesús García Crespo

[Scott Anderson]

On May 2, 2013, at 2:04 PM, Serge van Ginderachter wrote:

Maybe this can help (didn't test it yet):

https://github.com/ansible-contrib/ansible-plugins/blob/stable/library/known_host

Nice, thanks Serge, I'll try it out when I get a chance.

Regards,

-scott

[Scott Anderson]

On May 2, 2013, at 2:05 PM, Jesús García Crespo wrote:

>
> 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.

I use connection=ssh to make agent forwarding work.

Regards,
-scott

[Michael DeHaan]

Seems to be the cleanest approach and shares the least data with the host.