ssh_exchange_identification: Uzaktaki bir ana bilgisayar tarafından kapatılan bağlantı (hosts.deny kullanılmıyor)

Ben değilim değil kullanarak hosts.allowveya hosts.denydaha fazla SSH benim pencere-makine (aynı dizüstü bilgisayar, farklı bir sabit disk) ama benim Linux makine çalışır.

ssh -vvv root@host -p port verir:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Windows makinesinde her şey yolunda gidiyor, bu yüzden güvenlik kayıtlarını kontrol ettim ve içindeki satırlar aynı, sunucu iki farklı "makineye" farklı davranmıyor ve her ikisine de ortak anahtar kimlik doğrulama yoluyla izin veriliyor.

Bu da yerel ArchLinux dizüstü bilgisayarımla ilgili bir sorun olması gerektiği sonucuna yol açıyor.

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Demek sorun bu değil.

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Güvenlik duvarı ayarlarıyla çakışma yok (şimdilik).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

İzinler iyi görünüyor (sunucuda aynı) .. Ayrıca /etc/ssh/ssh_config, aynı hatayla sonuçlanan istemcide gerçekleşen bir çok otomatik yapılandırma dışında, aynı sonucu yapılandırmadan da denedim .

Herhangi bir "dış" faktörü göz ardı ettiyseniz, aşağıdaki adımlar kümesi genellikle daraltmak için yardımcı olur. Dolayısıyla, bu doğrudan sorunuzu yanıtlamamakla birlikte, hata nedeninin izlenmesine yardımcı olabilir.

Sorun giderme sshd

Bu gibi durumlarda genellikle çok yararlı sshdbulduğum şey, cüret etmesine izin vermeden başlamaktır . Benim durumumdaki sorun ne anlamlı ne syslogde auth.loghiçbir şey göstermedi.

Terminalden başladığımda aldım:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Çok daha iyi! Bu hata mesajı neyin yanlış olduğunu görmeme ve düzeltmeme izin verdi. Günlük dosyalarının hiçbiri bu çıkışı içermiyordu.

Not: en azından Ubuntu'da mutlak bir yolun gerekliliğini $(which sshd)karşılamak için en iyi yöntemdir sshd. Aksi aşağıdaki hatayı alırsınız: sshd re-exec requires execution with an absolute path. -p 10222Markaları sshdpotansiyel çalışan çatışma etmeyecek şekilde bu - yapılandırma dosyasını geçersiz kılma, bu alternatif bağlantı noktası üzerinde dinleme sshdörnekleri. Burada boş bir liman seçtiğinizden emin olun.

Son olarak: alternatif bağlantı noktasına ( ssh -p 10222 user@server) bağlanın .

Bu yöntem bana, kimlik doğrulama sorunları ya da diğer türler gibi sorunları bulmada birçok kez yardımcı oldu. Gerçekten ayrıntılı çıktı elde etmek için stdoutkullanın $(which sshd) -Ddddp 10222( ddayrıntı düzeyini artırmak için eklenenlere dikkat edin ). Daha fazla hata ayıklama iyilik kontrolü için man sshd.

Ayrıca, hafızası o kadar kötü parçalanmış bir ana bilgisayara da sahip olabilir ki, bir sayfaya SSH oturumunu barındırmak için süreci doldurmak için bitişik bir hafıza atayamazsınız.

Böyle bir durumda, mesajlardan birini alabilirsiniz:

ssh_exchange_identification: read: Connection reset by peer

veya:

Connection closed by aaa.bbb.ccc.ddd

Ana bilgisayar, ayrılmadan önce ne kadar uzağa gittiğine bağlı olarak.

Eğer hafıza parçalanması görünen sebep ise, çözüm sunucuya başka yollarla erişmek ve ilgili servislerin bir kısmını yeniden başlatmaktır. VM'lerin takas bölümü olmadığından, Apache ve MySQL'in VM'lerin suçlu olduğunu tespit ettim. Başarısız olursa, ana bilgisayarı yeniden başlatın.

Sadece durumda, çünkü bu bana oldu. Ana bilgisayarda çalışan sshd olduğundan emin olun!

Aptalca bir başarısızlık, ama gerçekten senin sorunun olabilir.

Bu hatanın sunucuya ssh oturumlarının aşılmasından kaynaklandığını buldum. Bağlanmaya çalışan ana bilgisayarları buldum ve tüm oturumları tüm istemcilerden öldürdüm. Tüm oturumları temizledikten sonra sorun çözüldü.

ssh_exchange_identification: read: Connection reset by peerBir döngü içinde 16 veya daha fazla ssh oturumu başlatan bir komut dosyasında sorunla karşılaştım . sshd görünüşte devam edemiyor; kısa bir uyku eklemek sorunumu çözdü:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Ya da dün gece yaptığım şeyi yaptım ve sildim / boş / boş. Görünüşe göre, bu dizin ve izinleri sshd'nin işleyişi için şarttır ve yeniden başlatıldığında dizini yeniden /etc/init.d/sshdbaşlatmaz ve yeniden başlatmayı başaramaz ve hiçbir sistemd nedenini size söylemez.

Sorunu ön planda sshd çalıştırarak buldum:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Dizinleri yeniden oluşturmak benim durumumdaki sorunu çözdü:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Linux programcılarına not: Kritik olarak önemli şeyler /var/empty... gerçekten ???

ssh_exchange_identification: Connection closed by remote hostSSH'ye bağlanmaya çalışırken hata aldım : Yerel bilgisayarımın SSH portu 22 için uzak bir portu yönlendirdim, böylece geçici olarak İnternet üzerindeki uzak bir sunucudan erişebildim.

Benim yerel bilgisayarda SSH hizmetini başlatmak zorunda yüzden ben başlangıçta SSH hizmetini devre dışı bıraktığını hatırlamıyorum çünkü Aslında hata sadece görüntülenen: sudo service ssh start.

İlk önce ilk şey; 22 nolu bağlantı noktasının bu ana bilgisayardan gerçekten dinleyip dinlemediğini doğrulamak için ana bilgisayar IP adresine telnet:

telnet x.x.x.x 22

(değilse, oturum açmak için bir konsol kablosu bağlayabilirsiniz)

Benim durumumda işe yaramadı ve oturum açmak için bir konsol kablosu bağladım. Giriş yaptıktan sonra, 5 VTY hattının hepsinin o ana bilgisayarda (bir Cisco yönlendirici) meşgul olduğunu keşfettim.

VTY hatlarını serbest bırakmak için orada asılı olan eski bağlantıları temizledim, işe yaradı. VTY satırlarına "exec-timeout 15" komutunu ekledim. Sonra konsol kablosunu çıkardım.

Ders:

Tüm cihazlarınızda 5-10 dakikalık bir zaman aşımı belirlediğinizden emin olun - (hiçbir etkinlik algılanmazsa).

Benim durumum yanlışlıkla soket proxy (çalışmıyor) ayarlandı. Tam olarak aynı ssh -vvv çıktısı ve boş sshd günlüğü aldım.

Hata ssh_exchange_identification: Connection closed by remote host, bilinmeyen nedenlerden dolayı olabilir. Ne zaman ben kullanıyordum Visual Studio kodunu . Aynı hata, git pullkomutu kullanarak uzak repodan çekmeye çalıştığımda da oldu .

Gömülü terminali kapattım ve Ubuntu'nun terminalini açtım ve tekrar çektim . Ve başarılı oldu

İle başlayan CentOS Linux release 7.4.1708 (Core)ile OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017bir bağlantı vardı portları filtreleme değil arkasında:

ssh_exchange_identification: Bağlantı uzak ana bilgisayar tarafından kapatıldı

Ve Ahududu Pi'm kapalı olduğu ortaya çıktı!

Açılmayan bir ana makinenin "Ev sahibine yol yok" hatasını vereceğini düşünüyordum. Ahududu Pi ISS yönlendiricimin arkasında, bu yüzden muhtemelen bağlantıyı kapatıyordu.

Sonra denemeyi tekrar yaptım (kapatılmış bir Raspberry Pi bağlantısıyla) başka bir internet bağlantısından Debian Stretch ile limanları filtrelemedim OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017ve bu sefer beklediğim gibi:

Ev sahibi için rota yok