☰

ssh 无法协商 - 未找到匹配的密钥交换方法

tag-icon • tag-icon ssh
ssh 无法协商 - 未找到匹配的密钥交换方法

我正在尝试登录我的 DSL 路由器，因为我在使用命令行邮件时遇到问题。我希望能够重新配置路由器。

当我发出ssh命令时，会发生以下情况：

$ ssh [email protected]

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

然后我看了看这个堆栈交换帖子，并将我的命令修改为此，但我遇到了一个不同的问题，这次是与密码有关。

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

所以有一个命令提供 3des-cbc加密？我不确定 3des，比如我是否想将其永久添加到我的系统中。

有允许密码的命令吗3des-cbc？

这里有什么问题？它不要求输入密码。

答案1

在设置加密通道时会发生此特定错误。如果您的系统和远程系统不共享至少一种密码，则无法达成一致的密码，并且不可能存在加密通道。通常 SSH 服务器会提供少量不同的密码，以满足不同的客户端需求；我不确定为什么您的服务器被配置为仅允许 3DES-CBC。

现在，3DES-CBC 并不可怕。它很慢，但它提供了安全性较低与其他一些算法相比，但只要正确选择密钥，它就不会立即被破解。CBC本身也存在一些问题当密文可以在传输过程中修改时，但我强烈怀疑由此产生的损坏会被 SSH 的 HMAC 拒绝，从而减少影响。总而言之，有比 3DES-CBC 更糟糕的选择，也有更好的选择。然而，在覆盖与安全相关的默认值（包括密码和密钥交换算法选择）时，请务必谨慎行事。这些默认设置是有原因的；一些非常聪明的人花了一些脑力来考虑这些选项，并确定选择作为默认值的选项可以提供最佳的整体安全性与性能权衡。

正如您所发现的，您可以使用-c ...(或-oCiphers=...) 来指定从客户端提供哪个密码。在这种情况下，添加-c 3des-cbc仅允许来自客户端的 3DES-CBC。由于这与服务器提供的密码相匹配，因此可以建立加密通道并且连接进入身份验证阶段。

您也可以将其添加到您的个人~/.ssh/config.为了避免进行全局更改来解决局部问题，您可以将其放在一个Host节中。例如，如果您的 SSH 配置当前显示（虚拟示例）：

Port 9922

通过指定全局默认端口 9922 而不是默认的 22，您可以为需要特殊配置的主机添加一个主机节，并为默认情况添加一个全局主机节。那会变成类似...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

缩进是可选的，但我发现它极大地增强了可读性。空白行和以 开头的行将#被忽略。

如果您始终（或大部分）以该系统上的同一用户身份登录，则还可以指定该用户名：

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

如果 ~/.ssh/config 中没有任何内容，则不需要添加Host *节，因为在这种情况下，只有编译或系统范围的默认值（通常来自 /etc/ssh/ssh_config）用过的。

此时，连接到该主机的 ssh 命令行就简化为简单的

$ ssh 10.255.252.1

系统上的所有其他用户以及系统到所有其他主机的连接都不会受到更改的影响。

答案2

好吧，我阅读了联机帮助页并弄清楚了。

我不想修改我的配置文件，所以我在手册页中搜索了术语“cipher”，它向我显示了该-c选项；这允许我指定加密类型。结束命令是：

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]

答案3

我在设置新的 SFTP 服务器（在 Ubuntu 22 上）时遇到了这个问题。告诉所有客户更新他们的密钥和密码不是一个选择（欢迎来到战壕）。

我添加KexAlgorithms +diffie-hellman-group1-sha1到文件的底部/etc/ssh/sshd_config- 但是前Match group sftp配置的一部分 - 否则我会收到以下错误：

Jun 22 09:43:22 sftp02 sshd[88559]: /etc/ssh/sshd_config line 140: Directive 'KexAlgorithms' is not allowed within a Match block

之后，我仍然需要更新密码：

Jun 22 09:44:45 sftp02 sshd[88613]: Unable to negotiate with 10.10.1.154 port 46973: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]

解决方案：将其添加到 sshd_config 中：

HostkeyAlgorithms +ssh-rsa,ssh-dss

之后不要忘记重新启动 ssh 服务。就我而言：

systemctl restart sshd.service

答案4

许多年后，到 2022 年，我所有 sshd 服务器的日志中每天都会有数百条这样的信息：

Jan  9 00:00:46 server sshd[335552]: Unable to negotiate with x.x.x.x port 53994: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

我只是告诉人们：需要这些 SHA1 密码的客户端永远不是合法用户。

https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html

那些基于 sha1 的密码不再包含在普通、安全、现代的 ssh 服务器中。不要添加那些密码，忘掉它吧，99% 肯定所有这些日志消息都来自试图使用旧 sha1 密码查找易受攻击的 SSH 服务器的机器人。

如果您有需要这些旧密码的合法客户端，则必须升级客户端，而不是通过添加旧的不安全、不受支持的 sha1 密码来降级服务器。

当然，如果您需要连接到需要这些的非常旧的设备，那么是有原因的，但我希望人们会阅读此警告:) 如果您知道原因，那么在 ssh 客户端中添加这些旧密码是可以的。但在 2022 年在 ssh 服务器上添加这些是无意义的:)

这只是对 ssh 服务器管理员在谷歌搜索此错误消息 ssh 无法协商 - 未找到匹配的密钥交换方法时发现此线程的警告。

相关内容