新版openssh客户端默认禁用旧算法，导致连接老旧设备时因密钥交换或主机密钥算法不匹配而失败；需通过显式配置kexalgorithms、ciphers等参数或调整paramiko/netmiko底层设置恢复兼容性。
新版OpenSSH客户端默认禁用旧算法
Python的SSH库（如paramiko或netmiko）底层依赖系统OpenSSH或自身实现的加密协商逻辑。当目标服务器是老旧硬件（如十年前的网络设备、嵌入式Linux系统），其SSH服务通常只支持diffie-hellman-group1-sha1、aes128-cbc、ssh-dss等已被现代OpenSSH弃用的算法。而较新版本的paramiko（≥3.0）或系统级ssh命令（OpenSSH 8.8+）默认不启用这些算法，直接导致协商失败，报错类似no matching key exchange method found或no matching host key type found。
paramiko连接时需显式启用旧算法
paramiko从2.9开始逐步收紧默认策略，3.x版本默认关闭CBC模式和SHA-1类密钥交换。若脚本使用paramiko.SSHClient()直连旧设备，必须手动配置transport层参数：
- 在
connect()后、执行命令前，获取transport对象：client.get_transport() - 调用
set_security_options()并传入允许的算法列表，例如：transport.set_security_options(kex=['diffie-hellman-group1-sha1'], ciphers=['aes128-cbc'], macs=['hmac-sha1']) - 注意：
ssh-dss主机密钥需额外设置host_key_policy为paramiko.WarningPolicy()或自定义策略，否则仍会拒绝
netmiko连接老设备要绕过默认安全限制
netmiko封装了paramiko，但它的设备类型（如'cisco_ios'、'huawei'）预设了较新的加密套件。连接旧设备时常见报错Authentication failed或静默断连，实际是算法协商失败。
- 必须显式覆盖
device_type的默认行为，在连接参数中加入：session_log='debug.log'用于捕获底层协商日志 - 通过
global_delay_factor=2缓解因旧设备响应慢导致的超时误判 - 关键修复：传入
fast_cli=False并设置allow_agent=False, look_for_keys=False，强制走密码认证路径（避免密钥协商失败） - 若仍需密钥登录，需配合
paramiko底层配置，不能仅靠netmiko高层参数
系统ssh命令被调用时的隐式兼容问题
部分Python脚本会用subprocess.run(['ssh', ...])调用系统ssh命令。此时问题不在Python代码本身，而在本地OpenSSH客户端版本。
- 检查
ssh -V输出，若为OpenSSH 8.8+，默认禁用diffie-hellman-group1-sha1等 - 临时解决：在命令中加
-o KexAlgorithms=+diffie-hellman-group1-sha1等参数（注意+号表示“追加”，不是替换） - 长期方案：修改
~/.ssh/config，为特定主机添加段落：Host legacy-device\n KexAlgorithms +diffie-hellman-group1-sha1\n Ciphers +aes128-cbc\n HostKeyAlgorithms +ssh-dss - 风险提示：这些算法已被证实存在理论漏洞，仅限内网离线环境短期使用
真正棘手的是，错误日志往往不直接暴露算法名，而是笼统报Authentication failed或Connection reset by peer——这时必须开-vvv或启用session_log才能看到协商细节。旧硬件的SSH服务日志通常又不可查，所以客户端侧的调试日志是唯一线索。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
