PuTTY Ağ Hatası: Yazılım bağlantının iptal edilmesine neden oldu


81

Garip bir sorun var: SSH barındırılan bir Linux sunucusuna bağlanma ile PuTTY kullanıyorum zaman VMware benim yerel üzerine Windows 7 , sık sık söyleyerek hatayı alıyorum "Network error: Software caused connection abort"ve sonra PuTTY SSH penceresi etkin değil. Genellikle sunucuya PuTTY ile giriş yapabilir ve bir şeyler yapabilirim, ancak rastgele bir süreden sonra (yaklaşık bir veya iki dakika) bu hatayı alıyorum. Bazen giriş bile yapamıyorum, zaman aşımı diyerek bir hata alıyorum.

VMware Player'ımda bir sorun var sanırım, çünkü VMware'de bir kod deposu sunucusu olarak barındırılan başka bir Ubuntu masaüstüne sahibim ve bir SVN güncellemesi / işlemi gerçekleştirdiğimde zaman aşımı hatası olmamasından çok daha fazla. Ancak, Windows 7'de bazı tuhaflıklar olduğunu tahmin ediyorum, çünkü VMware'de bir kod deposunda barındırılan Ubuntu sunucusu Windows Vista'da çok iyi çalışıyor! Windows XP'den Windows Vista'ya ve ardından Windows 7'ye geçtikten sonra tüm kötü şeyler oluyor gibi görünüyor!

Bu sorunun nedeni ne olabilir ve nasıl düzeltilebilir?

Ek :

Bir Google araması yaptım ve aşağıdakiler dahil yardımcı olmak için tüm yöntemleri uyguladım:

  1. Sshd'yi etkinleştir TCPKeepAlive
  2. Sshd Set ClientAliveIntervaliçin 900ve ClientAliveCountMaxhiç3
  3. PuTTY bağlantı ayarını 'korunanlar arasındaki saniye' olarak ayarlayın 5.

Ama bunların hepsi işe yaramıyor! Ve PuTTY'deki SSH oturumu bir süre sonra hala kırılıyor!

Hem Linux sunucu güvenlik duvarını hem de Windows 7 istemci güvenlik duvarını kapattım, ancak giriş hala zaman aşımına uğradı! Bu gerçekten sinir bozucu!

Görünüşe göre bazen giriş yapabilirim, ama bazen giriş zaman aşımına uğradı! Nedenini gerçekten bilmiyorum. Beni deli ediyor!

Söylemem gereken tek şey, PuTTY SSH'yi uzak bir sunucuya bağlanırken kullandığım ve her şey yolunda!

Giriş yapamadığımda, ping işlemi de başarısız oldu! Ancak, bu nasıl olabilir? Linux sunucumu yerel makinemde barındırmak için VMware player kullanıyorum!


Aktif olarak ssh bağlantısını kullanırken bu hatayı alıyor musunuz? veya bir süre aktif kalmasına izin verdikten sonra mı?
MaQleod

1
Bir hile için etkin değil. Ama bazen zaman aşımı için giriş bile yapamıyorum.
Robert

1
SSH sunucusunun oturum zaman aşımı ayarlarını kontrol ederdim.
MaQleod

Ama çoğu zaman, hatta zaman aşımı için macun dan sunucuya giriş yapamıyorum!
Robert

3
Bu sorun çözüldü mü? Aşağıda listelenen çözümlerin çoğunu denedim ve hiçbir şey benim için işe yaramadı. Başka bir önerin var mı? Robert'in orjinal sayısıyla aynı sorunla
yüzleştim

Yanıtlar:


58

Macun, bu sorunu gidermeye çalışan bir özelliğe sahip:

Network Error: Software caused connection abort
  1. Macunu Başlat
  2. Bağlantı ayarlarınızı kaydetmişseniz yükleyin
  3. “Bağlantı” üzerine tıklayın
  4. "Oturumu etkin tutmak için boş paket gönderme" bölümünde, 5 saniyeye değiştirildi. Ağ kesintileri sizin sorununuzsa 300 saniye daha iyi olabilir, ayrıntılar için aşağıyı okuyun.

