PuTTYネットワークエラー：ソフトウェアにより接続が中断されました

奇妙な問題があります：ローカルWindows 7でVMwareでホストされているLinuxサーバーに接続するSSHでPuTTYを使用すると、「PuTTY SSHウィンドウが非アクティブになる」というエラーが頻繁に表示されます。通常、PuTTYを使用してサーバーにログインして何かを実行できますが、ランダムな時間（約1〜2分）後にそのエラーが発生します。そして、時々ログインできず、タイムアウトというエラーが表示されます。"Network error: Software caused connection abort"

VMwareでコードリポジトリサーバーとしてホストされている別のUbuntuデスクトップがあり、SVNの更新/コミットを行うときにタイムアウトエラーが発生することが多いため、VMware Playerに何か問題があると思います。ただし、Windows Vistaでは、VMwareでコードリポジトリとしてホストされているのと同じUbuntuサーバーが非常にうまく機能するため、Windows 7には多少の癖があると思います。Windows XPからWindows Vistaに、そしてWindows 7に移行した後、すべての悪いことが起こるようです。

この問題の原因は何ですか？どのように修正できますか？

補足：

Google検索を行い、以下を含むすべての方法を適用して支援しました。

1. sshdを有効にする TCPKeepAlive
2. SSHDを設定ClientAliveIntervalする900とClientAliveCountMaxし3
3. PuTTY接続設定「キープアライブ間の秒数」をに設定し5ます。

しかし、これらはすべて機能しません！そして、PuTTYでのSSHセッションは、しばらくしてまだ中断しています！

LinuxサーバーファイアウォールとWindows 7クライアントファイアウォールの両方をオフにしましたが、ログインがタイムアウトします。それは本当に迷惑です！

ログインできる場合もありますが、ログインがタイムアウトする場合もあります！理由は本当にわかりません。それは私を夢中にさせます！

私が言及しなければならないことの1つは、リモートサーバーに接続するPuTTY SSHを使用しているとき、それは大丈夫です！

ログインに失敗すると、pingも失敗しました！しかし、それはどのようにして起こるのでしょうか？VMwareプレーヤーを使用して、ローカルマシンでLinuxサーバーをホストしています。

Puttyには、この問題を修正しようとする機能があります。

Network Error: Software caused connection abort

1. パテを開始
2. 接続設定を保存している場合はロードします
3. 「接続」をクリックします
4. 「セッションをアクティブに保つためのヌルパケットの送信」というセクションで、5秒に変更しました。ネットワークの停止が問題の場合は、300秒の方が良い場合があります。詳細については以下をお読みください。

キープアライブがPuttyとの切断を防ぐ方法：

一部のネットワークルーターとファイアウォールは、それらを経由するすべての接続を追跡する必要があります。通常、これらのファイアウォールは、特定の時間間隔が経過した後、どちらの方向にもデータが転送されない場合、接続が停止していると想定します。これにより、しばらくの間セッションにトラフィックが見られない場合、ファイアウォールによってPuTTYセッションが予期せず閉じられる可能性があります。

キープアライブオプション（「キープアライブ間の秒数」）を使用すると、実際の端末セッションを中断させない方法で、定期的にセッションを介してデータを送信するようにPuTTYを構成できます。ファイアウォールがアイドル接続を切断している場合は、このフィールドにゼロ以外の値を入力してみてください。値は秒単位で測定されます。したがって、たとえば、ファイアウォールが10分後に接続を切断する場合、ボックスに300秒（5分）を入力することができます。

パテ自動ログインと「スクリーン」ツールを使用して問題を軽減する

PuTTYは、一度に数分間接続が失われるくだらないWiFiを処理できません。回避策は、自動ログインと画面を使用することです。

インターネット接続が1分間途絶えた後、パテが端末を再同期することは簡単な問題ではありません。停止中に中間者攻撃のリスクを負います。とにかく自分を再認証する必要があります。パテはあなたにそれを課すのではなく、ただあなたを落とします。

したがって、パテがあなたに代わって自動ログインできるように、自動ログインを使用してください。

