SSH + RC4 Cipher：到底有什麼風險？
我有一種情況，一台緩慢的 Windows 機器需要通過 SSH 定期自動連接到另一台機器。SSH 在這台慢速機器上的性能非常糟糕，實際上已經成為一個問題。我已經建議用更快的機器更換有問題的機器，但已被擊落。
我正在考慮在慢速機器上嘗試使用 SSH 的 arcfour -aka RC4 -cipher。我讀過它比 AES 或河豚更不安全但更快。那麼究竟有什麼風險呢？我的理解是 SSH 提供了 3 種安全性：
- 通過 SSH 通信的數據的隱私性
- 向伺服器保證客戶就是他/她聲稱的那個人。即，有效的使用者名 + 密碼/SSH 密鑰組合。
- 通過伺服器 /etc 目錄中的鍵向客戶端保證伺服器機器就是它聲稱的身份。
對於我的具體情況，我們可以忍受 #1 的安全性很低，#2 令人不安，但不會破壞交易。對於這個特別慢的機器，#3 也是可以接受的。但我擔心#3 會以某種方式影響其他客戶。
在伺服器上連接的帳戶是無特權的，並且已經很好地鎖定了，因此任何以該使用者身份連接的人都不應該做一些明顯的事情，比如更改伺服器上的關鍵文件。但是，如果攻擊者可以破解使用較弱的 RC4 會話進行的交易，他/她是否可以做一些事情，比如獲得對伺服器密鑰的某種洞察力？使用較弱的密碼會在上述三個方面中的哪個方面面臨風險？
PS：SSH 的連接共享功能可能是最好的答案，但不幸的是，Windows 似乎不支持。此外，使用河豚密碼而不是 AES 確實提供了一些改進，但它仍然很糟糕。
SSH 將根據所用公鑰的簽名（簡單的雜湊）驗證伺服器。由使用者確保簽名有效（即您通常需要一個安全通道，實際上，客戶端通常只記住伺服器發送的第一個簽名，並在簽名更改時簡單地警告您）。
這意味著驗證伺服器（正確或錯誤）不會受到您選擇的對稱加密算法的影響。
話雖如此，我可以或多或少地向您保證，將對稱加密從 AES 更改為 RC4 不會產生任何明顯的性能改進：即使使用非常慢（或飢餓）的處理器，兩者之間的速度差異也是不會引人注目。
如果您需要更多資訊，實際上有人對 AES 與 RC4 的性能進行了詳細分析（包括 AES 的幾種操作模式）