görüntü tanımını buraya girin

Nasıl yapılır? Macunları Macun ile bağlantının kesilmesini nasıl önler?

Bazı ağ yönlendiricileri ve güvenlik duvarlarının, aralarındaki tüm bağlantıları takip etmesi gerekir. Genellikle, bu güvenlik duvarları, belirli bir zaman aralığından sonra her iki yönde de veri aktarılmazsa bağlantının kesileceğini varsayar. Bu, bir süre oturumda trafik görülmezse PuTTY oturumlarının güvenlik duvarı tarafından beklenmedik şekilde kapatılmasına neden olabilir.

Kalıcılık seçeneği ('Kalkanlar arasındaki saniye'), PuTTY'yi, oturum boyunca gerçek terminal oturumunu aksatmayacak şekilde düzenli aralıklarla veri gönderecek şekilde yapılandırmanıza olanak tanır. Güvenlik duvarınızın boşta kalan bağlantıları kesmekte olduğunu tespit ederseniz, bu alana sıfır olmayan bir değer girmeyi deneyebilirsiniz. Değer saniye cinsinden ölçülür; bu nedenle, örneğin, güvenlik duvarınız on dakika sonra bağlantıları keserse, kutuya 300 saniye (5 dakika) girmek isteyebilirsiniz.

Macun otologini ve "ekran" aracını kullanarak sorunu azaltın

Macun, bir seferde dakikalarca bağlantıyı kaybeden berbat bir wifi kullanamaz. Bir geçici çözüm, otolog ve ekranı kullanmaktır.

İnternet bağlantısındaki çok kısa bir süre sonra terminalinizi tekrar senkronize etmek macun için önemli bir problem değil. Kesinti sırasında insanın orta ataklarında risk alırsınız. Emin olmak için yine de kimliğinizi yeniden doğrulamanız gerekir. Macun size empoze etmez, sadece sizi düşürür.

Yani autologin kullanın, böylece macun sizin adınıza otomatik giriş yapabilir.

  1. Macun yaptığınız bilgisayardaki puttygen aracıyla özel bir anahtar oluşturun .
  2. Ortak anahtarı /home/youruser/.ssh/authorized_keyssunucuya yapıştırın, kullandığınız sunucuya yapıştırın go login yapın.
  3. Özel anahtarı, macun ayarlarında macun için erişilebilir kılın. Bağlantı-> SSH-> Yetkilendirme
  4. "Anahtar doğrulama için özel anahtar dosyası" altındaki özel anahtar dosyasını belirterek özel anahtarı ekleyin.
  5. Macun bağlantı ayarlarını kaydedin.

Ardından, bağlantınızı macunla çift tıklayabilirsiniz ve kullanıcı adınızı / şifrenizi yazmadan doğrudan terminale götürmeniz gerekir.

Yani şimdi bir klavye kombinasyonu ile bu bağlantıya macun için bir oturum açabilirsiniz F6. Yani wifi kötü gittiğinde ve düştüğünde. F6'yı ezip geçtiniz ve tekrar giriş yaptınız.

AMA yine de terminalinizin durumunu kaybedersiniz! Bunu nasıl düzeltebilirim? "Ekran" programını kullanın. 'Screen' yazarak yeni bir ekran yapın. Yeni bir ekran oluşturulur.

Dışarı atıldığınızda ve otomatik giriş yaptığınızda, ekranınıza yeniden takabilirsiniz. İşte bunun nasıl yapılacağı hakkında bir öğretici: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

Her screendüşürüldüğünüzde yazmak ve yeniden bağlanmak çok zordur. Böylece, saydam yapmak için "sizi en son ekrana otomatik olarak getirecek" bir komut dosyası yazabilirsiniz.