1. パテを使用しているコンピューターでputtygenツールを使用して秘密鍵を生成します。
2. 公開鍵を/home/youruser/.ssh/authorized_keysサーバー側のputty go loginを使用しているサーバーに貼り付けます。
3. パテ設定Connection-> SSH-> Authで、パテがプライベートキーにアクセスできるようにします。
4. 「認証用のプライベートキーファイル」の下にプライベートキーファイルを指定して、プライベートキーを追加します。
5. パテ接続設定を保存します。

その後、パテを介して接続をダブルクリックできるようになります。ユーザー名/パスワードを入力せずに、ターミナルに直接アクセスできます。

だから今、あなたはのようなキーボードの組み合わせでその接続上のパテにログインをフックすることができますF6。そのため、wifiが悪くなり、ドロップした場合。F6をマッシュダウンすると、再びログインします。

しかし、あなたはまだあなたの端末の状態を失います！それを修正する方法は？「スクリーン」プログラムを使用します。「screen」と入力して、新しい画面を作成します。新しい画面が作成されます。

追い出されて自動ログインされたら、画面に再接続できます。これを行う方法のチュートリアルは次のとおりです。http：//www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

screenドロップするたびに入力して再接続するのは面倒です。したがって、「最後に使用可能な画面に自動的に戻る」スクリプトを作成して、透明にすることができます。

そのため、パテ端末がフリーズしたとき。次のようになります。軽norをし、Alt + F4を押しつぶしてパテを閉じ、F6を押しつぶします。そして、6秒後には、中断した場所に戻ります。

理論的にはさらに良い解決策

理論的には、上記のプロセス全体をスクリプト化して、端末がドロップされたことを検出し、インターネット接続の復元時に上記のすべてのステップを実行できるようにします。誰かがこれを自動的に行うプログラムを知っているなら教えてください。それはきちんとしているでしょう。

ソース：

http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-keepalive

http://rafaelwolf.com/?p=516

PuTTYネットワークエラーのトラブルシューティング

Software caused connection abort

PuTTYがエラーについて何を言っているかを読む

これは、何らかの理由で確立された接続を強制終了するときにWindowsネットワークコードによって生成される一般的なエラーです。たとえば、イーサネット接続されたコンピューターの背面からネットワークケーブルを引き出したり、Windowsにネットワーク全体が到達不能になったと思われる他の同様の理由がある場合に発生する可能性があります。

また、Windowsは、応答する接続のもう一方の端のマシンをあきらめた場合に、このエラーを生成します。クライアントとサーバー間のネットワークがダウンし、クライアントがデータを送信しようとすると、Windowsはデータの送信を何度か試み、接続を断念して終了します。特に、SSH-2を使用していて、PuTTYがキーの再交換を試みる場合、何も入力しなくても発生する可能性があります。

（接続でキープアライブを使用している場合にも発生する可能性があります。他の人々は、キープアライブがこのエラーを修正すると報告しています（キープアライブの長所と短所があります）。）

PuTTYのバグを表すこのエラーが発生する理由はわかりません。問題は、あなた、あなたのWindowsシステム、あなたのネットワーク、そしてリモートシステムの間です。

別のSSHクライアントを試す

ほとんどの場合、問題はPuTTYとターゲットSSHサーバーの間のどこかに存在します。これの証拠を提供するには、（http://kitty.9bis.net）のような別のSSHクライアントを使用し、その上でも問題が発生するかどうかを確認します。おそらく、PuTTYから問題を隔離するでしょう。

疑わしいインターネット接続

問題は、むらのあるインターネット接続にある可能性があります。インターネット接続インターネット接続の稼働時間を監視することは、ISPがパケットを失っているかどうかを判断する良い方法であり、PuTTYがダウンしたことを非難することです。インターネット接続の稼働時間をテストするソフトウェアを入手してください。たとえば、http：//code.google.com/p/internetconnectivitymonitor/。頻繁かつ長時間インターネットから切断されると、ISPサービス要件に違反します。この場合、テクニカルサポートがコンピューター、OS、ルーター、自宅への配線に関するこれらの種類の問題を自動的に非難するため、ISPの障害であることを証明するのは困難です。ケーブルインターネットを使用して金持ちで生活している場合、隣の家の欠陥のあるハードウェアが、最初に電源を入れたときに数秒/分の間、回線に静的なデータを送信している可能性があります。最後に、自宅へのISPのネットワークに欠陥のあるハードウェアがある可能性があります。ISPがハードウェアを交換するためのコストは非常に高く、そのコストを保証するのに十分な加入者がエリアにいない限り、ISPがそれを行わないことがよくあります。

