Hi Guys,

I'm new to the Ansible world, and consequently, late to this discussion.  

Here's what I've done to address the bastion host issue.   I created a 
small module called "cloudformation_extract_ssh_config".  It requires 3 
parms:
   - A cloudformation stack name 
   - An AWS region name
   - A substring of a dns name to identify the bastion server (probably 
gonna change that to an ip address)

Given those values, it walks thru the stacks, gets on that is active, then 
queries each machine therein.  After a little munging, it spits out an SSH 
config with the proxies pre-configured. 

Ex.

host test-bastion-01
     batchmode yes
     passwordauthentication no
     hostname 111.111.111.111
     user ubuntu
     proxycommand none
host test-private-ip-01
     hostname 10.0.0.10
     user ubuntu
     proxycommand ssh -qaYy test-bastion-01 'nc -w 14400 %h %p'
host test-private-ip-02
     hostname 10.0.1.10
     user ubuntu
     proxycommand ssh -qaYy test-bastion-01 'nc -w 14400 %h %p'

The downside is I have to now figure out an an elegant way to dynamically 
associate the ssh config file with the playbook without having to do 
complicated things with extra vars or hard coding values.

$0.02
-T
 

On Wednesday, October 29, 2014 8:12:07 AM UTC-5, erewh0n wrote:
>
> Based on our own experience doing this (fully automated "single click" AWS 
> VPC deployment), the only gap in the automation dynamic assignment of the 
> bastion host during playbook execution.  I would imagine the parameters 
> could be exposed as variables that playbook developers can assign via 
> set_fact.
>
> I'm a little unclear about your last paragraph though:
>
> The part that seems tougher to get a general-purpose solution for is 
>> getting ec2.py/ec2_vpc doing something sane for automatic proxy support 
>> on private VPC hosts. I think the cleanest approach would probably be to 
>> add first-class support for jump box provisioning to ec2_vpc (as has been 
>> discussed for NAT support), at which point ec2.py could have a mode to set 
>> the ansible_ssh_proxy_X vars to the jump box for hosts without a public IP. 
>> I think that would solve 99% of the issues people have with jump 
>> box/bastion host access for dynamic VPC environments.
>>
>
> I'm not sure that you want to add more to ec2_vpc (it's pretty busy 
> already).  Wouldn't having the dynamic bastion host variables be 
> sufficient?  You run ec2_vpc, set up instances, routing and security 
> groups, then you call set_fact and set the bastion host to an instance that 
> you have in your registered variables.  The selection criteria for which 
> host you choose will obviously vary, but you could, for example, base it on 
> a host group assignment.
>
>
> On Tuesday, October 28, 2014 1:06:25 PM UTC-4, Matt Davis wrote:
>>
>> I've been hacking around this for my AWS VPCs by having my VPC setup 
>> playbook drop an ansible.cfg in the playbook dir with the appropriate 
>> ProxyCommand ssh_args set to use the jump box. When it gets to 
>> provisioning, it fails (since it can't re-read ansible.cfg), then we re-run 
>> the VPC setup and provision playbooks and everything works through the jump 
>> box as expected. Hacky, but it's the cleanest thing I could come up with to 
>> work in a fully dynamic VPC env (where each dev can stand up/tear down 
>> their own multiple times a day).
>>
>> If I were going to take this to the next level, I'd probably add 
>> ansible_ssh_proxy_host, _user, and _port vars and ssh.py support to 
>> generate the right ProxyCommand config. That part looks pretty 
>> straightforward, and would probably solve a lot of folks' issues (since you 
>> could then use set_fact to configure the jump box on the fly). 
>>
>> The part that seems tougher to get a general-purpose solution for is 
>> getting ec2.py/ec2_vpc doing something sane for automatic proxy support 
>> on private VPC hosts. I think the cleanest approach would probably be to 
>> add first-class support for jump box provisioning to ec2_vpc (as has been 
>> discussed for NAT support), at which point ec2.py could have a mode to set 
>> the ansible_ssh_proxy_X vars to the jump box for hosts without a public IP. 
>> I think that would solve 99% of the issues people have with jump 
>> box/bastion host access for dynamic VPC environments.
>>
>> Thoughts? I can just push forward and kick out a PR, but if folks 
>> generally disagree with the approach, I'd rather spend my time elsewhere.
>>
>> -Matt
>>
>>
>> On Friday, August 8, 2014 4:57:59 PM UTC-7, Michael DeHaan wrote:
>>>
>>> I think I rejected this in the past, when we were young, saying you 
>>> could set this in ~.ssh/config (as you can).
>>>
>>> I'm open to it now though, for exactly those reasons.
>>>
>>> Would need to be implemented in ssh.py and probably raise warnings if 
>>> found in paramiko.py.
>>>
>>> Code submissions would be great, otherwise file a feature idea in GitHub.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 8, 2014 at 7:51 PM, Kevin Fox <[email protected]> wrote:
>>>
>>>> I'd love a feature that let you set ansible_ssh_proxy in this way. I'd 
>>>> be able to set it from my openstack inventory module.
>>>>
>>>>
>>>> On Wednesday, February 5, 2014 11:51:03 AM UTC-8, Adam Heath wrote:
>>>>>
>>>>> I've had musings on that too.  Currently, I think you'd have to 
>>>>> manually 
>>>>> configure $HOME/.ssh/config, with ProxyCommand. 
>>>>>
>>>>> However, I just had a thought.  What if there was an 
>>>>> ansible_ssh_proxy=$other_inventory_host feature?  When set, ansible 
>>>>> would auto-add the -o ProxyCommand="$something". 
>>>>>
>>>>> This is just some random brainstorm ramblings. 
>>>>>
>>>>> On 02/05/2014 12:59 PM, Jeff Lord wrote: 
>>>>> > Hello, 
>>>>> > 
>>>>> > I am building out an env in AWS using ansible and would like to 
>>>>> > configure all of my hosts by running through a single bastion host 
>>>>> which 
>>>>> > has port 22 open. 
>>>>> > Laptop -> AWS Bastion -> AWS private network instances 
>>>>> > 
>>>>> > Is there a good example of how to configure the proxy around? 
>>>>> > 
>>>>> > Thank You in advance, 
>>>>>
>>>>>  -- 
>>>> 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/304538a4-182d-40f3-ae04-4504bdb0fec5%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/ansible-project/304538a4-182d-40f3-ae04-4504bdb0fec5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> 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/692bfdf4-db36-48f9-9512-84ed5baa5413%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to