Öyleyse macun terminali donduğunda. Şuna benziyor: Bir hor horlama yaptınız, macunu kapatmak için Alt + F4'ü ezin, F6'yı aşağı çekin. Ve 6 saniye içinde bıraktığınız yerden geri döndünüz.

Daha iyi bir çözüm, teoride

Teoride, yukarıdaki tüm bu süreci yazabilirsiniz, böylece terminal ne zaman bırakıldığını algılar ve internet bağlantısının restorasyonunda yukarıdaki tüm adımları sizin için yapar. Birisi bunu otomatik olarak yapan bir program biliyorsa bana bildirin. Düzgün olurdu.

Kaynaklar:

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

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


Merhaba, Bunu yapıyorum, ancak hala yazılım bağlantısının kapandığı hatayı alıyorum
tuskiomi

Ayrıca, sakaliviler arasındaki saniyeler bir sonraki bağlantı için kaydedilemez.
ZhaoGang

10

PuTTY Ağ Hatasında Sorun Giderme

Software caused connection abort

PuTTY'nin hata hakkında neler söylediğini okuyun.

Bu, bir nedenden dolayı kurulmuş bir bağlantıyı kestiğinde, Windows ağ kodu tarafından üretilen genel bir hatadır. Örneğin, ağ kablosunu Ethernet bağlantılı bir bilgisayarın arkasından çıkarırsanız veya Windows'un tüm ağın erişilemez olduğuna inanması için başka benzer bir neden varsa olabilir.

Windows bu hatayı, makineye yanıt veren bağlantının diğer ucunda bırakmışsa da oluşturur. İstemcinizle sunucunuz arasındaki ağ kesilirse ve istemciniz bazı verileri göndermeye çalışırsa, Windows verileri göndermek için birkaç girişimde bulunur ve ardından bağlantıyı keser ve keser. Özellikle, hiçbir şey yazmasanız bile bu durum oluşabilir, SSH-2 kullanıyorsanız ve PuTTY anahtar değişimi yapmaya çalışır.

(Bağlantınızda saklayıcılar kullanıyorsanız da oluşabilir. Diğer insanlar saklayıcıların bu hatayı onlar için düzelttiklerini bildirmiştir. (Saklayıcıların artıları ve eksileri vardır.))

PuTTY'de bir hatayı temsil eden bu hatanın neden olabileceğinin hiçbir sebebinin farkında değiliz. Sorun siz, Windows sisteminiz, ağınız ve uzak sistem arasında.

Farklı bir SSH istemcisi deneyin