有線/無線ルーターを疑う

有線/無線ルーターを介して接続していますか？これはどれくらい古いのですか？ルーターに問題がある可能性があります。古いワイヤレスおよびワイヤードテクノロジーは、古いものを取得し、散発的に接続を切断して再起動し、PuTTYを停止させる可能性があります。これらのコンポーネントを方程式から削除し、それが問題を解決するかどうかを確認します。有線接続や別のルーターを試して、問題が解決するかどうかを確認してください。Linksysワイヤレスルーターでこの遅い死を経験し、接続を切断して再起動しました。

SSH接続を提供しているオペレーティングシステムが疑われる

SSHで接続しているコンピューターには、SSH接続を維持する秒数のポリシーがあります。この数はセキュリティ上の理由から低く設定されており、増やすことができます。この設定の場所は、SSHを提供する使用しているオペレーティングシステムによって異なります。

仮想マシンを介してPuTTYを使用している場合

仮想マシンを通過するPuTTYを使用している場合、仮想マシンが非アクティブだと判断したときにサーバーへのSSH接続を切断しているというポリシーが存在する場合があります。これらの値を増やすことは、使用している仮想マシンソフトウェアとオペレーティングシステムによって異なります。

インターネット接続が悪い場合、SSHクライアント接続の回避策：

ISPが不安定な接続を提供している場合、「ssh autologin」を使用して切断の痛みを軽減できます。あなたがすることは、公開鍵と秘密鍵を生成することです。また、外部サーバーに、正確な秘密キーを提供する人を自動的に入れるように指示します。問題が完全に解決するわけではありませんが、インターネットの停止が発生した場合、ウィンドウを閉じてアイコンをダブルクリックするだけで、ユーザー名/パスワードを入力せずにすぐにホームフォルダーのコマンドラインに戻ります。

これはあなたを助けます： パスワードでPuTTYに「自動ログイン」する方法はありますか？

管理者特権でのコマンドプロンプトで、次を実行します。

C:\Windows\system32>netsh int tcp show global

Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled

Chimney Offload State               : automatic

NetDMA State                        : enabled

Direct Cache Acess (DCA)            : disabled

Receive Window Auto-Tuning Level    : normal

Add-On Congestion Control Provider  : none

ECN Capability                      : disabled

RFC 1323 Timestamps                 : disabled

Receive Window Auto-Tuning Level正常であれば、問題が発生します。無効にすると、すべてが次のように機能するはずです。

C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled

私はWindows PCのCentOSサーバーで作業しましたが、PuTTYでも同じ問題がありました。セッションは1〜5分以上続きませんでした。PuTTY設定（キープアライブなど）で遊んでみましたが、まったく役に立ちませんでした。

最後に、私のケースの解決策を見つけました。 クライアントとサーバーの両方でTCPダンプを記録しました。私は、切断する前の25-30秒の間に、クライアントのダンプに（クライアント側とサーバー側の両方から）TCPセグメントのいくつかの再送信があり、最後にPuTTYがRSTを送信し、そのエラーでセッションを閉じることを発見しました。サーバーのダンプでは、この期間にクライアントからのセグメントは表示されませんでした。RSTでさえも。つまり、クライアントからのTCPセグメントがサーバーに配信されないことがあり、この期間は約30〜60秒です。このケースを数回記録しましたが、PuTTYからの再送信と最終RSTが常にありました。おそらくルート上のどこかで、パケットがネットワーク機器によってドロップされました。

回避策を講じるために、データ再送信の最大数をデフォルト値の5から16に増やしました。これにより、PuTTYの切断が速すぎるのを防ぐことができます。変数は「HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions」です。この変数は手動で追加しましたが、最初はWindowsのレジストリで定義されていませんでした。それは助けになりました！現在、PuTTYは時々ハングすることがわかりますが、常に仕事に戻ります。

問題を解決するには： 1. TCPダンプを記録し、切断する前に再送信とRSTを探します。2.同じ再送信/ RSTセグメントが見つかった場合は、サーバーまたはクライアント側で再試行の回数を調整します（RSTの側に依存します）。

