SSH + RC4 密码:到底存在什么风险?

SSH + RC4 密码:到底存在什么风险?

我遇到过这种情况:一台运行缓慢的 Windows 计算机需要定期通过 SSH 自动连接到另一台计算机。这台运行缓慢的计算机上的 SSH 性能非常差,实际上已经成为一个问题。我已经建议用速度更快的计算机替换有问题的计算机,但遭到了拒绝。

我正在考虑在慢速机器上尝试使用 arcfour(又名 RC4)密码进行 SSH。我读到过它比 AES 或 blowfish 更不安全,但速度更快。那么究竟有什么风险呢?我的理解是 SSH 在 3 方面提供安全性:

  1. 通过 SSH 传输的数据的隐私性
  2. 确保服务器确认客户端的身份。即有效的用户名 + 密码/SSH 密钥组合。
  3. 通过服务器 /etc 目录中的密钥向客户端保证服务器计算机就是其所声称的那个计算机。

就我的具体情况而言,我们可以接受 #1 的较低安全性,#2 令人不安,但不是大问题。对于这台特别慢的机器,#3 也是可以接受的。但我担心 #3 会受到某种影响其他客户。

服务器上连接的帐户没有特权,并且已被很好地锁定,因此以该用户身份连接的任何人都无法执行某些显而易见的操作,例如更改服务器上的关键文件。但是,如果攻击者能够破解使用较弱的 RC4 会话进行的交易,他/她是否可以执行某些操作,例如深入了解服务器密钥?使用较弱的密码会在上述三个方面中的哪一方面带来风险?

PS:SSH 的连接共享功能可能是最好的答案,但不幸的是,Windows 似乎不支持此功能。此外,使用 blowfish 密码代替 AES 确实带来了一些改进,但仍然很糟糕。

答案1

SSH 将根据所用公钥的签名(简单哈希)来验证服务器。用户需要确保签名有效(即,您通常也需要一个安全通道,实际上,客户端通常只记住服务器发送的第一个签名,如果该签名发生变化,只会提醒您)。

这意味着验证服务器(正确或错误)不会受到您选择的对称加密算法的影响。

话虽如此,我可以或多或少地向你保证,将对称加密从 AES 更改为 RC4 不会带来任何明显的性能改善:即使使用非常慢(或不足)的处理器,两者之间的速度差异也不会很明显。

如果你需要更多的信息,有人实际上做了一个详细分析AES 与 RC4 的性能(包括 AES 的几种操作模式)

答案2

我不是这方面的专家,但(假设问题出在密码上)使用 RC4 对服务器身份验证没有帮助 - RC4 用作对称加密算法,而不是非对称连接设置阶段(IIRC 身份确定阶段)。也许基于 PSK 的方法会是一种更合适的方法,可以避免由于计算开销而导致的性能问题?

相关内容