Hello,

first of all, thank you for your work on ncclient. We use it extensively for communication with devices and automated testing, and it serves us well.

We are reaching out with a proposal to optionally integrate an alternative SSH transport layer into ncclient.

Motivation

We are using ncclient also in resource-constrained environments - specifically on MIPS architecture, where available RAM, CPU, and flash memory are limited.

Currently, the default transport relies on Paramiko, which in turn depends on the cryptography package (source). This introduces several key issues in our use case:

• cryptography includes Rust code, which is not well-supported or optimized for MIPS. According to the Rust platform support list (link), MIPS architectures are classified as Tier 3, meaning they are only unofficially supported and may require community effort to maintain.
• It significantly increases the size of our firmware - by about 20%, which is critical in our context, as our systems rely on narrow data channels and very limited storage.

To solve this, we have implemented a custom SSH transport using ssh-python, which is a binding to the C-based libssh library. This alternative has a much smaller footprint and compiles cleanly using a C toolchain, even for MIPS.

Proposal

We propose contributing this alternative transport to ncclient, with the following integration plan:

• The public API (connect() and connect_ssh() methods) would remain unchanged where feasible, depending on the capabilities and compatibility of ssh-python with the existing interface.
• The SSH backend would be selected based on availability in the runtime environment.
• Paramiko would remain the preferred and default option. The ssh-python based transport could be used as a fallback or via an explicit parameter.

Would the maintainers be open to such a contribution? Looking forward to your thoughts!