注意：TCP設定の変更は、すべてのソフトウェアとOS自体に適用されます。

エラーネットワークエラー：ソフトウェアは、ネットワーク上でIPアドレスの競合（2つ以上のコンピューターが同じIPアドレスを持っている）がある場合に、PuTTYからの接続中断を引き起こします。（同じIPアドレスを使用するように手動でセットアップされた不正なデバイス/コンピューターと同じDHCPアドレスがDHCPサーバーによって割り当てられたRaspberry Piでこの問題が発生しました。）

この特定のケースでは、Windows 7コンピューターでローカルに、またはネットワーク上の別のデバイスとIPアドレスが競合している可能性があります。Wiresharkを使用して、この種のエラーを正常に追跡できます。

エラー10053 WSAECONNABORTED（ソフトウェアによって接続が中断されました）は、さまざまな理由で発生する可能性がある一般的なWinsockエラーです。

公式の説明が書かれています：

このエラーは、データの再送信が失敗した後にWinsockが確立された接続を閉じるなど、ローカルネットワークシステムが接続を中止したときに発生する可能性があります（受信者はデータストリームソケットで送信されたデータを確認しません）。

この問題の理由は、欠陥のあるネットワークケーブルから単純な接続の損失までさまざまです。単一のソリューションを提供することは不可能です。

新しいWLANルーター/ 3Gモデムをインストールしてインターネットに接続した後、PuTTYで同じ問題が発生しました。上記のすべてのキープアライブソリューションと、ルーターの構成メニューにあるすべてのソリューションを試しましたが、効果はありませんでした。

それから、90年代の固定電話モデムを持っていた頃のことを思い出しました：MTU（最大伝送ユニット）、基本的には転送されるデータチャンクの最大サイズ-接続の安定性に顕著な影響がありました。

そこで、WLANルーターの構成を確認し、MTU設定を見つけて、1424の固定値から「自動」に変更しました（より小さい値を試してみましたが、「自動」の方が音がよくなりました）。その後、PuTTYでこれ以上問題は発生しませんでした。接続は確実に確立されました。これが、少なくとも「ネットワークエラー：ソフトウェアによって接続が中断された」という問題の解決に役立つことを願っています。

接続タブ：キープアライブを「5」秒に設定し、有効にします

しかし、もっと重要なのは：

接続 - > SSH - > のKex、再入力前に最大分： "2"（デフォルトは60です）。

PuTTYがしばらくしてキーを失い、タイムアウトが発生しました。その値を「2」分に落とすことで問題は解決しました。私は今、いつまでもつながっています。

WinSCPスクリプトまたはGUIコンソールで同じ問題が発生しました。最後に、速度に関連していることがわかりました（インターネットの速度-サーバーはインターネット上にあります）。スクリプトをネットワーク内の別の場所、別のサイトに移動しましたが、GUIとスクリプトの両方がうまくいきませんでした。

多くの分析と並べ替えの後に整理されています。

TCPKeepAliveLinuxで有効にする必要があります。

このエラーを検索しているときに、WebサイトのPuTTyのFAQで説明されています。

仮想マシンがローカルハードウェアで実行されている場合、キープアライブパケットを無効にします。

私は実際にこの問題に何度も直面していました。私は何時間も費やすソリューションを探しましたが、どれも効果的ではありませんでした。私は自分のために働いた解決策を共有しており、他の人にも役立つことを願っています。

ホストO / SとしてWindows 10を、ゲストO / SとしてRedhat-7を使用し、VMwareが接続をブリッジしました。DBAとして、クライアントを訪問する必要があり、クライアントの前提に従ってネットワーク構成を設定する必要があります。そのため、クライアントの構内を離れ、ワイヤレスおよびオープンVMを介して別のネットワークに接続するたびに、質問で述べたのと同じ問題に直面しました。それでしばらく考えて、LANイーサネットとワイヤレスイーサネットの構成を確認しましたが、不一致が見つかりました。私の仮想マシンは、ブリッジングのために2つの物理イーサネットを自動的に使用するためです。そのため、LAN /ワイヤレスイーサネットのネットワーク構成をDHCPにリセットすると、チャームのように機能し、接続が中断することはなくなりました。[ホストマシンをDHCPに設定した後、ホストマシンを再起動することもできます。]