SSH 为密码、MAC 和 KexAlgorithms 配置选项提供了多种算法。有时我需要快速和轻便（我自己的内部网络），有时我需要我能得到的所有保护（从 DEFCON 获得 VPN'ing home）。
对于上述每个类别，是否有最慢/最快和最/最不安全的分类法（考虑到降低复杂性或增加碰撞可能性等的已知攻击）？
我已经阅读了对称、非对称、哈希、消息验证码密码的现实和最安全的加密是什么？，但我希望看到更多关于每个应用程序的不同建议的讨论（强大的服务器到服务器 vs 电池寿命短且 CPU 较弱的移动设备），以及不同操作模式的其他副作用（CBC vs CTR vs ECB ) 让我们说交互式使用，vs 文件传输。
补充：刚刚发现了不同加密算法/模式的有效传输速度的总结。
对上述问题的另一种回应是，如果您担心安全性，那么专注于算法在很大程度上是无关紧要的，因为您将通过 SSH 服务器中的实现错误来获得 0wned，而不是通过任何人攻击加密货币。特别是如果你正在从 DEFCON 做一些类似于 VPN'ing home 的事情，那么你需要防御 metasploit，而不是 DES-cracker。您可以使用 SSH 通常支持的最弱算法，单个 DES，并且非常安全，因为您将获得 OpenSSH 中的 0day，或者，如果您没有运行最新版本，那就简单了。所以你真的问错了问题，几乎任何算法都会保证你的安全，这是他们会抓住你的实现错误。
您选择的密码不太可能对 SSH 的性能产生影响。在大多数情况下，您的 CPU 可以比您的网络跟上的速度更快地进行加密/解密。在大多数情况下，网络带宽似乎是限制因素。
因此，我建议您将 SSH 保留为默认值。他们很好。默认值是相当安全的，使用默认值进行调整不太可能提供明显更好的性能。
如果你真的想玩弄参数，你可以查看 SSH 的压缩使用。默认情况下，所有数据在通过加密通道发送之前都会被压缩。您可以调整压缩级别ssh -o 'CompressionLevel 6'（将 6 替换为 1-9 之间的任意数字，1 最快，9 最慢）。但是，就我个人而言，我没有发现改变压缩级别有显着的收益。此外，如果您要传输已使用 scp 压缩的文件，您可以使用scp -o 'Compression no' .... 在某些情况下（您的网络非常快而 CPU 速度较慢），这可能会有所帮助，但根据我的经验，我还没有发现它有足够大的差异值得担心。
在我的 OpenSSH 客户端支持的密码中，以下所有密码都应该提供强大的安全性：
aes128-ctr,aes192-ctr,aes256-ctr
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc
您不应该使用des，因为它提供的安全性较弱（3des很好）。我不确定arcfour128、arcfour256和arcfour，因为我没有跟上这方面的文献，但它们对我来说似乎比其他的风险更大。在我的 OpenSSH 客户端支持的消息验证码 (MAC) 算法中，以下所有算法都应该提供强大的安全性：
hmac-md5,hmac-sha1,umac-64@openssh.com,
hmac-ripemd160,hmac-sha1-96,hmac-md5-96
在我的 OpenSSH 客户端支持的 HostKeyAlgorithms 中，所有支持的选项 ( ssh-rsa, ssh-dss) 都很好，并且应该提供强大的安全性，只要您选择足够长度的密钥。我不熟悉 KexAlgorithms 选项。
简而言之，基本上所有提供的加密选项都应该足够安全，除了不要使用 plaindes并且最好避免使用arcfour-based 密码。