ProxyCommand fails on > ansible 3.4.0 using network_cli

[nol...@gmail.com]

Hi,

For connectivity to Cisco XR devices, i need to use one or more jumphosts.

I am using:
ansible_ssh_common_args: -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ProxyCommand="ssh -W %h:%p -q jumphost"

but also tried some other order of the arguments as was suggested in this thread (to no avail):
https://groups.google.com/g/ansible-project/c/ny63wqcGv7Y

vars:

connection: network_cli

ansible_network_os: cisco.iosxr.iosxr
ssh_type: libssh

Running:

ansible          3.4.0
ansible-base     2.10.17
ansible-pylibssh 0.3.0
paramiko         2.10.5

As soon as i switch to ansible version 4.0,0 the ansible_ssh_common_args is not being read/loaded and the task:

- task

    - name: run show version on remote device
      cisco.iosxr.iosxr_command:
        commands: show version

This task fails

    "msg": "ssh connection failed: ssh connect failed: Network is unreachable",

as it tries to connect to the host directly.
The same results are yielded when running ansible 5.0.x and 6.0.x

When I use the default connection: ssh in combination with iosxr_command
    "changed": false,
    "msg": "Connection type ssh is not valid for this module"

So as jumphosts are quite normal to use as it is best practice, there must be a way to get this to work.
I must be missing something, but after reading heaps of sources, i am unable to figure out how to get this to work in current non-EOL ansible.

Thanx in advance.

Regards

[Nico Kadel-Garcia]

On Thu, Jul 28, 2022 at 9:26 AM nol...@gmail.com <nol...@gmail.com> wrote:
>
> Hi,
> For connectivity to Cisco XR devices, i need to use one or more jumphosts.
> I am using:
> ansible_ssh_common_args: -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ProxyCommand="ssh -W %h:%p -q jumphost"
>
> but also tried some other order of the arguments as was suggested in this thread (to no avail):
> https://groups.google.com/g/ansible-project/c/ny63wqcGv7Y
>
> vars:
> connection: network_cli
> ansible_network_os: cisco.iosxr.iosxr
> ssh_type: libssh
>
> Running:
> ansible 3.4.0
> ansible-base 2.10.17
> ansible-pylibssh 0.3.0
> paramiko 2.10.5

Start upstream, yoink those obsolete versions of ansible and
ansible-base, and install ansible-core by itself. Add modules only if
and as needed from the ansible galaxy collection, rather than relying
on the quite large and sometimes fragile suite of more than 100
modules in what I would call the mislabeled "ansible" tarball.

Put the SSH settings to disable the known_hosts file in the
.~/ssh/config file of the staging account and the ansible server's
account, stop trying to force those through complex remote
environments. known_hosts has been a problem since SSH was created,
especially in bulky remote environments where IP addresses may be
re-assigned to hosts with quite distinct SSH host keys.

> As soon as i switch to ansible version 4.0,0 the ansible_ssh_common_args is not being read/loaded and the task:
> - task
> - name: run show version on remote device
> cisco.iosxr.iosxr_command:
> commands: show version

Where are you finding ansible 4.0.0? I'd not expect such an old
ansible to have a contemporary cisco iosxr module, nor rely on a
contemporary version of the module it to be compatible with such an
old ansible-base. It's helpful to remember that the modern "ansible"
package, well, it isn't ansible. It's a bulky collection of ansible
galaxy collection modules, and all the key functional tools are in the
"ansible-core" package, formerly labeled ansible-bae.

See above. Deal with the minimum suite of tools, including a supported
version of ansible-core and the relevant galaxy tools.

> This task fails
> "msg": "ssh connection failed: ssh connect failed: Network is unreachable",
> as it tries to connect to the host directly.
> The same results are yielded when running ansible 5.0.x and 6.0.x

So... those seem to include the cisco.iosxr module Why not install and
review just that module,? I'd yoink the "ansible" package entirely,
and update the ansible-core to the most recent version for debugging.
Debug the Ansible to your nearer hosts to validate your basic SSH
usage, then activate the more complex module as appropriate.

> When I use the default connection: ssh in combination with iosxr_command
> "changed": false,
> "msg": "Connection type ssh is not valid for this module"

> So as jumphosts are quite normal to use as it is best practice, there must be a way to get this to work.
> I must be missing something, but after reading heaps of sources, i am unable to figure out how to get this to work in current non-EOL ansible.

"jumphosts" are an effective tool to solve certain exposure issues.
But there are quite a few distinct ways to run jumphosts, and I'm
afraid your description is missing enough details to provide a lot
more help. I urge you to start from scratch in a clean contemporary
test environment.



