目前，在 SSH 中使用MD5 或 CBC 加密或 96 位 MAC 没有已知的弱点。因此，严格意义上讲，在实施您提议的配置修改时没有安全优势。有人可能会争辩说，删除对某些算法的支持可能会导致安全问题，因为它可能会阻止某些客户端连接，从而迫使用户寻找可能不太安全的解决方法（例如，如果scp不再可能，将文件发送到电子邮件...）。

您的设计目标中最不合理的是禁止 CBC。CBC 安全需要对初始化向量进行适当的管理；在 SSH 的情况下，IV 是从前一个数据包的最后一个块中提取的（参见标准），只要攻击者不处于“选择明文攻击”的情况下就可以了。在实践中，进入 SSH 隧道的数据并不是恶意的，这与在 HTTPS 上下文中发生的情况相反，其中恶意客户端代码（在 Javascript 中）是绝对可能的。类似地，对 SSH 的填充 oracle 攻击很难利用（假设客户端或服务器代码没有得到充分保护），因为 SSH 是面向连接的，不会自动（重新）打开失败的连接（同样，与发生的情况相反HTTPS）。

同样，据我们所知，HMAC/MD5 一如既往地坚固。已知的对 MD5 的碰撞攻击对 HMAC 的安全性没有影响，除了最模糊的感觉（可以概括为：“MD5 臭”）。至于将 HMAC 值截断为 96 位，再次没有理由对此进行区分：攻击者将以 2 ^-96的概率成功绕过 96 位 MAC 值，这非常低，并且在实践中不可能被利用，因为任何MAC报告单个 SSH 连接失败并显示一条非常明显的错误消息。这又是使用 SSH 的方式，它可以保护它免受可应用于 HTTPS 的攻击自动化级别。

因此有人可以说，既然从列表中删减算法是为了让你有安全感，那么正确的列表会让你感到最安全。根据定义，这是主观的，因此您是唯一可以定义此“最佳”列表的人。至于我，我对默认设置非常满意。

至于order ，请考虑RFC 4253 的第 7.1 节的摘录：

  encryption_algorithms

     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

所以选择的算法将是客户的首选算法。服务器的优先顺序只是一个美化的评论；它不会影响实际选择的算法。因此，输入的顺序/etc/sshd_config并不重要。

每个真正担心 SSH 安全性的人可能都想阅读此页面：

https://stribika.github.io/2015/01/04/secure-secure-shell.html

它通过 OpenSSH 支持的所有密钥交换、服务器身份验证、密码和 MAC，然后丢弃任何不再被认为是安全的东西，为它消除的一切提供有效的理由。使用此设置，您将坚如磐石！

TL；博士？最高安全性的获胜者是：

密钥交换：（ curve25519-sha256
后备diffie-hellman-group-exchange-sha256：）

服务器身份验证：（ Ed25519 with SHA512
回退RSA with SHA1 4096 Bits：）

密码：（ chacha20-poly1305
后备aes256-ctr：）

MAC：（ hmac-sha2-512-etm
后备hmac-sha2-512：）

回退是您在大多数 SSH 服务器上会发现的，虽然不那么安全，但按照今天的标准仍然足够安全。

我这边只有一条评论：如果您也使用 SSH 来复制数据（scp或rsync）或用于端口转发 X11 或 VNC，性能和延迟并非无关紧要。在这种情况下，aes128-ctr将提供最佳性能（在目前已知安全的密码中），您可以考虑使用hmac-md5-etm@openssh.com，因为即使 MD5 已被破坏，HMAC-MD5 至今还没有，而且 MD5 胜过 SHA- 1 在速度和 SHA-2 甚至到目前为止。要了解算法速度，请参阅该页面：

https://www.cryptopp.com/benchmarks.html

恕我直言，这是一个可以接受的权衡：用一些安全性换取更快的速度。

怎么样chacha20-poly1305？chacha20-poly1305到目前为止，我既没有基准，也不能说它已被证明是安全的。它应该是 RC4（又名 arcfour）的替代品，因此它可能比aes128-ctr软件更快，但现代英特尔 CPU 可以在硬件中计算 AES128，所以如果您的 SSH 实现使用它，您可以期望 AES128 非常快. 仍然 ChaCha 可能会更快，但让我有点担心的是尚未证明的安全性；对其尝试的攻击太少，即使它自 2008 年以来就存在，但直到最近，当发现 NSA 可以实时中断 RC4 SSL/TLS 连接时，ChaCha 才变得流行起来。ChaCha 将修复该问题并替换 TLS 中的 RC4，但这并不能证明其安全性。

不必担心密钥交换或服务器身份验证，它们的速度仅在初始连接和需要更新密钥时起作用（何时发生取决于选择的密码和传输的数据量......每个密码有数据限制，一旦达到，就会交换一个新密钥，因为与现有密钥保持一致会从那时起削弱加密），但更新不会经常发生，所以对于这两个我总是去最高的安全性和完全忽略速度。

并且永远不要将截断的哈希 (-96) 用于 MD5 或 SHA-1。除了为每个数据包节省几个字节（MD5 为 4，SHA-1 为 8）之外，它们并没有给您带来真正的好处。哈希将花费同样长的时间来计算/验证（没有速度优势），而截断只会削弱安全性（没有安全优势）。截断会为 SHA-2 带来回报，因为它们要大得多（每个数据包 32、48、64 字节），考虑到传输数据包的最大大小，这么大的散列没有意义，但对于这些截断不是一种选择。

要删除 cbc 密码，请在 /etc/ssh/sshd_config 中添加或修改“密码”行，如下所示：密码 aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,arcfour

为了删除 HMAC MD5 在 /etc/ssh/sshd_config 中添加或修改 MACs 行，如下所示： MACs hmac-sha1,hmac-ripemd160

重新启动 SSHD 以应用更改： service sshd restart