SSH Saga

[DanPartelly]

Recent Paramiko has gone to the dark side sometimes and fails with old Cisco devices by default. I do not have any desire whatsoever to bisect this, see when it happened, and in conjunction with what OS settings, and how the spheres - including Pluto - were aligned.

At this stage, it's safer to use ansible-pylibssh by default (if offered by the OS package manager, the binary from pypy is flawed, since it vendors libssh with default settings, and you get no guarantee of consistency with OS settings). That rules out any binary install with pip and netlab install. (Yeah it may still work on your Ubuntu, but do not vount on it :P)

Or, we should start to treat iosv and iosvl2 as second-layer platforms.

[snuffy22]

Well it appears Paramiko has stripped most of its older support (ssh-rsa/sha256) in 5.0 according to their release notes,
Maybe we could just force an older one as our pip requirements?
https://www.paramiko.org/changelog.html

[jbemmel]

We could derive our pip requirements from the Netlab topology, similar to how we load kernel modules.

If the topology uses older Cisco devices, it would trigger a Paramiko version check and possible downgrade

Would require a simple paramiko.version attribute for devices, plus some logic to check that

[ipspace]

Considering that the only (semi) legal way to get IOS images is via CML, and CML includes IOL and IOLL2, and they're well supported by containerlab and netlab, I'd deprecate IOSv and IOSvL2, add the "you need paramiko version less than 5.0, and this is how you install it" to the Cisco IOS SSH caveats (and maybe to device quirks), and move on and have a life.

Any objections?

[DanPartelly]

Im OK with depreciation, as long as we do not remove them totally in the foreseeable future. I still need them sometimes.

[ipspace]

FWIW, when I was testing this stuff, I figured out that users using netlab install ansible aren't impacted (yet) because netmiko 4.7 (which is also installed) forces paramiko down to 4.0.0. Anyhow, added an error (that can be disabled) in #3771.

[DanPartelly]

Yes. That may be so, as long as they use that path. Yet the target distro, Ubuntu, is a way worse offender than other distros regarding packaging policies and crypto. Too opinionated and without a central crypto policy point. They have a penchant for disabling things with compilation flags, not configs. That pretty much leaves you at the whim of packagers.

I'll maintain the Jinja templates for the platform for the foreseeable future (but likely no new features), as I still need it occasionally.

At any rate, I see no reason to keep it as a tier 1 platform, despite it not being impacted everywhere. (I know you were not suggesting this, just thinking out loud on its fate from my perspective)

[ipspace]

Implemented in #3771