I submitted a PR a month or so ago as a possible solution to specifying bastion hosts via an inventory variable:
https://github.com/ansible/ansible/pull/9122 On Thursday, October 30, 2014, Tennis Smith <[email protected]> wrote: > Here is a possible compromise. Another way > <http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts> to > use a proxy is via this kind of ssh construct: > > ssh -o "ForwardAgent=yes" -tt [email protected] ssh -tt [email protected] > > It accomplishes the same thing. Could that be passed somehow in Ansible > in its current code? > > -T > > > On Wednesday, October 29, 2014 1:04:01 PM UTC-5, Matt Davis wrote: >> >> I suppose I could do both. I personally prefer the explicit vars- I find >> it makes the playbooks more readable and maintainable than deciphering >> ssh_args line noise. I can see where it'd nice to have the "escape hatch" >> to do unsupported things, though, too. The trick is getting everything to >> behave if things get set with the explicit vars and also in ssh_args- >> there's a bit of code in ssh.py to deal with that already (ssh_args takes >> precedence IIRC), but there would probably need to be a lot more to make it >> really robust. >> >> On Wednesday, October 29, 2014 10:26:26 AM UTC-7, erewh0n wrote: >>> >>> If there was a more generic "ansible_ssh_args" parameter, it could be >>> used however the user sees fit. It's a more flexible approach because it >>> assumes less about how the parameter might be used or implemented in SSH. >>> It just means a little more overhead for the user to know how to construct >>> that string correctly. >>> >>> >>> On Wednesday, October 29, 2014 1:04:45 PM UTC-4, Michael Peters wrote: >>>> >>>> I think that would be my preference. I know in the past there's been >>>> some pushback against implementing more ansible_ssh_* parameters >>>> because that's long rabbit whole considering the number of ssh >>>> configuration parameters that exist. I agree with this point, so if >>>> adding one more (ansible_ssh_proxy) is too much, then maybe a last and >>>> final ansible_ssh_config to point to a config file on a >>>> per-host/play/task level. Then anything you want can be put into that >>>> config file and ansible itself wouldn't have to ever add any other >>>> ansible_ssh_* parameters. >>>> >>>> Either way would solve the problem, although the latter is more >>>> complicated to implement for users (would probably need to have the >>>> dynamic inventory dynamically generate ssh config files too). >>>> >>>> On Wed, Oct 29, 2014 at 12:45 PM, Tennis Smith <[email protected]> >>>> wrote: >>>> > >>>> > How about implementing "ansible_ssh_proxy" to match >>>> "ansible_ssh_user" and >>>> > "ansible_ssh_host"? >>>> > -T >>>> > >>>> > >>>> > On Wednesday, October 29, 2014 11:36:42 AM UTC-5, erewh0n wrote: >>>> >> >>>> >> Good point -- so configuration per play might be inflexible. I >>>> guess the >>>> >> better choice is a variable that can be modified per >>>> host/group/play. Call >>>> >> it "ssh_args" and give it the same meaning as ANSIBLE_SSH_ARGS. >>>> Assign it >>>> >> per host, group or play where required and use the "-o" option to >>>> pass in >>>> >> ProxyCommand parameters. >>>> >> >>>> >> This seems pretty clean, although I'm not sure what the convention >>>> is for >>>> >> exposing new "global" variable state in Ansible. :) >>>> >> >>>> >> >>>> >> On Wednesday, October 29, 2014 12:19:41 PM UTC-4, Michael Peters >>>> wrote: >>>> >>> >>>> >>> Another use case to consider (that I myself have come up against) >>>> is >>>> >>> configuring the bastion per-host from a dynamic inventory. The >>>> servers >>>> >>> need to use a different bastion depending on their role and >>>> location. >>>> >>> >>>> >>> On Wed, Oct 29, 2014 at 12:17 PM, erewh0n <[email protected]> >>>> wrote: >>>> >>> > Thinking on this a bit more ... it seems there are two use cases >>>> here: >>>> >>> > how >>>> >>> > to dynamically change your SSH control connection during playbook >>>> >>> > execution >>>> >>> > and how to subsequently refer to the new bastion host on >>>> subsequent >>>> >>> > calls to >>>> >>> > ansible-playbook. If you could set SSH arguments per play, then >>>> I >>>> >>> > think >>>> >>> > both of these cases are addressed: >>>> >>> > >>>> >>> > - hosts: all >>>> >>> > connection: ssh >>>> >>> > connection_args: >>>> >>> > proxy_host: {{ groups.bastion[0] }} >>>> >>> > proxy_port: 22 >>>> >>> > user: johndoe >>>> >>> > >>>> >>> > The 'connection_args' feature implies you no longer require SSH >>>> config >>>> >>> > files >>>> >>> > (but could optionally use them if preferred). It could be used >>>> >>> > dynamically >>>> >>> > within a playbook to override your defaults that come from >>>> >>> > "ANSIBLE_SSH_ARGS", for example. >>>> >>> > >>>> >>> > I can see an argument for just specifying raw SSH command line >>>> >>> > arguments as >>>> >>> > well, something like: >>>> >>> > >>>> >>> > - hosts: all >>>> >>> > connection: ssh >>>> >>> > connection_args: >>>> >>> > command_line: "-o ProxyCommand ssh -W %h:%p -l johndoe >>>> johndoe@{{ >>>> >>> > groups.bastion[0] }}" >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > -- >>>> >>> > 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 [email protected]. >>>> >>> > To post to this group, send email to [email protected]. >>>> >>>> >>> > To view this discussion on the web visit >>>> >>> > >>>> >>> > https://groups.google.com/d/msgid/ansible-project/ >>>> 2f75fa3d-cc99-4bc5-aa3b-28562d9d8db9%40googlegroups.com. >>>> >>> > For more options, visit https://groups.google.com/d/optout. >>>> > >>>> > -- >>>> > 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 [email protected]. >>>> > To post to this group, send email to [email protected]. >>>> > To view this discussion on the web visit >>>> > https://groups.google.com/d/msgid/ansible-project/ >>>> df0108fb-0405-4f10-8b04-2295a3912b7a%40googlegroups.com. >>>> > >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > 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 [email protected] > <javascript:_e(%7B%7D,'cvml','ansible-project%[email protected]');> > . > To post to this group, send email to [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/11928401-fc81-4fe2-946d-7d74dbd671aa%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/11928401-fc81-4fe2-946d-7d74dbd671aa%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Matt Martz @sivel sivel.net -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAD8N0v9HwugTWmfyYJvVJ9JrivRtE9c-W0RHYgVv4GppgW0gdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
