☰

SSHは交渉できません。一致する鍵交換方法が見つかりません。

tag-icon • tag-icon ssh
SSHは交渉できません。一致する鍵交換方法が見つかりません。

コマンドラインメールの使用に問題があるため、DSLルーターにログインしようとしています。ルーターを再構成したい。

sshコマンドを実行すると、次のことが発生します。

$ ssh [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

それから見てこのスタック交換ポスト、これを行うようにコマンドを修正しましたが、今回はパスワードに関して他の問題が発生しました。

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

だからコツがあります。供給 3des-cbc暗号化？私は3desを私のシステムに永久に追加したいかどうかわかりません。

パスワードを許可するコマンドはありますか3des-cbc？

ここで問題は何ですか？パスワードを求められません。

答え1

この特定のエラーは、暗号化されたチャネルを設定したときに発生します。システムとリモートシステムが1つ以上のパスワードを共有していない場合、合意されたパスワードに同意できず、暗号化されたチャネルが存在できません。通常、SSH サーバーは、さまざまなクライアントのニーズに合わせていくつかの異なるパスワードを提供します。サーバーが3DES-CBCのみを許可するように構成されている理由は不明です。

今、3DES-CBCはひどいものではありません。遅いですが提供しています。安全性が低い他のアルゴリズムと比較すると、キーを正しく選択するとすぐにクラックしません。CBC自体にもいくつかの問題があります。暗号文は転送中に変更される可能性がありますが、それによって引き起こされる破損はSSHのHMACによって拒否され、影響が軽減されると強く疑っています。全体として、3DES-CBCよりも悪いオプションもあり、より良いオプションもあります。しかし、パスワードや鍵交換アルゴリズムの選択など、セキュリティ関連のデフォルト値を上書きするときは注意してください。これらのデフォルト値には理由があります。いくつかの非常にスマートな人々は、これらのオプションについて考え、デフォルトとして選択されたオプションは、最高の全体的なセキュリティとパフォーマンスのバランスを提供すると判断しました。

見つけたように-c ...（または-oCiphers=...）を使用して、クライアントが提供するパスワードを指定できます。この場合は、クライアントが-c 3des-cbc3DES-CBCのみを許可するように追加してください。これはサーバーによって提供されたパスワードと一致するため、暗号化されたチャネルが確立され、接続が認証フェーズに入ります。

~/.ssh/configローカルの問題を解決するためにグローバルな変更をしたくない場合は、セクションに追加することもHostできます。たとえば、SSH設定が現在表示されている場合（ダミーの例）：

Port 9922

デフォルト値22の代わりにグローバルデフォルトポート9922を指定すると、特別な設定が必要なホストのホストセクションと、デフォルトのケースのグローバルホストセクションを追加できます。それは次のように変わります...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

インデントはオプションですが、読みやすさが大幅に向上します。空行とで始まる行は#無視されます。

このシステムで常に（またはほとんど）同じユーザーとしてログインしている場合は、そのユーザー名を指定することもできます。

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

~/.ssh/config に何もない場合は、Host *スタンザを追加する必要はありません。これは、コンパイルまたはシステム全体のデフォルト値（通常は/etc/ssh/ssh_config）のみが使用されるためです。

この時点で、ホストに接続するためのSSHコマンドラインは単純なコマンドラインに縮小されます。

$ ssh 10.255.252.1

システムの他のすべてのユーザーと他のすべてのホストへのシステム接続は、変更の影響を受けません。

答え2

さて、マンページを読んで調べました。

設定ファイルを変更したくなかったので、マニュアルページで「暗号化」という用語を検索しました。これにより、暗号化の種類を指定する-cオプションが表示されました。終了コマンドは次のとおりです。

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]

答え3

新しいSFTPサーバー（Ubuntu 22）のセットアップ中にこの問題が発生しました。すべての顧客に鍵とパスワードを更新することはオプションではないことを教えてください（参加へようこそ）。

KexAlgorithms +diffie-hellman-group1-sha1ファイルの一番下に追加しましたが/etc/ssh/sshd_config-今後Match group sftp構成の一部 - それ以外の場合は、次のエラーが発生します。

Jun 22 09:43:22 sftp02 sshd[88559]: /etc/ssh/sshd_config line 140: Directive 'KexAlgorithms' is not allowed within a Match block

その後もパスワードを更新する必要があります。

Jun 22 09:44:45 sftp02 sshd[88613]: Unable to negotiate with 10.10.1.154 port 46973: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]

解決策：これをsshd_configに追加します。

HostkeyAlgorithms +ssh-rsa,ssh-dss

後でSSHサービスを再起動することを忘れないでください。私：

systemctl restart sshd.service

答え4

数年後の2022年には、私のすべてのSSHDサーバーのログに毎日このような何百ものメッセージがあります。

Jan  9 00:00:46 server sshd[335552]: Unable to negotiate with x.x.x.x port 53994: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

私は、人々にこれらのSHA1パスワードを要求するクライアントは決して正当なユーザーではないことを言いたいと思います。

https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html

これらのSHA1ベースのパスワードは、正常で安全な最新のSSHサーバーには含まれなくなりました。適切なパスワードを追加しないでください。忘れてください。これらのすべてのログメッセージは、以前のsha1パスワードを使用して脆弱なSSHサーバーを見つけようとするボットからのものであると99％確信しています。

これらの古いパスワードを必要とする正当なクライアントがある場合は、サーバーをダウングレードするのではなく、以前の安全でサポートされていないSHA1パスワードを追加してクライアントをアップグレードする必要があります。

もちろん、これを必要とする非常に古いデバイスに接続する必要がある場合は理由がありますが、人々がこの警告を読んでください。しかし、SSHサーバーにこれを追加することは2022年には意味がありません:)

これは、ssh failed to ネゴシエーション - 一致するキー交換方法が見つかりませんでしたというエラーメッセージを取得したときに、このスレッドを検出したSSHサーバー管理者に送信する警告です。

関連情報