Büyük olasılıkla, sorun PuTTY ile hedef SSH sunucusu arasında bir yerde var. Buna kanıt sağlamak için, ( http://kitty.9bis.net ) gibi farklı bir SSH istemcisi kullanın ve sorunun bunun üzerinde de olup olmadığını görün. Muhtemelen sorunu PuTTY'den uzaklaştıracaktır.

Sivilceli şüpheli internet bağlantısı

Sorun sivilceli internet bağlantısı olabilir. İnternet Bağlantısı İnternet bağlantısının çalışma süresini izlemek ISS'nizin paketleri kaybedip kaybetmediğini ve PuTTY'nin düşmesi için suçlu olup olmadığını belirlemenin iyi bir yoludur. İnternet bağlantısının çalışma süresini test eden bir yazılım edinin. Örneğin, http://code.google.com/p/internetconnectivitymonitor/. İnternetten sık ve uzun süreli bağlantı kesilmesi, ISS servis gereksinimlerinin ihlalidir. Bu durumda, ISS'nin suçu olduğunu kanıtlamak zor olacaktır, çünkü teknik destek bilgisayarınızdaki, işletim sisteminizdeki, yönlendiricinizdeki ve evinizdeki kablo tesisatında bu tür sorunları otomatik olarak suçlar. Kablolu İnternet kullanıyorsanız ve boonilerde yaşıyorsanız, komşunuzun evindeki arızalı donanımın, ilk açıldığında birkaç saniye / dakika boyunca hatta statik olarak gönderilmesi mümkün olabilir. Son olarak, ISS'nin ağında evinize hatalı donanım olması muhtemeldir. ISS'lerin donanımlarını değiştirmelerinin maliyeti o kadar yüksektir ki, bir bölgedeki maliyeti zorlamak için yeterli sayıda abone olmadıkça, çoğu zaman bunu yapmayacaklardır.

Kablolu / kablosuz yönlendiriciden şüpheleniliyor

Kablolu / kablosuz bir yönlendirici üzerinden mi bağlanıyorsunuz? Kaç yaşında? Yönlendiriciniz sorun olabilir. Eski kablosuz ve kablolu teknoloji, bağlantıları eski hale getirebilir ve ara sıra bağlantı kurabilir ve PuTTY'nin ölmesine neden olarak yeniden başlatılabilir. Bu bileşenleri denklemden çıkarın ve bunun sorunu çözüp çözmediğine bakın. Sorunun çözülüp çözülmediğini görmek için kablolu bir bağlantı ve / veya farklı bir yönlendirici deneyin. Bir Linksys kablosuz yönlendiricisinin bu yavaş ölüme maruz kalması ve bağlantıların kesilmesi ve yeniden başlatılması vardı.

SSH bağlantısı sağlayan işletim sisteminden şüphelenin

SSH ile bağlandığınız bilgisayarın, SSH bağlantılarını canlı tutmak için birkaç saniye politikası vardır. Bu numara güvenlik nedeniyle düşük ayarlanmış ve siz de artırabilirsiniz. Bu ayarın nerede olduğu, kullandığınız işletim sisteminin SSH'yi sağlamasına bağlıdır.

PuTTY'yi sanal bir makine ile kullanıyorsanız

Sanal bir makineden geçen PuTTY kullanıyorsanız, sanal makinede, etkin olmadığını düşündüğü zaman SSH bağlantısını sunucuya bağlayan bir politika olabilir. Bu değerleri artırmak, hangi sanal makine yazılımını ve işletim sistemini kullandığınıza bağlıdır.

İnternet bağlantısı kötüyse, SSH istemcisi bağlantısı geçici çözümlere sahiptir:

ISS'niz dengesiz bir bağlantı sağlıyorsa, "ssh autologin" ile bağlantıyı daha az ağrılı yapabilirsiniz. Yapmanız gereken, ortak ve özel bir anahtar oluşturmak. Ayrıca yabancı sunucunuza, otomatik olarak doğru bir özel anahtar sağlayan herkese izin vermesini söyleyin. Sorununuzu tamamen çözmüyor, ancak İnternet kesintisi olduğunda, yaptığınız tek şey pencereyi kapatmak, bir simgeye çift tıklamak ve bir kullanıcı adı / parola girmeden hemen ana klasör komut satırına geri götürülmek.

Bu size yardımcı olacaktır: PuTTY'de bir şifre ile "otomatik giriş" yapmanın bir yolu var mı?


4

Yükseltilmiş bir komut isteminde aşağıdakileri çalıştırın:

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

Eğer Receive Window Auto-Tuning Levelnormalse, sorun yaşarsınız. Devre dışı bırakın ve sonra her şey eskisi gibi çalışmalıdır:

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

5
Bunun neden işe yaradığını / ne işe yaradığını açıklayabilir misiniz?
Eiyrioü von Kauyf

3
support.microsoft.com/kb/947239 bunun açıklaması
bksi

Benim durumumda yardımcı olmuyor.
reinierpost

4

Windows PC'lerden CentOS sunucularıyla çalıştım ve PuTTY ile aynı problemi yaşadım. Bir oturum 1-5 dakikadan fazla sürmedi. PuTTY ayarları (keepalives, vb.) İle oynamaya çalıştım ama hiç yardımı olmadı.

Sonunda davamın çözümünü buldum. Hem istemcide hem de sunucuda TCP dökümü kaydettim. Bağlantı kesilmeden 25-30 saniye önce, müşterinin dökümünde (hem müşteriden hem de sunucu tarafından) birkaç TCP kesiminin yeniden gönderildiğini ve nihayet PuTTY'nin RST gönderdiğini ve oturumu bu hatayla kapattığını keşfettim. Sunucunun çöplüğünde, bu dönemde müşteriden herhangi bir segment görmedim, hatta RST bile. Zaman zaman istemciden hiçbir TCP kesimi sunucuya teslim edilmez ve bu süre 30-60 saniyedir. Davayı birkaç kez kaydettim ve her zaman PuTTY'den yeniden iletimler ve son RST vardı. Muhtemelen yol paketlerinde bir yerlerde ağ teçhizatları düşmüştür.

Geçici bir çözüm bulmak için Maksimum veri aktarım sayısını varsayılan değer 5'ten 16'ya yükselttim. Bu, PuTTY'nin bağlantısının çok hızlı kesilmesini önleyebilir. Değişken 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransm' şeklindedir. Bu değişkeni manuel olarak ekledim, başlangıçta Windows kayıtlarımda tanımlanmadı. Yardım etti! Şimdi PuTTY'nin zaman zaman askıda kaldığını görüyorum, ancak her zaman işe geri dönüyor.

Sorunu çözmek için: 1. Bir TCP dökümü kaydedin ve bağlantıyı kesmeden önce yeniden iletimleri ve RST'yi arayın. 2. Aynı aktarımları / RST segmentlerini bulursanız, bir sunucu veya müşteri tarafında yeniden deneme sayısını ayarlayın (bu, RST'nin tarafına göre değişir).

