解决Windows SSH无法连接老旧网络设备（路由器交换机）

1. 背景与痛点

在企业级网络运维中，我们经常面临一个典型的"代沟"问题：

运维终端：运行着最新的Windows 10/11或Linux发行版，内置的OpenSSH客户端版本较新（通常为OpenSSH 8.x/9.x），默认遵循严格的安全标准，禁用了被认为不安全的加密算法。
网络基础设施：现网中运行着大量服役多年的交换机、路由器、防火墙（如老款Cisco Catalyst、Huawei Quidway、H3C Comware v5/v3等）。这些设备的SSH服务端版本较老，仅支持旧式的密钥交换算法（KEX）和加密套件（Ciphers）。

故障现象 ：

当运维工程师尝试通过Windows终端SSH连接这些设备时，往往会遇到如下报错，导致连接直接断开：

Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

或者

no matching host key type found. Their offer: ssh-rsa,ssh-dss

本文将深入解析这一问题的根源，并提供标准化的Windows SSH配置方案，在确保安全可控的前提下实现对老旧设备的兼容。

2. 核心原理分析

SSH协议在建立连接时，会经历一个协商（Negotiation） 过程。客户端和服务端必须就"用什么算法加密数据"和"用什么算法验证身份"达成一致。

随着网络安全技术的发展，许多早期广泛使用的算法（如SHA-1、RSA-1024、3DES、Diffie-Hellman Group 1）已被证实存在弱点，容易受到中间人攻击或暴力破解。因此，现代OpenSSH客户端默认移除了对这些算法的支持。

协商失败示意图

网络设备 (老旧) Windows OpenSSH (新版) 网络设备 (老旧) Windows OpenSSH (新版) 默认配置：禁用 SHA1, DSS, CBC模式仅支持：DH-Group1, 3DES, AES-CBC 连接终止：Unable to negotiate Client Hello (支持算法: curve25519, aes256-gcm...) Server Hello (支持算法: diffie-hellman-group1-sha1...) ❌ 协商失败 (无匹配算法)

要解决此问题，我们不需要降级客户端版本，而是需要显式地告诉Windows SSH客户端：针对特定的老旧设备，允许使用旧算法。

3. 解决方案：配置 `config` 文件

虽然可以通过命令行参数（如 ssh -o KexAlgorithms=...）临时解决，但对于频繁运维的场景，配置SSH Config文件是最高效、最规范的方法。

3.1 配置文件位置

在Windows系统中，OpenSSH的配置文件通常位于当前用户的家目录下：

路径：C:\Users\<您的用户名>\.ssh\config
注意：如果 .ssh 文件夹或 config 文件不存在，请手动创建（注意 config 文件没有后缀名）。

3.2 关键配置参数详解

我们需要在配置文件中通过 Host 字段指定目标设备，并追加以下三类参数：

KexAlgorithms (密钥交换算法) : 用于生成会话密钥。老设备常用 diffie-hellman-group1-sha1。
Ciphers (加密套件) : 用于加密传输数据。老设备常用 aes128-cbc, 3des-cbc。
HostKeyAlgorithms / PubkeyAcceptedKeyTypes (主机密钥算法) : 用于验证服务端身份。老设备常用 ssh-rsa, ssh-dss。

3.3 标准配置模板

建议不要全局开启不安全算法，而是限定在特定的网段或IP范围内。

请将以下内容复制到您的 config 文件中：

ssh 复制代码

# =======================================================
# Legacy Network Devices Compatibility
# 针对老旧网络设备的兼容性配置
# =======================================================

# 匹配特定网段 (例如 192.168.10.x) 或具体IP
Host 192.168.10.* 10.1.1.5 switch-core-01
    # 允许旧的密钥交换算法
    KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
    
    # 允许旧的加密算法 (CBC模式)
    Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
    
    # 允许旧的主机公钥算法 (RSA, DSS)
    HostKeyAlgorithms +ssh-rsa,ssh-dss
    
    # 允许旧的公钥认证类型 (针对OpenSSH 8.8+ 默认禁用ssh-rsa的情况)
    PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss

# 全局默认配置 (保持现代安全标准)
Host *
    # 这里不需要额外配置，默认使用高强度算法

3.4 参数说明

Host : 支持通配符 *。例如 192.168.1.* 可以匹配该网段所有设备。
+ 号的作用 : 这是一个非常重要的语法细节。例如 +ssh-rsa 表示在默认支持的算法列表末尾追加该算法，而不是覆盖默认列表。这保证了如果设备支持新算法，客户端仍会优先使用新算法，只有在协商失败时才回退到旧算法。

4. 常见报错与对应参数速查表

根据您在终端看到的具体报错信息，可以针对性地调整配置：

报错关键词	缺失的算法类型	建议添加的配置参数
`no matching key exchange method found`	Key Exchange	`KexAlgorithms +diffie-hellman-group1-sha1`
`no matching cipher found`	Ciphers	`Ciphers +aes128-cbc,3des-cbc`
`no matching host key type found`	Host Key	`HostKeyAlgorithms +ssh-rsa,ssh-dss`
`userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms`	Public Key	`PubkeyAcceptedKeyTypes +ssh-rsa`

5. 安全建议与最佳实践

作为网络架构师，必须提醒您：启用这些旧算法是基于业务连续性的妥协，而非安全推荐。

最小权限原则 ：切勿在 Host * 全局配置中启用这些算法。这会降低您连接所有服务器（包括公网服务器）的安全性。务必仅对内网受信任的旧设备IP段开启。
隔离管理平面：老旧网络设备应置于独立的带外管理网络（OOB）或特定的管理VLAN中，配合防火墙策略，限制仅允许运维堡垒机或特定IP访问。
设备升级计划：虽然配置客户端可以解决连接问题，但根本的解决之道是升级网络设备的固件（Firmware）以支持 SSHv2、AES-CTR 和 SHA-2。如果硬件不支持升级，应制定长期的设备替换计划。
跳板机/堡垒机：在大型企业环境中，建议部署一台支持旧算法的Linux跳板机（Bastion Host），所有对老旧设备的访问均通过该跳板机中转，从而避免在所有员工终端上降低安全配置。

6. 验证配置

配置保存后，无需重启服务，直接在CMD或PowerShell中测试连接：

powershell 复制代码

# 使用 -v 参数查看详细的协商过程
ssh -v admin@192.168.10.1

在输出日志中，寻找 debug1: kex: algorithm: 和 debug1: kex: host key algorithm: 行，确认是否成功协商到了您配置的旧算法。