chore: allow paramiko 5.0.0 to avoid CVE-2026-44405

[dpinol]

Solves #1742

• Pull request is based on the default branch (3.x at this time)
• Pull request includes tests for any new/updated operations/facts
• Pull request includes documentation for any new/updated operations/facts
• Tests pass (see scripts/dev-test.sh)
• Type checking & code style passes (see scripts/dev-lint.sh)
• Pull request title follows the
  conventional commits format

[wowi42]

The diff is two lines but the impact is a major version bump of paramiko, the core SSH dependency used across connectors/ssh.py, sshuserclient/, scp/, and several api/ modules (including version-specific workarounds like the multi-key retry and the ProxyJump timeout from #971).

CI passing only proves the resolver picked one compatible version, not that 5.x was exercised. How was this tested?

• Did you try this against real servers (not just the test suite)?
• Was the SSH end-to-end suite run with paramiko pinned to ==5.* and types-paramiko==5.*?
• Was the paramiko 5.0 changelog reviewed for removed/renamed APIs we use (Transport.open_channel, SSHClient, SFTPClient, Agent, PKey, HostKeyEntry, SSHConfig)?
• Were the existing workarounds (host key save, paramiko#1390 retry, FakeInvoke shim) re-validated?

A range bump like this should land with a CI matrix entry pinning paramiko to the new major. Without that, users upgrading are the test.

[wowi42]

On the actual CVE impact: CVE-2026-44405 is CVSS 3.4 (Low), AV:A/AC:H. The fix (paramiko a448945) just removes ssh-rsa + SHA-1 from the HASHES map in rsakey.py, forcing rsa-sha2-256/rsa-sha2-512 for RSA signatures.

For pyinfra specifically:

• pyinfra is an SSH client, relies on paramiko's default algorithm negotiation. No code in src/ pins ssh-rsa or SHA-1 for SSH (the SHA-1 usages in api/util.py and facts/files.py are file/template hashing, unrelated to this CVE).
• Modern OpenSSH (>= 8.8, default since Sept 2021) already disables ssh-rsa server-side, so on any current target paramiko already negotiates rsa-sha2-*. The vulnerable code path only triggers when talking to legacy servers that still negotiate ssh-rsa.
• To exploit, an attacker needs adjacent-network MITM position AND a usable SHA-1 collision against an in-flight RSA signature. Hence the Low rating.

Net impact on pyinfra users: near zero in practice unless they're managing legacy SSH servers. This is a hardening fix in paramiko, not a critical vuln for pyinfra. The PR is still worth merging to silence scanners, but the urgency framing in #1742 is overstated and doesn't justify skipping a paramiko-5.x test run.

[dpinol]

Did you try this against real servers (not just the test suite)?

I just executed the tests at https://docs.pyinfra.com/en/latest/contributing.html#tests

Was the SSH end-to-end suite run with paramiko pinned to ==5.* and types-paramiko==5.*?

Yes with paramiko=5.x. types-paramiko 5.x does not yet exist.

Was the paramiko 5.0 changelog reviewed for removed/renamed APIs we use (Transport.open_channel, SSHClient, SFTPClient, Agent, PKey, HostKeyEntry, SSHConfig)?

Changelog reports these breaking changes in 5.0:

• renamed PKey.from_path passphrase argument: not used by pyinfra
• Removed support for verifying/signing with RSA keys using SHA-1 hashing
• Removed support for key exchange using SHA-1
• Raised the minimum modulus size in diffie-hellman-group-exchange-sha256 key exchange from 1024 (the original spec’s minimum) to 204

Were the existing workarounds (host key save, paramiko#1390 retry, FakeInvoke shim) re-validated?

No