win11 ssh

使用最新版本的ssh客户端试试

这个是因为windows升级后，为了加强安全性，有些ssh2的密钥类型或算法不再被支持了。

解决方法:

建议通过使用secureCRT、Xshell等软件发起ssh连接来规避。

原理展示（这个是我写着玩的）：

以登录H3C交换机为例：

首先复现问题。

抓包分析，发现服务端（交换机）的Key Exchange Init里的ssh.server_host_key_algorithms刚好只有ssh-rsa和ssh-dsa，跟windows回显的错误提示一样；但客户端（windows 11 PC）报文里的同一字段里有一大堆东西，右键复制--值--大概是这些：

ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521,
。。。。。。
rsa-sha2-512,
rsa-sha2-256

里面并没有ssh-rsa和ssh-dsa，和服务端完全没有交集（rsa-sha2-256不等于ssh-rsa，其他同理）。也就是说服务端支持ssh-rsa和ssh-dsa，但客户端支持的是这个那个那个这个。。。。。。没有哪个选项是双方都支持的，所以会协商失败。

通过其他方法（比如secureCRT）登录设备，display ssh2 algorithm发现Public key algorithms里有rsa和dsa，除此之外还有ecdsa-sha2-nistp256和ecdsa-sha2-nistp384，这两个参数是客户端报文ssh.server_host_key_algorithms里也存在的，理论如果服务端报文里他们其中一个，那么两端就能匹配上，但为啥交换机发送的服务端报文里没有呢？

尝试把我之前生成的本地ecdsa public-key销毁，重新生成一个secp256r1的（后经测试，用256r1和384r1都可以，对应上文的ecdsa-sha2-nistp256和ecdsa-sha2-nistp384，用其他的虽然也能生成，但匹配不上Public key algorithms，影响不了报文交互）。

此时用windows也可以连接设备了。

同时抓到的服务端数据包里多出了个ecdsa-sha2-nistp256，和客户端数据包匹配。