PuTTYネットワークエラー：ソフトウェアが原因で接続が中断されました
私は奇妙な問題を抱えています。SSHでPuTTYを使っているとき、私のローカルWindows 7の VMware でホストされているLinuxサーバーに接続しています。 、私はよく"Network error: Software caused connection abort"と言ってエラーが出ます、そしてそれからPuTTY SSHウィンドウは非アクティブです。通常、私はPuTTYでサーバーにログインして何かをすることができますが、ランダムな時間（約1分か2分）の後に私はそのエラーを得ます。そして時々私はログインさえできず、タイムアウトと言ってエラーを得ます。
私のVMware Playerには、コードレポジトリサーバーとして別のUbuntuデスクトップをコードリポジトリサーバーとしてホストしているため、SVNの更新/コミットを実行してもタイムアウトエラーが発生しないことが多いので、問題があると思います。しかし、Windows 7では、コードリポジトリとしてVMwareでホストされているものと同じUbuntuサーバーが非常にうまく機能するため、Windows 7にはちょっとしたおかしなことがあると思います。私がWindows XPからWindows VistaそしてWindows 7に移行した後に起こることはすべて悪いことのようです。
この問題の原因は何だろうか。また、どのように修正できますか。
補足：
私はグーグル検索をして、そして助けるためにすべての方法を適用した：
- Sshdを有効にする
TCPKeepAlive - Sshd
ClientAliveIntervalを900に、ClientAliveCountMaxを3に設定します。 - PuTTY接続設定の「秒間隔のキープアライブ」を
5に設定します。
しかし、これらはすべてうまくいきません！そしてPuTTYでのSSHセッションはしばらくしても中断されます。
LinuxサーバーのファイアウォールとWindows 7クライアントのファイアウォールの両方をオフにしましたが、それでもログインがタイムアウトします。本当に迷惑です！
ログインできることもありますが、ログインがタイムアウトすることもあります。その理由はわかりません。それは私を狂わせる！
私が言及しなければならないことの一つは、私がPuTTY SSHを使用してリモートサーバーに接続しているとき、そしてそれはすべて大丈夫です！
ログインに失敗したとき、pingも失敗しました。しかし、どうすればそれが起こるのでしょうか。私は自分のローカルマシンでLinuxサーバをホストするためにVMware Playerを使います！
PuTTYには、この問題を解決しようとする機能があります。
Network Error: Software caused connection abort
- PuTTYを起動
- 保存している場合は接続設定を読み込みます
- 「接続」をクリック
- 「セッションをアクティブに保つためのnullパケットの送信」というセクションで、5秒に変更しました。ネットワークの停止が問題になっている場合は、300秒のほうがよい場合があります。詳細は以下を参照してください。
PuTTYで切断を防ぐためのキープアライブ方法
一部のネットワークルーターおよびファイアウォールは、それらを通過するすべての接続を追跡する必要があります。通常、これらのファイアウォールは、一定時間経過してもデータがどちらの方向にも転送されない場合、接続が切れていると見なします。しばらくの間セッションにトラフィックが見られない場合、これによりPuTTYセッションがファイアウォールによって予期せず閉じられることがあります。
キープアライブオプション（「キープアライブ間の秒数」）を使用すると、実際の端末セッションを中断させないように、定期的にセッションを通じてデータを送信するようにPuTTYを設定できます。ファイアウォールがアイドル接続を切断していることがわかった場合は、このフィールドにゼロ以外の値を入力してみてください。値は秒単位で測定されます。そのため、たとえば、ファイアウォールが10分後に接続を切断した場合は、ボックスに300秒（5分）を入力します。
PuTTY自動ログインと "screen"ツールを使用して問題を軽減します
PuTTYは、一度に数分間接続を失うような不安定なWiFiを処理できません。回避策はautologinとscreenを使うことです。
PuTTYがインターネット接続を失ってしばらくしてから端末を再同期するのは、ささいな問題です。あなたは、停電中に中間者攻撃の危険を冒します。確認するには、とにかく自分自身を再認証する必要があります。 PuTTYはあなたにそれを課しません、それはあなたを落とすだけです。
だからPuTTYがあなたに代わって自動ログインできるように自動ログインを使用してください。
- 秘密鍵を生成する puttygenツールを使って あなたがPuTTYであるコンピュータ上で。
- サーバー側のPuTTYを使用しているサーバーの
/home/youruser/.ssh/authorized_keysに公開鍵を貼り付けます。 - PuTTY設定のConnection-> SSH-> Authで秘密鍵をPuTTYにアクセス可能にする
- 「認証用の秘密鍵ファイル」の下に秘密鍵ファイルを指定して秘密鍵を追加します。
- PuTTY接続設定を保存します。
それからPuTTYを通してあなたの接続をダブルクリックすることができるでしょう、そしてそれはあなたがusername/passwordをタイプすることなしにあなたをターミナルに正しく連れて行くべきです。
だから今あなたはそのようなキーボードの組み合わせでその接続でPuTTYへのログインをフックすることができます F6。だから無線LANが悪くなるとあなたは落とされる。あなたはF6を壊して、あなたは再びログインしました。
しかし、あなたはまだあなたの端末の状態を失います！それを修正するには？ "screen"プログラムを使ってください。 'screen'と入力して新しい画面を作ります。新しい画面が作成されます。
キックアウトして自動ログインしたら、画面に再接続できます。これを行う方法についてのチュートリアルは、次のとおりです。 http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/
screenを入力してドロップするたびに再接続するのは面倒です。それで、あなたはそれを透明にするために「自動的にあなたを利用可能な最後のスクリーンに戻す」スクリプトを書くことができます。
それでPuTTY端末がフリーズしたとき。それはこのように見えます：あなたは軽蔑の軽蔑をして、PuTTYを閉じるためにAlt + F4を押しつぶし、F6を押しつぶします。そして6秒後には、中断したところから戻ってきます。
理論上、さらに優れた解決策
理論的には、上記のプロセス全体をスクリプト化することができます。そのため、端末はいつドロップされたのかを検出し、インターネット接続の復旧時に上記の手順をすべて実行します。誰かがこれを自動的に行うプログラムを知っていれば私に知らせてください。それはきちんとしているでしょう。
出典：
http://the.earth.li/~sgtatham/PuTTY/0.58/htmldoc/Chapter4.html#config-keepalive
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へのコストは非常に高いです、そのコストを正当化するのに十分な加入者がエリアにいない限り彼らはそれをしないことがしばしばあります。
有線/無線ルーターの疑いがあります
有線/無線ルーター経由で接続していますか？これはどれくらい古いのですか？ルーターが問題になっている可能性があります。古い無線と有線の技術では、古くなったり断続的に接続を切断したりして再起動し、PuTTYを停止させることがあります。方程式からこれらの成分を取り除き、それが問題を解決するかどうか確かめてください。有線接続や別のルーターを試して、問題が解決するかどうかを確認してください。私はLinksysの無線ルーターにこの遅い死を受けさせ、接続を落としてそれらを再起動させました。
SSH接続を提供しているオペレーティングシステムの疑いがあります
SSHで接続しているコンピュータには、SSH接続を維持するための秒数に関するポリシーがあります。この数はセキュリティ上の理由から低く設定されているので、増やすことができます。この設定がどこにあるかは、SSHを提供しているオペレーティングシステムによって異なります。
仮想マシンでPuTTYを使っている場合
仮想マシンを通過するPuTTYを使用している場合は、仮想マシンに非アクティブだと思われるときにSSH接続を切断するポリシーが仮想マシンにある可能性があります。これらの値を大きくすると、使用している仮想マシンソフトウェアとオペレーティングシステムによって異なります。
インターネット接続に問題がある場合は、SSHクライアント接続の回避策：
あなたのISPが不安定な接続を提供しているなら、あなたは "ssh autologin"を使って切断をより簡単にすることができます。あなたがすることは、公開鍵と秘密鍵を生成することです。そして、あなたはあなたの外部サーバに、正確な秘密鍵を提供する人を自動的に入れるように伝えます。問題が完全に解決するわけではありませんが、インターネットが停止してもウィンドウを閉じてアイコンをダブルクリックするだけで、ユーザー名とパスワードを入力せずにホームフォルダーのコマンドラインにすぐに戻ります。
昇格したコマンドプロンプトで、次のコマンドを実行します。
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'です。私は手動でこの変数を追加しました、それは最初私のウィンドウズのregistyに定義されていませんでした。それは助けました！今、私はPuTTYが時々ハングするのを見ます、しかしそれはいつも仕事に戻ります。
問題を解決するには、1.切断する前にTCPダンプを記録し、再送信とRSTを探します。 2.同じ再送信/ RSTセグメントが見つかった場合は、サーバー側またはクライアント側で再試行回数を調整します（RST側によって異なります）。
注意：TCP設定の変更はすべてのソフトウェアとOS自体に適用されます。
エラーネットワークエラー：ソフトウェアが原因でPuTTYからの接続が中断されました、IPアドレスが競合している場合ネットワーク上の（複数のコンピュータが同じIPアドレスを持っている）。 （私は Raspberry Pi で、 DHCP サーバによって不正なデバイス/コンピュータと同じIPアドレスが割り当てられていました。同じIPアドレスを使用するように手動で設定されています。
この場合、Windows 7コンピュータ上でローカルに、またはネットワーク上の別のデバイスとIPアドレスが競合している可能性があります。 Wireshark を使用すると、この種のエラーを正しく追跡できます。
接続タブ：キープアライブを "5"秒に設定して有効にする
しかしもっと重要なこと：
接続 - >SSH - >Kex、キー再生成前の最大分数： "2"（デフォルトは60）。
私のPuTTYはしばらくしてそのキーを失い、タイムアウトを引き起こしました。その値を "2"分に落とすと問題は解決しました。私は今、無期限に連絡を取り合います。
私は WinSCP スクリプトかGUIコンソールで同じ問題に遭遇しました。最後に、速度に関係していることがわかりました（インターネットの速度 - 私たちのサーバーはインターネット上にあります）。スクリプトをネットワーク内の別の場所、別のサイトに移動しましたが、GUIとスクリプトの両方がうまくいきませんでした。
それは多くの分析と分類の後に整理されています。
インターネットに接続するために新しいWLANルーター/ 3Gモデムをインストールした後、私はPuTTYで同じ問題を抱えていました。私は上記のすべてのキープアライブ解決策を試してみました - そして私のルーターの設定メニューのそれらすべて - 効果がありません。
それから、私が固定電話のモデムを持っていた90年代の頃から何かを思い出しました：MTU（最大伝送ユニット）、基本的に転送されるデータ塊の最大サイズ - それは接続の安定性に著しい影響を与えました。
それで私は私のWLANルーターの設定をチェックし、MTU設定を見つけ、それを固定値の1424から "Auto"に変更しました（私はもっと小さい値を試すつもりでしたが、 "Auto"のほうが良いです）。その後、私はこれ以上PuTTYに問題はありませんでした - 接続は今や堅実です。私はこれが少なくとも "ネットワークエラー：ソフトウェアが原因で接続が中断された"問題を抱えている誰かに役立つことを願っています。
私は実際に何度もこの問題に直面していました。私は解決策の支出時間を探しましたが、どれも効果的ではありませんでした。私は私のために働いた解決策を共有しています、そしてそれが他の人にも役立つことを願っています。
私はホストO/SとしてWindows 10を、ゲストO/SとしてRedhat-7を持っていて、私のVMwareはブリッジ接続を持っていました。 DBAとして、私はクライアントを訪問しなければなりません、そして、私はクライアント構内に従って私のネットワーク構成を設定しなければなりません。だから私はクライアントの家を離れてワイヤレスで他のネットワークに接続して開くときはいつでもVM私は質問で述べられているのと同じ問題に直面した。そこで、しばらく考えて、LANイーサネットとワイヤレスイーサネットの設定を確認しましたが、不一致が見つかりました。私のVMは自動的にブリッジングのために2つのうちの物理的なイーサネットを使うでしょう。そのため、LAN/Wireless Ethernetのネットワーク設定をDHCPにリセットしても、魅力的で、接続が中断されることはありませんでした。 [DHCPに設定した後にホストマシンを再起動することもできます。]
LinuxではTCPKeepAliveを有効にする必要があります。
このエラーを探しているときは、WebサイトのPuTTYのFAQで説明されています。
仮想マシンがローカルハードウェア上で実行されている場合は、キープアライブパケットを無効にします。