Kex error connecting to device using ssh-dss on v1.3.0, worked on v1.2.2

[OSIRIS-REx]

SUMMARY

After upgrading ansible-pylibssh from v1.2.2 to v.1.3.0, I am no longer able to connect to a legacy device running OpenSSH_5.0 that only supports host key algo ssh-dss. It worked fine on v1.2.2 and it also works with system SSH (OpenSSH_8.0p1).

Running ansible-playbook to connect to the device errors with the following message:
MSG: ['ssh connection failed: ssh connect failed: kex error : no match for method server host key algo: server [ssh-dss], client [ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521]']

ISSUE TYPE

• Bug Report

PYLIBSSH and LIBSSH VERSION

libssh-devel 0.9.6-14.el8
ansible-pylibssh 1.3.0
ansible.netcommon 8.2.0

ansible [core 2.19.4]
  python version = 3.12.11 (main, Aug 15 2025, 13:38:57) [GCC 8.5.0 20210514 (Red Hat 8.5.0-28)] 
  jinja version = 3.1.6
  pyyaml version = 6.0.3 (with libyaml v0.2.5)

OS / ENVIRONMENT

RHEL 8 -> Alcatel-Lucent Enterprise OmniSwitch device (AOS6)

STEPS TO REPRODUCE

Using ansible-pylibssh v1.3.0, run a playbook which conects to the remote device using host key algo ssh-dss.

- name: Run commands on ALE OmniSwitch AOS6
  hosts: aos6
  connection: ansible.netcommon.network_cli
  gather_facts: false
  tasks:
    - name: "Run show system to gather info about the switch"
      ansible.netcommon.cli_command:
        command: show system

Vars in inventory file:

[aos6:vars]
ansible_connection=ansible.netcommon.network_cli
ansible_network_os=jefvantongerloo.alcatel.aos
ansible_network_cli_ssh_type=libssh
ansible_libssh_hostkeys=ssh-dss

INI entries in ansible.cfg:

[libssh_connection]
hostkeys = ssh-dss

EXPECTED RESULTS

Ansible using pylibssh v1.3.0 should connect to the device without errors, just as when using v.1.2.2 or using the native SSH client.
The best would be if pylibssh honored /etc/ssh/ssh_config which contains the following. This worked fine in v1.2.2:

Host *
  HostKeyAlgorithms +ssh-dss

Pylibssh should also honor the variable ansible_libssh_hostkeys=ssh-dss set in the inventory file, or the INI entry in in ansible.cfg, but this doesn't seem to be the case.

[libssh_connection]
hostkeys = ssh-dss

ACTUAL RESULTS

After upgrading from pylibssh v1.2.2 to v1.3.0, it's no longer possible to connect to the device.

