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] > <javascript:>> 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] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > 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]. 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/bc3cde6e-a263-4d3a-ad4d-731ddf05fc7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
