web-dev-qa-db-ja.com

sshネゴシエートできません：「一致する暗号が見つかりません」、cbcを拒否しています

リモートマシンにSSH接続しようとしていますが、失敗します。

$ ssh -vvv [email protected]
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: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
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
[email protected]
aes128-ctr
... and there are several more.

そして、私がこのようなアルゴリズムを明示的に指定した場合：

ssh -vvv -c aes256-cbc [email protected]

サーバーに正常にログインできます。

私の~/.ssh/configには暗号関連のディレクティブが含まれていません（実際には完全に削除しましたが、問題は残っています）。

では、クライアントとサーバーが、明示的な指示なしに使用する暗号を決定できないのはなぜですか？クライアントは、サーバーがaes256-cbcをサポートしていることを理解し、クライアントは自分で使用できることを理解しています。

追加のメモ：

  • しばらく前（約1ヶ月）にはそのような問題はありませんでした。それ以来、ssh構成ファイルを変更していません。インストール済みのパッケージは更新しましたが。

  • 非常によく似た問題を説明する質問がありますが、私の質問には答えがありません： sshが交渉できません-一致する鍵交換方法が見つかりません

更新：問題は解決しました

TelcoMが説明したように、問題はサーバーにあります。古い暗号アルゴリズムのみを示唆しています。クライアントとサーバーの両方が古くないと確信していました。私はサーバーにログインし（ちなみに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で接続できます。

sshopensshsynology
27
lesnik

-cbcアルゴリズムは攻撃に対して脆弱であることが判明しました。 結果として、OpenSSHの最新バージョンはデフォルトでこれらのアルゴリズムを拒否するようになりました。今のところ、必要な場合は引き続き使用できますが、発見した場合は、明示的に有効にする必要があります。

最初に脆弱性が発見されたとき（2008年後半、10年近く前！）これらのアルゴリズムは、互換性のために優先リストの最後にのみ配置されていましたが、SSHでの非推奨は、これらのアルゴリズムが存在する段階に達していますデフォルトでは無効になっています。 Cryptography.SEのこの質問 によると、この非推奨のステップは2014年にすでに発生しています。

可能であれば、これをSSHサーバーの更新への穏やかなリマインダーと見なしてください。 （ファームウェアベースの実装の場合は、ハードウェアで更新されたファームウェアが利用可能かどうかを確認してください。）

19
telcoM

次の場所にあるファイルからssh構成を更新できます：/ etc/ssh/ssh_config

  1. 端末を起動します。
  2. 端末に行を貼り付けます：Sudo nano /etc/ssh/ssh_config
  3. パスワードを入力してください。 Enterキーを押します。 SSH設定ファイルが表示されます。
  4. 次の行のコメントを外します：Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
  5. 押す Ctrl + X。 Enterキーを押して保存し、終了します。
6
Farhan Ar Rafi

〜/ .ssh/config内にファイルを作成し、コンテンツの下に貼り付けます

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc
2
Yash Jagdale