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


23

リモートマシンに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いることを理解し、クライアントは自分でそれを使用できることを理解しています。なぜそれを使用しないのですか?

いくつかの追加のメモ:

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

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接続できます。


1
関連-unix.stackexchange.com/questions/333728/…-無効にする方法に関する情報を表示します。
slm

3
私は同じ問題を抱えていて、Webインターフェイスでこれを簡単に変更できることがわかりました(sshは私にとってはうまくいきませんでした...)が、DSMコントロールパネルの「ターミナル->詳細設定」に移動し、 「ハイ」プロファイル-何らかの理由で、そこで手動選択を有効にしました...それが以前のDSMアップデートで行われたものではなく、私がしたことや忘れたことであることを確信しています!-選択肢は、aes128-ctr、aes128-gcm、aes192 *、aes256 *、dhge-sha256、curve25519-sha256、hmac-sha2-256
Zak

回答:


16

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

脆弱性が発見された当初(約10年前の2008年後半)、これらのアルゴリズムは互換性のために優先順位リストの末尾にのみ配置されていましたが、SSHでの非推奨はこれらのアルゴリズムが存在する段階に達しましたデフォルトでは無効になっています。Cryptography.SEのこの質問によると、この廃止ステップは2014年にすでに行われていました。

可能であれば、これをSSHサーバー更新するための優しいリマインダーと考えてください。(ファームウェアベースの実装の場合は、更新されたファームウェアがハードウェアで利用可能かどうかを確認してください。)


2

/ etc / ssh / ssh_configにあるファイルからssh構成を更新できます。

  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キーを押して保存して終了します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.