ssh 無法協商:“找不到匹配的密碼”,正在拒絕 cbc
我正在嘗試 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 無法協商 - 找不到匹配的密鑰交換方法
更新:問題已解決
正如電信公司解釋的那樣,問題出在伺服器上:它只建議使用過時的密碼算法。我確信客戶端和伺服器都沒有過時。我已經登錄到伺服器(順便說一下,它是 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 到伺服器。
事實證明,這些
-cbc
算法很容易受到攻擊。因此,最新版本的 OpenSSH 現在將預設拒絕這些算法:目前,如果您需要它們,它們仍然可用,但正如您所發現的,您必須明確啟用它們。最初發現漏洞時(在 2008 年末,將近 10 年前!)為了兼容性,這些算法只是放在優先級列表的末尾,但現在它們在 SSH 中的棄用已經達到了這些算法的階段預設禁用。根據Cryptography.SE 中的這個問題,這個棄用步驟已經在 2014 年發生。
如果可能的話,請考慮這是一個溫和的提醒,以更新您的 SSH 伺服器。(如果它是基於韌體的實現,請查看更新的韌體是否適用於您的硬體。)