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

Question

我正在尝试通过 ssh 连接到远程机器，尝试失败：

$ ssh -vvv admin@192.168.100.14
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: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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
rijndael-cbc@lysator.liu.se
aes128-ctr
... and there are several more.

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

ssh -vvv -c aes256-cbc admin@192.168.100.14

我可以成功登录到服务器。

我的~/.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 连接到服务器。

Answer 1

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

最初当漏洞被发现时（2008 年底，将近 10 年前！）为了兼容性，这些算法只是放在优先级列表的末尾，但现在它们在 SSH 中的弃用已经到了一个阶段，这些算法是默认禁用。根据Cryptography.SE 中的这个问题，这个弃用步骤已经在 2014 年发生了。

如果可能，请将此视为一个温和的提醒，以更新您的 SSH 服务器。（如果它是基于固件的实现，请查看更新的固件是否适用于您的硬件。）

Answer 2

您可以从位于以下位置的文件更新 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 保存并退出。

Answer 3

在 ~/.ssh/config 中创建一个文件并粘贴下面的内容

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc

Answer 4

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

\n\n

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

\n

Answer 5

只需-c使用支持的密码之一（aes128-cbc、3des-cbc、aes192-cbc、aes256-cbc）添加参数：

ssh -c aes256-cbc admin@192.168.100.14