私は家にサーバーがあり、動的DNSを使用しており、10年以上何の問題もなく使用しています。外部からsshを使用してログインするのに問題はありませんが、ルータを頻繁に使用しないため、数ヶ月前にルータのポートを無効にしました。
これが私の問題です。 SSHと192.168.1.xxxを使用して内部ネットワークのルーターの背後にログインできますが、私のサーバーのドメイン名を使用してログインしようとすると、外部IP経由でログインしようとすると、次のメッセージが表示されます。 36.xxx .xx.xx ポート 22 とのネゴシエーション: その見積もりに一致するキー交換方法が見つかりません: diffie-hellman-group1-sha"。
実際には、ルータでポートが無効になっているため、タイムアウトエラーが発生したことを示す必要があります。
これを確認するために、Ubuntuを使用して外部からログインしようとした後、「ssh：ホストxxxx.comポート22に接続中：接続タイムアウト」が正しく表示されました。 Macを使用して内部から外部IPに接続すると、すべてを取得できます。パスワードプロンプトに移動しましたが、入力すると拒否されたと表示されますか？
内部で Debian を使用して外部 IP に接続すると、中間者攻撃の可能性について警告します。
外部 IP を使用してルータの背後でログインしようとした後にログインを拒否しましたが、外部で期待どおりにタイムアウトエラーが発生した場合、ブロックされたポート 22 をリッスンして接続を提供するのはなぜですか?ルータが破損していますか？
ベストアンサー1
要約すると、ネットワーク内で接続するときに3つの異なる動作を観察できます。
- マシンAはクライアントとサーバーが一致するプロトコルオプションをサポートしていないため、SSH接続を確立することもできません。
- マシン D では、クライアントはホスト鍵の不一致により接続を拒否します。
- システムMでSSH接続が確立されましたが、ユーザー認証に失敗しました。
これらすべては、あなたが到達できると思ったホストに到達できないことを示します。一部の人がすでにコメントで述べたように、ネットワーク内で外部IPアドレスにアクセスした場合は、実際にルータにアクセスすることです。 （より正確に言えば、あなたはあなたのNATデバイス- 家庭や小規模オフィスネットワークの場合は、ルーティング、NAT、およびモデムを実行するためのボックスです。 ）また：
- Aで接続を確立できないという事実は、アクセス中のサーバーが利用可能なオプションの一部のみをサポートし（ルーターで通常発生する）、しばらく更新されなかったことを示します。ルータでは一般的です））—
diffie-hellman-group1-sha1廃止。 - Dホストキーの不一致が検出されたという事実は、そのホストが探しているホストではないことを明確に示しています。
- M 接続は廃止予定のプロトコルをサポートし、そのクライアントが必要なサーバーに接続しないため、矛盾が表示されないため、問題はありません。
known_hosts（）ファイルから適切な公開鍵を削除する必要がありますssh-keygen -R 36.xxx.xx.xx。それ以外の場合は、必要なサーバーに接続しようとするとエラーメッセージが表示されます。
ネットワーク内部から外部IPアドレスに接続しようとしたときに発生する状況は、NATデバイスの設定方法によって異なります。通常、IPアドレスの1つへの接続要求を確認し、それを自分の接続として扱います。これは NAT の設定方法によって異なり、通常はインターフェイスによって設定されるため、外部からの着信接続要求は着信リダイレクト規則に従って変換されますが、内部から着信接続要求は実際に発信された場合にのみ変換されます。 NATデバイスに到着したら変換を行います。
ホームルーターではSSHインターフェースを提供するのが一般的で、これを無効にする特別な理由はありません。廃止予定のプロトコルでも心配する必要はありません。これに対する攻撃は「理論上」に過ぎず、避けるのが最善ですが、すぐに中断されることはありません。事実は、ソフトウェアが古すぎるということです。はいただし、問題は、パッチされていない他のセキュリティホールがある可能性があることです。ルータがTCP以上のプロトコルレベルで外部インターフェイスの何も受信しないことを確認してください。つまり、NATを実行しますが、SSH、Webインターフェイスなどが内部IPアドレスに制限されていることを確認してください。 WiFiがある場合、または物理ネットワークを信頼できない場合は、内部接続も強化してください。