リモートコンピュータに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クライアントはこれらのうちの1つをサポートしていないようですので、サーバーとクライアントはもはやネゴシエートできません。
しかし、私の顧客は提案されたすべてのアルゴリズムをサポートしています。
$ 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
、クライアントもこれを使用できることを理解するのに直接使ってみてはいかがでしょうか。
いくつかの追加の注意:
しばらく前まででも(一ヶ月ほど)そんな問題はありませんでした。それ以来、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経由で接続できます。
答え1
-cbc
これらのアルゴリズムは攻撃に対して脆弱であることがわかりました。その結果、OpenSSH の最新バージョンはデフォルトでこれらのアルゴリズムを拒否します。現在は必要な場合は引き続き使用できますが、見つかったとおりに明示的に有効にする必要があります。
最初に脆弱性が発見されたとき(2008年末、ほぼ10年前!)、これらのアルゴリズムは互換性の理由で優先順位リストの一番下に置かれましたが、SSHでの廃止は削除段階に達しました。デフォルトでは無効になっています。 ~によるとCryptography.SEのこの問題、このサポート停止段階はすでに2014年初めに発生しました。
この通知を親切に考えてください。SSHサーバーの更新、可能であれば。 (ファームウェアベースの実装の場合は、ハードウェアに利用可能な最新のファームウェアがあることを確認してください。)
答え2
内部にファイルを作成します。~/.ssh/configそして、以下を貼り付けてください。
Host 192.168.100.14
SendEnv LANG LC_*
Ciphers +aes256-cbc
答え3
次の場所にあるファイルからSSH構成を更新できます。/etc/ssh/ssh_config
- 端末を起動します。
- 次の行を端末に貼り付けます。
sudo nano /etc/ssh/ssh_config
- パスワードを入力してください。エンターキーを押してください。 SSH 構成ファイルが表示されます。
- 次の行のコメントを外します。
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
- によると
Ctrl + X
。保存して終了するにはEnterを押します。
答え4
私は長い間SynologyサーバーでもOPと同じ問題を抱えていましたが、これはssh -c aes256-cbc diskstation.local
便利な一時的な方法です。しかし、サーバーが古いパスワードを使用していることを知っているのは、本当に安心できません。
本当の解決策はいいえ私が何年もの間素直に知っていたように、Synologyがファームウェアを更新するのを待ちます(または少なくとも更新しないでください)。代わりに、サーバー構成を確認してください。許可されたパスワードは後ろに隠されています。端末とSNMP>高度なパラメータ。オプションを選択すると最新のパスワードが許可され、低セキュリティ以外のオプションを選択すると-cbc
パスワードが無効になります。