ssh_exchange_identification: read: Bağlantı eş tarafından sıfırlandı

106

OS X üzerinde bir ubuntu 12.04 sunucusuna ssh çalışıyorum. Aniden işler durdurulana kadar SSH'yi yapabildim. -vBu hata ayıklamak için kullanmak için çevrimiçi okudum . Çıktı aşağıda gösterilmiştir. Farklı bir kutuya ssh atarsam ve o kutudan sunucuya ssh girersem giriş yapabilirim. Bu sorunun nasıl hata ayıklanacağı hakkında hiçbir fikrim yok ama öğrenmek istiyorum.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Şimdiye kadar (mesaj panolarının tavsiyesi üzerine) bir ev sahibi reddetti dosyasını aradım - ancak makinemde böyle bir dosya yok.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

İstemci makinede yönetici erişimim var ancak sunucuda değil.

ssh

— bernie2436
kaynak

sshdAlternatif bir bağlantı noktasında, ayrıntılı çıktıyla dinlemeye başlamanızı ve bağlanmaya çalışırken çıktıyı vermenizi öneririm . $(which sshd) -d -p 23. Bunu yapabilme yeteneğiniz yoksa, seçenekleriniz oldukça sınırlıdır. En iyi bahis, sunucuda yönetici haklarına sahip birisini elde etmektir.

— Patrick,

Sunucudaki yöneticinin bir nedenden dolayı erişiminizi kısıtlaması olabilir mi? Her durumda, o kişiyle iletişim kurabilirim.

— mdpc

12

Hosts.deny ve hosts.allow dosyası , istemcide değil sunucuda kontrol edilmelidir . Ayrıca, sunucudaki sistem günlükleri kontrol edilmelidir. Bunlardan herhangi birine erişiminiz yoksa, bakmak için sunucu yöneticisine başvurmak isteyebilirsiniz.

— ckujau

bunun için bir çözüm buldun mu? problem neydi?

— MeV

2

Yönetici tarafından otomatik bir komut dosyası ile doldurulmuş bir hosts.deny listesi oldu. Şifremi bir noktada unuttuğumda, giriş yapmak için birkaç başarısız girişim oldu; bu, IP adresimin hosts.deny listesine girdiği zamandı. Aşırı derecede güvenliğin üretkenliği için çok fazla.

— K.-Michael Aye

24

Ani değişiklik, sunucu sshdyapılandırmasındaki yapılandırma dosyasındaki bir değişikliğin sonucu olabilir , ancak yönetici hakkı olmadan bunu kontrol edemez veya değiştiremezsiniz. Sunucunun yöneticilerine ulaşılamazsa (zaman içinde) aşağıdakileri deneyebilirsiniz.

Günlüğünüz yalnızca yerel sürüm dizesini gösterir sshd, sunucuda ve ara makinede çalışan sürümleri kontrol etmelisiniz .

Bu sürümler (özellikle orta makine ve sunucu arasında yerel makine ve sunucu ve daha az arasında) farklıysa bazı müzakere uyumsuzluğu, bu olabilir daha önce oldu yılında ssh. Çözüm, şifreleri, HostKeyAlgorithms ve / veya MACs girişlerini kısaltmak ya da komut satırında ( ssh -c aes256-ctrya da vb.) Kullanmaktaydı /etc/ssh/ssh_config.

-c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsVe -m/ MACscommandline resp için argüman olarak uygun değerler için hata ayıklama bilgisine (ara ürün üzerinden sunucuya bağlanmadan) bakmalısınız . ssh_config değişir.

Bir süredir bu sorunu yaşamadım, ancak yaptığımda IIRC Şifreleri ve HostKeyAlgorithms ayarını manuel olarak zorlamak için yeterliydi, daha sonra sunucunun sshdsürümünü güncelleyebilirdim ve sorun çözüldü .

— Anthon
kaynak

3

Benim durumumda, sunucu sshdpaketi daha yeni bir sürüme güncellendi ve sshdediğiniz gibi mevcut müşteri yapılandırmamla uyumsuzluğa neden oldu . Eski sshkonfigürasyon dosyalarımı silmek hile yaptı. Bu kabul edilen cevap olmalı.

— chakrit

2

@chakrit, eski ssh yapılandırma dosyalarınızı nasıl temizlediniz?

— Jonathan

@Jonathan Bunu yapmak için bir kurtarma diski monte ettim.

— chakrit

16

Sen tarafından yasaklanmış olabilir fail2banya denyhosts. Böyle bir durumda (ve ayrıca kontrol etmek için), sunucu sağlayıcı yardımcınızla uğraşmak istemiyorsanız, sunucunuza başka bir IP adresinden giriş yapmanız gerekir: örn. Başka bir sunucu veya bir arkadaşınızın ev bağlantısı veya wifi etkin nokta veya TOR ile SSH kullanarak.

Oturum açtıktan sonra, IP adresinizin gerçekten /etc/hosts.deny(sunucu tarafında) görünüp görünmediğini kontrol edin . Eğer öyleyse, o zaman fail2banya da denyhostsgerçekten suçlu olmalı.

denyhostsAdresinizi sürekli olarak engelleme prosedürü için bu sorunun cevaplarına bakın . For fail2banile ip bulmak iptables -L --line-numberve birlikte ip unban iptables -D <chain> <chain number>, sen ayrıntıları kontrol howtoforge .