> Thanx in advance.
> Regards
>
> --
> 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 ansible-proje...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/45bce891-c282-487b-9e96-391d28aee48fn%40googlegroups.com.

[nol...@gmail.com]

Thanx for the respons..
i appologize for not being clear enough, or given enough of information.

Good point to keep it lean and clean, and besides the ansible package, only the packages that were needed have been installed.

The "old" install was quite clean, i did not realize i could run playbook just on base or core, so now no ansible has been installed.

Just for good measure, i started for this discussion with a fresh playbook (new git clone)  and then just installed packages based on where the playbook fails due to missing modules.
I recloned fresh to get rid of any interference from previous ansible-galaxy installs

All packages are installed in a venv with  "ansible-galaxy collection install" and pip install.

"I'm afraid your description is missing enough details to provide a lot more help"

I'm not sure what details you would be needing, i thought i gave enough information, but i guess the playbook would be a good thing to include.
What details are missing for a proper look? I ommited any AWX information as i am testing on the command line, my assumption is that when it works in its most simple form, we can start moving towards AWX and see what happens.

- name: Test SSH proxy stuff
  hosts: xr-cisco
  connection: network_cli
  gather_facts: False
  vars:
    run_prepare: true
    run_po1: false
    ssh_type: libssh
    ansible_ssh_private_key_file: "{{ playbook_dir}}/some_dude_rsa"
    ansible_user: "xxxx"
    ansible_password: 'xxxxx'
    ansible_network_os: cisco.iosxr.iosxr
    ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -q jumphost"'

  tasks:

    - name: run show version on remote device
      cisco.iosxr.iosxr_command:
        commands: show version

Collections:
ansible.netcommon 3.1.0
ansible.posix 1.4.0
ansible.utils 2.6.1
cisco.iosxr 3.2.0
networktocode.nautobot 4.0.1

Pip:         
ansible-core 2.13.2
ansible-pylibssh 0.4.0
cffi 1.15.1
cryptography 37.0.4
Jinja2 3.1.2
MarkupSafe 2.1.1
packaging 21.3
pip 20.3.4
pkg-resources 0.0.0
pycparser 2.21
pyparsing 3.0.9
PyYAML 6.0
resolvelib 0.8.1

setuptools 44.1.1

"Where are you finding ansible 4.0.0? I'd not expect such an old ansible to have a contemporary cisco iosxr module, nor rely on a contemporary version of the module it to be compatible with such an old ansible-base"

Your question on the old versions they were all installed via pip.
Just for testing i removed the ansible-core and installed the ansible-base  2.10.17 package resulting in output using the iosxr module.
the iosxr module seems to be compatible with ansible-base 2.10.17 and the Cisco XR module works fine without a jumphost (using network_cli), only when i introduce a jumphost with a base/core > 2.10.17 the ansible_ssh_common_args seems not to be used.
For your information, when i use the ssh connection module in combination with the iosxr module, the output on the task is

    "msg": "Connection type ssh is not valid for this module"

I do not want to run 2.10.17 or other ancient base/core versions, it was just at a point where i was looking for some direction to focus on as the problem did not make sense.

So i found 2.10.17 that worked, again i do not want to run this for obvious reasons but it also it breaks my other playbooks.

"Put the SSH settings to disable the known_hosts file in the .~/ssh/config file of the staging account and the ansible server's account, stop trying to force those through complex remote environments"

Do you consider my setup to be connecting to be "complex.

I would consider a jumphost between ansible and the target far from complex, and the args is an example i see all over the place.

ansible_ssh_common_args: -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ProxyCommand="ssh -W %h:%p -q jumphost"

The reason i am using the ansible_ssh_common_args: variables, is that the playbook needs to be executed via AWX (installed on k8) and i was not able  to load a custom config file, where the custom config file is in the ansible_dir
ansible_ssh_common_args: '-F ssh-config'

My main focus is to get the jumphost used, once that was working on 2.10.17 meant that the variable string used by connection modules (ssh AND network_cli) was correct.
And based on web pages with people struggling with the same issue, i did not find that the string changed on later versions.

Your point in the known hosts issue is not really relevant for our environment, if it were, the playbook would given output regarding that, besides our environment is quite static.

"Deal with the minimum suite of tools, including a supported version of ansible-core and the relevant galaxy tool"

..minimum  Done :)  with "supported" you would mean current ansible version and a relevant galaxy tool would be the latest galaxy collection versions?

So... the core question:
Something is preventing me to load the ansible_ssh_common_args var when running on higher versions of ansible-base/ansible-core.

Thanx

Op zondag 31 juli 2022 om 19:44:51 UTC+2 schreef nka...@gmail.com: