Proposal to add ansible_ssh_config inventory parameter

Archives Ansible Project
1

Hello all,

First, being new to ansible and the ansible community, and having already this proposal rejected in a pull request (https://github.com/ansible/ansible/pull/3756)
let me know if the path I’m taking to have my arguments heard is the good one and I do not hurt or annoy anyone.

I began with a problem I’m far from the only one to have: using ssh jump hosts.
Apparently, the only ways to manage it with ansible are either via ANSIBLE_SSH_ARGS/ansible.cfg or via an entry in ~/.ssh/config.

The first is far from convenient:

  • According to http://www.ansibleworks.com/docs/gettingstarted.html#id4, if you use ANSIBLE_SSH_ARGS you loose the “sensible ControlMaster options”.

  • These parameters are system-wide/user-wide, and outside of the ansible

  • I want to version my ansible playbooks/inventory

  • I expect my ansible playbooks/inventory to be playable on any out-of-the-box ansible installation, like you’d expect any PDF file to open on any PDF reader out of the box.

The second is also inconvenient

  • it’s a user-wide setting
  • you cannot version it with your playbooks/inventory because it is outside of it

I stumbled upon somebody with same needs that proposed a ansible_ssh_proxy_cmd inventory parameter
https://github.com/ansible/ansible/pull/2970

that would solve my problems but I find this solution in either not generic enough or not specific enough.

So that would be nice to have a ansible_ssh_jump_host for instance, like we already have ansible_ssh_user, ansible_ssh_port,
ansible_ssh_host. Why not also add ansible_ssh_known_hosts_file, or ansible_ssh_verify_host_key_dns, or any of the bazillions ssh parameters.
But that would make a lot of parameters in the inventory file which goal seems to be more about listing and grouping hosts.

On the other hand, why not separate the the inventory and the connections parameters. ssh config file is good enough to explain how to connect to a host
(user, real name, identity file to use, proxy command, know_host file to use, etc.) already working with every option you’d happen to need.

But, as I already said, I think that:

  • using ~/.ssh/config is not nice
  • using ansible.cfg or ANSIBLE_SSH_ARGS to relocate ssh config into ansible playbook/inventory repository is also not nice
  • what if we would like to use several ssh config files according to inventory groups ?

Hence, I think ansible_ssh_config is a light and convenient way to

  • integrate ssh config files into the inventory/playbook repository
  • have this repository be self-sufficient and work from any host with a working ansible installation (git clone + point ansible to cloned repository + ansible-playbook my_playbook) as anyone would expect
  • permit to separate inventory and description on how to connect to hosts

I hope that was not too long. I’m ready for the suggestions/critics/flames?/anything.

2

if you use ANSIBLE_SSH_ARGS you loose the “sensible ControlMaster options”.

This is not the case, you can pass in whatever arguments you wish to pass in, including ControlMaster/ControlPersist.

The user who wanted the ProxyCommand parameter was asking for the same kind of option sprawl that resulted in this command being rejected – because if you want to set individual ProxyCommands, you can specify an SSH config usign ANSIBLE_SSH_ARGS or the configuration file to specify a configuration file that sets this up on a per host basis pretty easily.

There isn’t a reason to add a parameter for every possible SSH configuration parameter in Ansible UNLESS ansible needs to have significant behavior changes when those parameters are used.

As for your arguments that it are “not nice”, I disagree! It’s quite nice and ultimately flexible, and presenting a SSH option for every single flag in OpenSSH quickly results in unmanageable option sprawl.

3

if you use ANSIBLE_SSH_ARGS you loose the “sensible ControlMaster options”.

This is not the case, you can pass in whatever arguments you wish to pass in, including ControlMaster/ControlPersist.

What I understood is that you have to pass them again. Hence it’s not a matter of doing
ANSIBLE_SSH_ARGS=“-F new_ssh_config”
but
ANSIBLE_SSH_ARGS=“-F new_ssh_config -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-ssh-%h-%p-%r”
and this is only good for today ansible version. Maybe this could change one day.

We can reasonably assume that ansible developers chose the optimal options for the best experience using ansible with ssh (robustness, performance, security, etc.).
Each time somebody use ANSIBLE_SSH_ARGS, to change an unrelated behavior (like the place to look for a config file in this case), he has

  • to find parameters used by ansible and put them again in this variable, plus his little variation
  • when upgrading to any new version of ansible, to check whether these parameters evolved to keep in sync.

Hence, IMHO, ANSIBLE_SSH_ARGS is a valuable option for a slight temporary behavior change, not for a production configuration.

The user who wanted the ProxyCommand parameter was asking for the same kind of option sprawl that resulted in this command being rejected – because if you want to set individual ProxyCommands, you can specify an SSH config usign ANSIBLE_SSH_ARGS or the configuration file to specify a configuration file that sets this up on a per host basis pretty easily.

There isn’t a reason to add a parameter for every possible SSH configuration parameter in Ansible UNLESS ansible needs to have significant behavior changes when those parameters are used.

Sorry that was not very clear on my first post. My paragraph about having bazillions of ssh options was exactly to say what you say: you can’t have all of them there. I completely agree on this. And that’s also an argument about having an
ansible_ssh_config that could help you deprecate ansible_ssh_(user|private_key_file|host|port) (except if they are really used to change ansible behavior, but I’m not familiar with the code yet)

As for your arguments that it are “not nice”, I disagree! It’s quite nice and ultimately flexible,

What I would like is this scenario:

4

“and this is only good for today ansible version. Maybe this could change one day.”

These are options to OpenSSH, not Ansible, so if Ansible chooses to change OpenSSH defaults it won’t really affect your personal choices.

“We can reasonably assume that ansible developers chose the optimal options for the best experience using ansible with ssh”

You’re speaking to the primary author of Ansible here. They are reasonable defaults.

“My paragraph about having bazillions of ssh options was exactly to say what you say: you can’t have all of them there.”

You can specify -f to specify a configuration file if you have too many options and want to load them from a different configuration file.

“What I would avoid is … it’s not working”.

Sounds like you need to set up a Wiki.

5

“and this is only good for today ansible version. Maybe this could change one day.”

These are options to OpenSSH, not Ansible, so if Ansible chooses to change OpenSSH defaults it won’t really affect your personal choices.

What if my personal choice is: “whatever ansible developers (i.e. you) find optimal + my deviation” ?

“We can reasonably assume that ansible developers chose the optimal options for the best experience using ansible with ssh”

You’re speaking to the primary author of Ansible here. They are reasonable defaults.

That’s exactly why I don’t want to mess with them. You make my point.

“What I would avoid is … it’s not working”.

Sounds like you need to set up a Wiki.

You also make my point here. Your proposed solution force me to make non-standard hacks that need to be documented while my proposed modification would enable to fulfill those needs in a standard and clean way.

Also you did not answer to all my arguments.

Maybe my proposed solution is not the best one. Maybe there are better ways to do it. I don’t want to force this pull request in. Maybe somebody (including you) will come with another better proposal. I only really feel I’m asking for a hammer and you keep telling me you already provide a screwdriver and that should be sufficient to drive a nail. Did I behave incorrectly ?

6

I don’t feel you are asking for a hammer per se, but rather a minor tweak to add an extra option for your specific use case because you didn’t like how something worked.

I’ve already given you an answer that we are not going to add the option.

Generally speaking, if I reject a pull request, appealing to the mailing list will not get it to go further.

Controlling option sprawl is important and there are numerous solutions to this question already provided.

7

Fine then, thanks for your time.

Best regards,
Phil.

8

Sorry to resurrect an old post.

I’m trying to get ansible/vagrant integration working.

Vagrant uses a generated inventory file to communicate with Ansible.

But it is not setting Ansible to perform agent forwarding.

9

“But it is not setting Ansible to perform agent forwarding.”

I’m glad it’s not, that would be a very bad default.

SSH options are configurable via ansible.cfg.

http://docs.ansible.com/intro_configuration.html#ssh-args