Sorunun tekrarlanmasını önlemek için IP adresinizi fail2banve denyhostsbeyaz listeye (sırasıyla /etc/fail2ban/jail.conf, satır ignoreipve /var/lib/denyhosts/allowed-hostsgerekirse oluşturun (ancak yolun dağıtımınızda farklı olabileceğine dikkat edin)) eklemek isteyebilirsiniz.

— Skippy le Grand Gourou
kaynak

9

Ana bilgisayar sunucusunda, burada bulunan ssh pub.key dosyasını kaldırın: mac'unuz ~/.ssh/authorized_keysiçin. Sonra tail -f /var/log/auth.logbaşka bir terminal açıp tekrar ssh kurmaya çalışın ssh -v me@server. Sizden şifre istenirse, ssh anahtarınızla ilgili bir sorun oluştu. Hala 'ssh_exchange_identification: read: Bağlantıyı eş tarafından sıfırla' yanıtını görüyorsanız, başarısız denemenizden sonra '/var/log/auth.log' dosyasındaki günlük girişindeki sorunun ne olduğunu tespit edebilmelisiniz. giriş yapmak.

Hala bağlantı kuramadıysanız, oturum açmış olan girişi auth dosyasından buraya gönderin ve cevabımı düzelteceğim.

— devnull
kaynak

Bazı durumlarda SSH anahtarını silmenize gerek yoktur. Doğrudan -f /var/log/auth.log kuyruğuna gidin ve en son girişimleri kontrol edin.

— Jack Robson

6

Ağda aynı MAC adresine sahip birden fazla makineniz varsa (örneğin, sanal bir makinenin bir kopyasını çıkardığınızda ve MAC'yi değiştirmeyi unutursanız) bu olabilir.

— elCapitano
kaynak

4

Bunu, servis sağlayıcımın isim sunucuları nedeniyle alıyordum /etc/resolv.conf. Bu ad sunucuları genellikle aşırı yüklenir ve ters DNS araması başarısız olursa sshdbağlantıyı keser. Problemi, daha güvenilir isim sunucuları kullanarak çözdüm, örneğin 8.8.8.8.

— njahnke
kaynak

4

Aynı sorunla karşılaştım. Başarıyla ssh oturumu açacaktı ama bir süre sonra sıfırlanacaktı. Hemen kazanç bağlamaya çalıştığımda "Bağlantı reddedildi" hatası alırdım. oturumu ayıkladığımda bu mesajı bağlantı sıfırlanırken aldım

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

Bu noktada ağda bir IP adresi çakışması olduğunu fark ettim. Başka bir adrese değiştirdim ve sorun çözüldü

— David
kaynak

2

Olumsuz, cevapta yanlış olan ne? Yine de bir listeye girerken kontrol etmek için geçerli bir durum olabilir, belki diğerleri arasında ortak bir liste olmayabilir.

— Pysis

@Pysis: Doğru, olumlu cevap

— Daniel

3

Günlüğünüz, sunucu tarafının bağlantıyı kestiği anlamına gelir. Sebebini bulmak için sunucu tarafındaki günlüklere bakmalısınız, bağlantı kesilmelerinin nedenini göstermelidirler. Neredeyse her zaman / var / log / messages içindeki günlükleri bulabilmeniz gerekir.

İstemci, sürüm numarasını gönderdikten hemen sonra bağlantı koptuğu için, sunucuyu bir şekilde uyumsuz olarak tehdit ettiğini tahmin edebilirim.

— gena2x
kaynak

3

Aynı problemi yaşadım ama sebebi farklı çıktı: Yanlış port kullanıyordum.

sshVerilen hatanın daha yeni sürümlerinde Connection refusedveya Bad port.

Eski versiyonlarda verilen hata ssh_exchange_identification: read: Connection reset by peer

Yani böyle bir hata aldığınızda portun doğru olup olmadığını kontrol edin.

— Mugoma J. Okomba
kaynak

1

Bu sorunun eski olduğunu biliyorum, ancak sahip olduğum bazı bulguları paylaşmak istedim. /var/empty/sshdSunucuda uygun mülkiyet ve izinlere sahip olup olmadığını kontrol edin .

Bazı dizin izinlerini güncellemek için değiştirilmiş, ancak yanlışlıkla hedefin altındaki dizini güncelleyerek, bir uygulama kullanıcısı / grubuna / var mülkünü değiştiren ve izinleri 775 olarak değiştiren bir şef komut dosyası vardı.

— Andrew Boerema
kaynak

1

Bir Yanıtta açıkça belirtilmediğinden, bu hatanın ortaya çıkabileceği diğer bir yol, siz ve sunucu arasındaki ağ tabanlı bir güvenlik duvarının bağlantıyı engellemeye karar vermesidir. Güvenlik duvarı, OS X sisteminin IP'sinden "çok fazla" bağlantı olduğuna karar verebilirdi ve engellemeye başladı. Diğer sistemden henüz "çok fazla" bağlantı kurulamadı ve buna izin verildi.

Sunucudan en son aldığınız mesaj, hesabınızı, anahtarınızı veya şifrenizi çevreleyen geniş bir olasılık sınıfını dışlayan herhangi bir kimlik doğrulama denemesine başlamadan önce gelen bir mesajdır.

Bu tür kaba kuvvet politikalarına, satıcılardan rastgele örnekleme örneklerinden bazıları şunlardır:

— Jeff Schaller
kaynak