☰

ssh 无法协商：“未找到匹配的密码”，正在拒绝 cbc

tag-icon • tag-icon ssh openssh synology
ssh 无法协商：“未找到匹配的密码”，正在拒绝 cbc

我正在尝试 ssh 到远程计算机，尝试失败：

$ ssh -vvv [email protected]
OpenSSH_7.7p1, OpenSSL 1.0.2o  27 Mar 2018
.....
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc:
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
Unable to negotiate with 192.168.100.14 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

据我了解日志的最后一个字符串，服务器建议使用以下 4 种密码算法之一：aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc。看起来我的 ssh 客户端不支持其中任何一个，因此服务器和客户端无法进一步协商。

但我的客户确实支持所有建议的算法：

$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
[email protected]
aes128-ctr
... and there are several more.

如果我明确指定这样的算法：

ssh -vvv -c aes256-cbc [email protected]

我可以成功登录服务器。

我的~/.ssh/config不包含任何与密码相关的指令（实际上我完全删除了它，但问题仍然存在）。

那么，为什么客户端和服务器在没有我的明确指示的情况下无法决定使用哪种密码呢？客户端明白服务器支持aes256-cbc，客户端明白自己可以使用，为什么不直接使用呢？

一些附加说明：

  • 前一段时间（大约一个月）没有出现这样的问题。从那时起我就没有更改过任何 ssh 配置文件。不过我确实更新了已安装的软件包。

  • 有一个问题描述了非常相似的问题，但没有回答我的问题：ssh 无法协商 - 未找到匹配的密钥交换方法

更新：问题已解决

正如 telcoM 所解释的那样，问题出在服务器上：它仅建议使用过时的密码算法。我确信客户端和服务器都没有过时。我已经登录到服务器（顺便说一句，它是 Synology，已更新到最新的可用版本），并检查了/etc/ssh/sshd_config.该文件的第一行（！）是：

Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

这很奇怪（事实上该行位于文件的第一行），我确信我以前从未接触过该文件。不过我已将该行更改为：

Ciphers aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

重新启动服务器（不知道如何重新启动sshd服务），现在问题消失了：我可以像往常一样 ssh 到服务器。

答案1

事实证明，这些-cbc算法很容易受到攻击。因此，最新版本的 OpenSSH 现在将默认拒绝这些算法：目前，如果您需要它们，它们仍然可用，但正如您发现的那样，您必须显式启用它们。

最初，当漏洞被发现时（2008 年末，差不多 10 年前！），这些算法只是出于兼容性考虑而被放置在优先级列表的末尾，但现在它们在 SSH 中的弃用已经达到了这些算法被淘汰的阶段。默认禁用。根据Cryptography.SE 中的这个问题，这个弃用步骤早在 2014 年就已经发生了。

请将此视为善意的提醒更新你的 SSH 服务器，如果可能的话。 （如果是基于固件的实施，请查看更新的固件是否适用于您的硬件。）

答案2

里面创建一个文件〜/ .ssh /配置并粘贴以下内容

Host 192.168.100.14
  SendEnv LANG LC_*
  Ciphers +aes256-cbc

答案3

您可以从位于以下位置的文件更新 ssh 配置：/etc/ssh/ssh_config

  1. 启动终端。
  2. 将行粘贴到终端中：sudo nano /etc/ssh/ssh_config
  3. 输入您的密码。按 Enter 键。将显示 SSH 配置文件。
  4. 取消注释该行：Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
  5. 按Ctrl + X。按 Enter 保存并退出。

答案4

与 OP 相同的问题困扰了我很长时间，在 Synology 服务器上也是如此，这ssh -c aes256-cbc diskstation.local是一个有用的权宜之计。但知道自己的服务器使用过时的密码并不能真正让人放心。

真正的解决办法是不是等待 Synology 更新固件（或者至少不仅如此），正如我多年来天真地知道的那样，而是检查服务器的配置。允许的密码隐藏在后面终端和 SNMP>高级参数。选择任何选项都会允许更现代的密码，除了低安全性之外的任何选项都会使-cbc密码失效。

相关内容