sshがネゴシエートできません-一致するキー交換方法が見つかりません


32

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

sshコマンドを実行すると、次のようになります。

$ ssh enduser@10.255.252.1

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

それで私はこのstackexchange postを見て、コマンドをこれに変更しましたが、今回は暗号で別の問題が発生します。

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 enduser@10.255.252.1

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

暗号化を提供 するコマンドはあり3des-cbcますか?システムに永続的に追加するかどうかなど、3desについてはわかりません。

3des-cbc暗号を許可するコマンドはありますか?

ここで問題は何ですか?パスワードを要求していません。


1
多分それはすでにここで
エドゥアルドBaitello

1
Sshには、使用できるさまざまな暗号化アルゴリズムがあり、クライアントとサーバーの間に共通の暗号化アルゴリズムはありません。を使用ssh -o KexAlgorithms=diffe-hellman-group-sha1 enduser@10.255.252.1して、クライアントに古い安全性の低いアルゴリズムを使用するように強制し、ルーターの最新のファームウェアがあるかどうかを確認してください。
イカロス

1
ssh -vvv ...サーバーが提供するすべてのキー交換と暗号プロトコルを明らかにします。
デビッドフォースター

回答:


47

この特定のエラーは、暗号化されたチャネルのセットアップ中に発生します。システムとリモートシステムが少なくとも1つの暗号を共有していない場合、同意する暗号はなく、暗号化されたチャネルは使用できません。通常、SSHサーバーは、異なるクライアントに対応するために、少数の異なる暗号を提供します。サーバーが3DES-CBCのみを許可するように構成されている理由がわかりません。

現在、3DES-CBCはひどいものではありません。低速であり、他のアルゴリズムよりもセキュリティ低くなりますが、キーが適切に選択されている限り、すぐに壊れることはありません。暗号文を転送中に変更できる場合、CBC自体にいくつかの問題がありますが、結果として生じる破損はSSHのHMACによって拒否され、影響が軽減されると強く考えています。結論として、3DES-CBCよりも悪い選択肢があり、より良い選択肢があります。ただし、暗号や鍵交換アルゴリズムの選択など、セキュリティ関連のデフォルトをオーバーライドするときは常に慎重に検討してください。これらのデフォルトは、理由のためのデフォルトです。かなり賢い人の中には、オプションを検討するためにある程度の頭脳を使って、デフォルトとして選択されたものが全体的なセキュリティとパフォーマンスの最適なトレードオフを提供することを決定しました。

わかったように、-c ...(または-oCiphers=...)を使用して、クライアント側から提供する暗号を指定できます。この場合、追加で-c 3des-cbcはクライアントからの3DES-CBCのみが許可されます。これはサーバーが提供する暗号と一致するため、暗号化されたチャネルを確立でき、接続は認証フェーズに進みます。

これを個人用に追加することもできます~/.ssh/config。グローバルな変更を行ってローカルの問題を解決するのを避けるために、それをHostスタンザに入れることができます。たとえば、SSH configで現在(ダミーの例)と表示されている場合:

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

Host *〜/ .ssh / configに何もない場合はスタンザを追加する必要はありません。その場合、コンパイル済みまたはシステム全体のデフォルト(通常は/ etc / ssh / ssh_configから)のみです中古。

この時点で、このホストに接続するためのsshコマンドラインは単純になります

$ ssh 10.255.252.1

システム上の他のすべてのユーザー、およびシステムから他のすべてのホストへの接続は、変更による影響を受けません。


私の場合、Cipher行を削除しなければなりませんでしたが、それでうまくいきました!ありがとう!
カールスプリング

ssh_configのマニュアルページ(link)によると、暗号の構成ファイルの構文は「Cipher s」です(末尾のsに注意してください)。
MikeV

28

わかりました私はマンページを読み、それを理解しました。

構成ファイルを変更したくなかったので、-cオプションを示したmanページで「暗号」という用語を検索しました。これにより、暗号化タイプを指定できます。終了コマンドは次のとおりです。

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc enduser@10.255.252.1

4
手作業で暗号を選択する場合は注意してください。自分が何をしているのかわからない限り、非常に簡単に弱いものを選択する可能性があります(使いやすさなど)。
-heemayl

同じ@heemayl。3DES-CBCはそれほど悪くはありませんが、少なくとも最近のOpenSSHのバージョンでは、すべての意図と目的が完全に破られている暗号がサポートされています。慎重に踏んでください。
CVn

3

最近、PuTTYを使用してUbuntuの新しいバージョンに接続するこの問題に遭遇しました。PuTTYの以前のバージョンでは暗号が更新されていなかったようです。したがって、PuTTYの最新バージョンをダウンロードすることで問題は解決しました。それは別の解決策かもしれません。


1
多くの場合、ルーターは最新の状態に保たれていないか、メーカーによって十分にサポートされていません。

0

MacOSXおよびCLIコマンド(SFTPなど)に対する別の回答:この記事@ http://www.openssh.com/legacy.html(OpenSSL Legacy Options)を参照してください。この記事の情報、特に「〜/ .ssh / config」ファイルの構成パラメーターの設定によって解決された「ネゴシエートできません」という一貫したエラーが発生していました。

ところで、(管理下にない)宛先のSFTPサーバーが最終的にTLS 1.0(SSL暗号化オプション)をオフにし、TLS 1.1または1.2を必要とするときにこのエラーが発生しました。

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