Dikkatli olun: TCP ayarlarının değiştirilmesi tüm yazılımlar ve işletim sisteminin kendisi için geçerlidir.


3

Hata Ağ hatası: Yazılım neden bağlantı iptal bir varsa PuTTY gelen sonucudur IP adresi çakışması ağ üzerinde (iki veya daha fazla bilgisayar aynı IP adresine sahip). (Bu sorunu , DHCP sunucusu tarafından aynı IP adresini kullanmak için manuel olarak ayarlanmış bazı hileli aygıt / bilgisayar olarak atanmış aynı IP adresini alan bir Ahududu Pi ile yaşadım .)

Bu özel durumda, Windows 7 bilgisayarında yerel olarak veya ağdaki başka bir cihazla bir IP adresi çakışması olabilir. Wireshark , bu tür bir hatayı başarıyla izlemek için kullanılabilir.


2

Hata 10053 WSAECONNABORTED(Yazılım bağlantının kesilmesine neden oldu.), Herhangi bir nedenden ötürü yayılabilecek genel bir Winsock hatasıdır.

Resmi açıklama diyor ki:

Bu hata, yerel ağ sistemi, Winsock'un veri aktarımı başarısız olduktan sonra kurulan bir bağlantıyı kapatması gibi bir bağlantıyı kesmesi durumunda ortaya çıkabilir (alıcı, bir veri akışı soketinde gönderilen verileri hiçbir zaman onaylamaz).

Bu sorunun nedenleri, hatalı ağ kablolarından basit bağlantı kaybına kadar değişebilir. Tek bir çözüm önermek imkansız.


2

İnternete bağlanmak için yeni bir WLAN router / 3G modem kurduktan sonra PuTTY ile aynı problemi yaşadım. Yukarıdaki tüm canlı tutma çözümlerini ve yönlendiricimin yapılandırma menüsündeki tüm çözümleri etkilememeye çalıştım.

Daha sonra 90'lı yıllarda sabit hatlı bir telefon modemi varken bir şeyleri hatırladım: MTU (maksimum iletim birimi), temelde aktarılan maksimum veri boyutu büyüklüğü - bağlantının kararlılığı üzerinde kayda değer bir etkisi oldu.