ansible-playbook [core 2.19.4]
  config file = /home/user/ansible_playbooks/aos6/ansible.cfg
  configured module search path = ['/export/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible
  ansible collection location = /export/home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /export/home/user/.local/bin/ansible-playbook
  python version = 3.12.11 (main, Aug 15 2025, 13:38:57) [GCC 8.5.0 20210514 (Red Hat 8.5.0-28)] (/home/user/.local/share/pipx/venvs/ansible/bin/python)
  jinja version = 3.1.6
  pyyaml version = 6.0.3 (with libyaml v0.2.5)
Using /home/user/ansible_playbooks/aos6/ansible.cfg as config file
setting up inventory plugins
Loading collection ansible.builtin from 
host_list declined parsing /home/user/ansible_playbooks/aos6/hosts_aos6 as it did not pass its verify_file() method
script declined parsing /home/user/ansible_playbooks/aos6/hosts_aos6 as it did not pass its verify_file() method
auto declined parsing /home/user/ansible_playbooks/aos6/hosts_aos6 as it did not pass its verify_file() method
Parsed /home/user/ansible_playbooks/aos6/hosts_aos6 inventory source with ini plugin
redirecting (type: cache) ansible.builtin.yaml to community.general.yaml
Loading collection community.general from /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible_collections/community/general
Loading collection ansible.netcommon from /export/home/user/.ansible/collections/ansible_collections/ansible/netcommon
redirecting (type: callback) ansible.builtin.debug to ansible.posix.debug
Loading collection ansible.posix from /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible_collections/ansible/posix
Loading callback plugin ansible.posix.debug of type stdout, v2.0 from /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible_collections/ansible/posix/plugins/callback/debug.py
Skipping callback 'default', as we already have a stdout callback.
Skipping callback 'minimal', as we already have a stdout callback.
Skipping callback 'oneline', as we already have a stdout callback.

PLAYBOOK: test.yml *********************************************************************************************************************
Positional arguments: test.yml
verbosity: 4
connection: ssh
become_method: sudo
tags: ('all',)
inventory: ('/home/user/ansible_playbooks/aos6/hosts_aos6',)
forks: 5
1 plays in test.yml
Username: admin
Password: 

PLAY [Run commands on ALE OmniSwitch AOS6] *********************************************************************************************

TASK [Run show system to gather info about the switch] *********************************************************************************
task path: /home/user/ansible_playbooks/aos6/test.yml:15
Loading collection ansible.utils from /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible_collections/ansible/utils
Loading collection jefvantongerloo.alcatel from /usr/share/ansible/collections/ansible_collections/jefvantongerloo/alcatel
<10.13.4.140> attempting to start connection
<10.13.4.140> using connection plugin ansible.netcommon.network_cli
<10.13.4.140> local domain socket does not exist, starting it
<10.13.4.140> control socket path is /home/user/.ansible/pc/423ee443f4
<10.13.4.140> Loading collection ansible.builtin from 
<10.13.4.140> Loading collection ansible.netcommon from /export/home/user/.ansible/collections/ansible_collections/ansible/netcommon
<10.13.4.140> Loading collection ansible.utils from /home/user/.local/share/pipx/venvs/ansible/lib64/python3.12/site-packages/ansible_collections/ansible/utils
<10.13.4.140> Loading collection jefvantongerloo.alcatel from /usr/share/ansible/collections/ansible_collections/jefvantongerloo/alcatel
<10.13.4.140> local domain socket listeners started successfully
<10.13.4.140> loaded cliconf plugin ansible_collections.jefvantongerloo.alcatel.plugins.cliconf.aos from path /usr/share/ansible/collections/ansible_collections/jefvantongerloo/alcatel/plugins/cliconf/aos.py for network_os jefvantongerloo.alcatel.aos
<10.13.4.140> ssh type is set to libssh
<10.13.4.140> Loading collection ansible.builtin from 
<10.13.4.140> local domain socket path is /home/user/.ansible/pc/423ee443f4
<10.13.4.140> ANSIBLE_NETWORK_IMPORT_MODULES: enabled
<10.13.4.140> ANSIBLE_NETWORK_IMPORT_MODULES: found ansible.netcommon.cli_command at /export/home/user/.ansible/collections/ansible_collections/ansible/netcommon/plugins/modules/cli_command.py
<10.13.4.140> ANSIBLE_NETWORK_IMPORT_MODULES: running ansible.netcommon.cli_command
<10.13.4.140> ANSIBLE_NETWORK_IMPORT_MODULES: _load_params skipped for action plugin in direct execution
<10.13.4.140> ANSIBLE_NETWORK_IMPORT_MODULES: complete
[ERROR]: Task failed: Action failed: ssh connection failed: ssh connect failed: kex error : no match for method server host key algo: server [ssh-dss], client [ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521]
Origin: /home/user/ansible_playbooks/aos6/test.yml:15:7

13
14   tasks:
15     - name: "Run show system to gather info about the switch"
         ^ column 7

fatal: [10.13.4.140]: FAILED! => {
    "changed": false,
    "invocation": {
        "module_args": {
            "answer": null,
            "check_all": false,
            "command": "show system",
            "newline": true,
            "prompt": null,
            "sendonly": false
        }
    }
}

MSG:

ssh connection failed: ssh connect failed: kex error : no match for method server host key algo: server [ssh-dss], client [ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521]

[webknjaz]

Pylibssh should also honor the variable ansible_libssh_hostkeys=ssh-dss set in the inventory file

ansible-pylibssh has zero knowledge of how it's being invoked. It's whatever integrates it into a connection plugin that is responsible for passing this in.

[webknjaz]

@Jakuje is this supposed to work?

[webknjaz]

The best would be if pylibssh honored /etc/ssh/ssh_config

This is a config for OpenSSH, which is its own entirely separate project. I don't believe this is standardized in a reliable way for it to be used by others.

[OSIRIS-REx]

Pylibssh should also honor the variable ansible_libssh_hostkeys=ssh-dss set in the inventory file

ansible-pylibssh has zero knowledge of how it's being invoked. It's whatever integrates it into a connection plugin that is responsible for passing this in.

Oh, okay. I may have misunderstood this completely, as I assumed by setting ansible_network_cli_ssh_type=libssh it would use the libssh connection (via the ansible-pylibssh package), making the ansible_libssh_hostkeys=ssh-dss variable valid. But I see now that's maybe not how it works.

The best would be if pylibssh honored /etc/ssh/ssh_config

This is a config for OpenSSH, which is its own entirely separate project. I don't believe this is standardized in a reliable way for it to be used by others.

Yes, I thought libssh/pylibssh would honor these settings as some of the results I found on Google searches seemed to indicate that, but I completely understand if that's not the case. Perhaps the results I found was using another setup, such as the ansible.netcommon.libssh connection instead of ansible.netcommon.network_cli connection, if that would make a difference?

I did just test removing the HostKeyAlgorithms +ssh-dss from the OpenSSH ssh_config and using ansible-pylibssh v1.2.2 I was still able to connect using ssh-dss, so indeed the ssh_config didn't matter in this case. Simply downgrading to v1.2.2 seems to solve it without requiring any specific configuration.

---

Was there a change in v1.3.0 that dropped support for ssh-dss or other host key algos? I wasn't able to find anything about it in the release notes. If so, is there a proper way to add support for certain host key algos as a variable in the inventory file or playbook, or is that simply not possible at the moment?

[Jakuje]

The support for DSA host keys was removed from the libssh 0.11. The OpenSSH 5.0 is from 2008 [1] (17 years ago!) and we can not support broken algorithms forever.

But, if you are using pylibssh on RHEL8, you have libssh 0.9, which still has support for DSA keys. But the DSA signature algorithms are disabled by the default cryptographic policy [2]. So if you want to enable the DSA host keys, you should be able able to switch the cryptographic policy to legacy to be able to communicate with the legacy systems like this

[1] https://www.openssh.org/txt/release-5.0
[2] https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/rhel9/policies/DEFAULT.pol

[OSIRIS-REx]

@Jakuje, thanks for your comment. It's totally understandable that old legacy algorithms can't be supported forever by default. However, it would be nice if there was a way to easily enable legacy algorithms with a variable/setting similar to the ones I mentioned earlier.

As libssh is bundled with ansible-pylibssh, does it even matter what libssh version is installed on the system? For example, my RHEL8 servers have libssh 0.9.6-14.el8 installed through yum/dnf, but ansible-pylibssh 1.3.0 still use the bundled libssh 0.11.2?

Changing the default cryptographic policy is a bit problematic in my case due to the CIS benchmarks prohibiting setting it to legacy.

[Jakuje]

As libssh is bundled with ansible-pylibssh, does it even matter what libssh version is installed on the system? For example, my RHEL8 servers have libssh 0.9.6-14.el8 installed through yum/dnf, but ansible-pylibssh 1.3.0 still use the bundled libssh 0.11.2?

I think the idea was the pylibssh in RHEL should be using the system libssh, but I do not know how for sure. @webknjaz or anyone from the ansible side, do you know?

Changing the default cryptographic policy is a bit problematic in my case due to the CIS benchmarks prohibiting setting it to legacy.

The libssh shipts its own configuration files that are parsing the OpenSSH configuration file so adding the following code block to the /etc/libssh/libssh_client.config before the existing contet, you should be able to override the cryptographic policy:

Host legacy-hostname
  HostKeyAlgorithms ssh-dss
Host *
# [the rest of the current file]

At least this is the path the RHEL libssh uses. If the libssh would be bundled, it will be built differently and the workaround would likely not work.

[webknjaz]

As libssh is bundled with ansible-pylibssh, does it even matter what libssh version is installed on the system? For example, my RHEL8 servers have libssh 0.9.6-14.el8 installed through yum/dnf, but ansible-pylibssh 1.3.0 still use the bundled libssh 0.11.2?

I think the idea was the pylibssh in RHEL should be using the system libssh, but I do not know how for sure. @webknjaz or anyone from the ansible side, do you know?

@Jakuje if installed from a wheel from PyPI via pip install, it'd be bundled. But if there's an RPM-provided variant, it would likely be linked against the system-global lib.

[OSIRIS-REx]

The libssh shipts its own configuration files that are parsing the OpenSSH configuration file so adding the following code block to the /etc/libssh/libssh_client.config before the existing contet, you should be able to override the cryptographic policy:

Host legacy-hostname
  HostKeyAlgorithms ssh-dss
Host *
# [the rest of the current file]

At least this is the path the RHEL libssh uses. If the libssh would be bundled, it will be built differently and the workaround would likely not work.

Okay, understood. Yeah I can see that it's including it's own crypto-policies configuration file as well as parsing the OpenSSH configuration file. I tested this workaround by overriding the crypto-policy, but since libssh seem to be bundled in my case the workaround unfortunately didn't work.

As libssh is bundled with ansible-pylibssh, does it even matter what libssh version is installed on the system? For example, my RHEL8 servers have libssh 0.9.6-14.el8 installed through yum/dnf, but ansible-pylibssh 1.3.0 still use the bundled libssh 0.11.2?

I think the idea was the pylibssh in RHEL should be using the system libssh, but I do not know how for sure. @webknjaz or anyone from the ansible side, do you know?

@Jakuje if installed from a wheel from PyPI via pip install, it'd be bundled. But if there's an RPM-provided variant, it would likely be linked against the system-global lib.

Ansible is installed using pipx and ansible-pylibssh is injected into the ansible venv with e.g. pipx inject ansible ansible-pylibssh==1.3.0. Uninjecting ansible-pylibssh in order to try using the RPM-installed variant simply fails since Ansible cannot import the required Python library (ansible-pylibssh), since now it doesn't exist in the venv anymore.

I guess we simply have to stick to v1.2.2 until all of our legacy devices has been replaced (work in progress, but it takes time).
It would however be great if a future release made it possible to enable support for legacy algorithms that are disabled by default in a setup like this. I fully support the fact that legacy and insecure algorithms are dropped by default.

[Jakuje]

It would however be great if a future release made it possible to enable support for legacy algorithms that are disabled by default in a setup like this. I fully support the fact that legacy and insecure algorithms are dropped by default.

This is not going to happen. We removed the DSA support few years back already in libssh 0.11.0 and there is no good reason to adding it back:

https://www.libssh.org/2024/08/08/libssh-0-11-0-release/

[OSIRIS-REx]

It would however be great if a future release made it possible to enable support for legacy algorithms that are disabled by default in a setup like this. I fully support the fact that legacy and insecure algorithms are dropped by default.

This is not going to happen. We removed the DSA support few years back already in libssh 0.11.0 and there is no good reason to adding it back:

https://www.libssh.org/2024/08/08/libssh-0-11-0-release/

Alright, I completely understand the decision.

It's now clear to me why ssh-dss doesn't work in v1.3.0 in our case, so we'll continue using v1.2.2 until our legacy equipment is gone.

I don't think there's much more to be said regarding this case from my side, so unless anyone of you have anything to add I believe we can close this one. Big thanks to both of you for your assistance!