ansible_ssh_private_key and IdentitiesOnly

Archives Ansible Project
1

With ansible, one can define ansible_ssh_private_key=/some/key per-host, to define which private key will be sent along for which hosts. This is pretty useful, but I think it’s missing the next bit of usefulness, using that private key /exclusively/. As it stands, when you define ansible_ssh_private_key, the Ansible code will add -o IdentityFile=/some/key to the SSH arguments. This directs SSH to /include/ this key along with the rest of the keys it may get from ssh-agent when attempting to make the connection. In order to use the defined key exclusively, an extra option needs to be passed along, -o IdentitiesOnly=yes . This will direct SSH to /only/ attempt using the provided private key.

This functionality would be useful in key rotation, making sure the new key works before removing any old keys from authorized_keys. It also has security impact, making sure the remote side is responding to the specific key we’re providing, indicating it has the public part of this particular key and not some other key that’s letting ssh in.

The code to add this doesn’t look too bad, albeit spread across a few connection plugins and one module. I’m willing to put the work in if this is seen as as a useful and acceptable change in behavior. Note that at this time I’m not asking for an additional Ansible config entry or argument to toggle this feature, what I”m asking for is a behavior change to go along with the already existing config of ansible_ssh_private_key.

-jlk

2

I see your logic, but I think this world break a use case I have in my environment where a bot layers on the appropriate key depending on what it is doing.

There is the config key for initiating a config run, the provisioning key for each environment, the deploy key for each environment, and the security group key for each region.

Config key is always in the agent, but the others are loaded as needed.

The examples you mentioned seem more like something I would be doing occasionally, or one off. For that situation, it would be just as easy to drop keys from my agent to test a new key is working before removing the old.

3

ansible_ssh_args is leveragable here to pass additional arguments correct?

Also this is configurable in ansible.cfg.

4

ansible_ssh_args does not appear to be a config value used by Ansible.

[ssh_connection]

ssh_args

that is read, and looking at the source, it appears the environment ANSIBLE_SSH_ARGS is read by the ssh connection plugin.

I’ll try to play around and see if I can get that manipulated /in the middle/ of a playbook, but it looks fairly awkward to accomplish. This is a setting we’d want to set after the initial few connections.

-jlk

5

Per IRC, I’m open to that being a thing.

6

If there is value in this change of behavior, then cool. I have some other work-arounds in mind that shouldn’t be a big deal.