Bu yüzden WLAN yönlendiricimin yapılandırmasını kontrol ettim, MTU ayarını buldum ve 1424 sabit bir değerden "Auto" olarak değiştirdim (daha küçük bir değer denemek istedim, ancak "Auto" daha iyi geliyordu). Ondan sonra, PuTTY ile daha fazla sorun yaşamadım - bağlantı artık çok sağlam. Umarım bu en azından "Ağ hatası: yazılım bağlantının kesilmesine neden oldu" sorunu olan birine yardımcı olur.


2

Bağlantı sekmesi: canlı tutmaya devam edin "5" saniye ve etkin

Ama daha önemlisi:

Bağlantı -> SSH -> Kex , Yeniden anahtarlamadan maksimum dakikalar : "2" (varsayılan 60).

PuTTY bir süre sonra anahtarını kaybediyor, zaman aşımına neden oluyordu. Bu değeri "2" dakikaya düşürmek sorunu çözdü. Şimdi sonsuza dek bağlı kalıyorum.


1

WinSCP betiği veya GUI konsolu ile aynı sorunu yaşadım . Sonunda bunun hız ile ilgili olduğunu buldum (İnternet hızı - sunucumuz İnternette). Komut dosyasını ağdaki farklı bir yere taşıdım, farklı site, hem GUI hem de Komut Dosyası iyi gitmedi.

Çok fazla analiz ve sıralama yapıldıktan sonra ayrıldı.


0

TCPKeepAliveLinux'ta etkinleştirmeniz gerekir .

Bu hatayı ararken, PuTTy'nin web sitesinde SSS bölümünde açıklanmıştır.


Ancak TCPKeepAlive için varsayılan değer evet'tir. Ancak, ben etkinleştirdim. Ancak şimdi oturum açma zaman aşımı ilk sorundur. Herhangi bir fikir?
Robert

Hem linux sunucu güvenlik duvarını hem de windows-7 istemci güvenlik duvarını kapattım, ancak giriş hala zaman aşımına uğradı! Gerçekten sinir bozucu!
Robert

Görünüşe göre bazen giriş yapabilirim ama bazen giriş zaman aşımına uğradı! Nedenini gerçekten bilmiyorum. Beni deli ediyor!
Robert

0

Sanal Makine yerel donanımınızda çalışıyorsa, canlı paketleri saklayın.


6
Cevabını genişletebilir misin? Belki gelecekteki ziyaretçiler için talimatlar verebilirim?
Kanadalı Luke

OP'mde tam tersi bir durum var - VM'im ana bilgisayara bağlanan ssh istemcisi ve istemci sık sık kesiliyor. Hayatta kalmayı devre dışı bırakmak sorunu çözmüş gibi görünüyor. Nedenini merak ediyorum.
Raman

0

Aslında birçok kez bu meselelerle karşılaştım. Çözüm harcama saatlerini aradım ama hiçbiri etkili olmadı. Benim için işe yarayan çözümü paylaşıyorum ve bunun başkalarına da yardımcı olacağını umuyorum.

Konuk O / S olarak Windows 10 ve O / S ana bilgisayarı ve Redhat-7 var ve VMware'im bağlantı kurmuştu. DBA olarak müşterileri ziyaret etmeliyim ve ağ yapılandırmamı istemci tesislerine göre ayarlamalıyım. Bu yüzden ne zaman müşteri tesisinden ayrılsam ve kablosuz ve açık VM aracılığıyla başka bir ağa bağlansam, sorunda belirtildiği gibi aynı sorunla karşılaştım. Bir süre düşündüm ve LAN Ethernet ve Kablosuz Ethernet konfigürasyonumu kontrol ettim ve uyumsuzluk buldum. VM'm, köprüleme için iki tane arasında fiziksel ethernet'i otomatik olarak kullanır. Bu yüzden LAN / Kablosuz Ethernet için ağ yapılandırmasını DHCP'ye sıfırladığımda çekicilik gibi çalıştı ve daha fazla bağlantı iptal edildi. [Ana makinenizi de DHCP'ye ayarladıktan sonra yeniden başlatabilirsiniz.]

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.