SSH sorunu - Soketten okuma başarısız oldu: Bağlantı eş tarafından

23

SSH'yi tek yönde sorunsuz bir şekilde yapabilirim:

TAMAM:

ssh user@computerA

ama diğer yol:

ssh user@computerB

Ben olsun Read from socket failed: Connection reset by peer.

Bunu çözmek için nereye bakacağımı bile bilmiyorum.

Herhangi bir ipucu olan var mı?

ssh

— boehj
kaynak

Ağ yapılandırmanız nedir? Güvenlik duvarı / yönlendiricinin arkasındaki makineden herhangi biri var mı?

— NorTicU'lar

Her ikisi de birbirine bir yönlendirici üzerinden ethernet kablosu üzerinden bağlanmış. Geçmişte her iki yönde de SSH var.

— boehj

Her iki SSH daemonunun çalıştığını kontrol ettiniz mi? Kayıtlarda bir şey var mı?

— NorTicU’lar

İyi ve kötü haber: Kendi sorumu cevapladım. Bunu aşağıya yazarım. Yardımlarınız için teşekkürler.

— bohj

13

Sunucunun günlük dosyasını izlemeye başla

tail -f /var/log/auth.log
İstemci sonunda ayrıntılı bir çıktı elde etmek için -v ekle

ssh user@computerB -v

Bu size neden hakkında daha fazla ayrıntı verebilir. Sunucuda rsa ve dsa anahtarları eksikse, bunları düzeltin:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— şarbon
kaynak

Bu benim için çalıştı. Aşağıdakileri çalıştırmak için kök olmak zorunda olmama rağmen: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

Anahtarlar yeniden nesil kesinlikle işe yarıyor. Benim durumumda openssh kurulduktan sonra makine IP adresini değiştiriyordu (ve kurulum sırasında üretilen anahtarlar).

— Alfishe

Bunu yaptıktan sonra sunucuma bağlanma şansımı kaybettim. Hosting sağlayıcısının yardımını istemek zorunda kaldım. Hala cevaplarını bekliyorum. CPanel ile Centos 7.

— Tomas Gonzalez

8

SSH bitlerini aşağıdakileri yaparak tekrar yükledim:

sudo apt-get --reinstall install openssh-server openssh-client

Bu tüm sorunlarımı çözdü.

— boehj
kaynak

8

Tesadüf olabilir. Ssh'yi yeniden kurduğunuzda problemin bitmemesi, sebep ve sonuç için hava geçirmez bir güvence değildir. Bu arada, hangi tarafı yeniden kurdun? Ya da her ikisi de? Her durumda, "bu sorunun gelecekteki ziyaretçilere yardımcı olması pek mümkün değil".

— Kaz

5

änthräX'in yöntemi çok faydalıdır. Bu benim için çalışıyor!

Temelde ssh kurulduktan sonra, anahtar dosyalara ihtiyaç olduğunu düşünüyorum.

Yaptığım tek revizyon rsayerine kullanmaktı rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Bu değiştirilmiş yöntem benim için çalıştı.

— Alan_04
kaynak

Benim durumumdaki problem buydu. OP belirtisine sahip olan Utilite ARM makinesi için geçerli Ubuntu sürümüne sahip ssh sunucu paketi. Bu iki komutu çalıştırdıktan sonra (ki root olarak yaptım), sonunda ssh yapabiliyorum. Çok teşekkürler. +1

— James T Snell

1

Bunun nedeni, içerideki dosyaların izinlerinin /etc/sshdeğişmiş olması ... Dolayısıyla, aşağıda verilen örnekteki gibi dosyaların izinlerini değiştirin:

kullanın:

chmod 644 ssh_config
chmod 600 moduli

ve bunun gibi...

Son olarak, dosya izinleri aşağıdaki gibi bir şeye benzemelidir,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

İzinleri değiştirdikten sonra macuntan bağlanmayı deneyin, iyi çalışmalı ..

— Varun Joseph
kaynak

1

Macun neden alakalı? Ve OP'ye, değişiklik yapmasını tavsiye etmeden önce dosyalar üzerinde izinlerin ne olduğunu sormayı düşünün.

— Clive van Hilten

Yanıtı yanlış bir şekilde gönderdiğim için son derece üzgünüm. İşte buradaki, bazı uygulama yüklemeleri sırasında birisi bu dosyaların izinlerini 777 olarak değiştirdi. Bu, / var / log / messages (seri bağlantıya bağlanırken) makine). Dolayısıyla izinleri değiştirdi ve tahmin et ne oldu? ondan sonra iyi çalıştı.

— Varun Joseph

1

Benzer bir problemimiz vardı, ancak sadece Ubuntu'dan Solaris'e giriş yaparken ortaya çıktı. Tüm bu satırların /etc/ssh/ssh_config Ubuntu ana bilgisayarında bulunduğundan emin olmak sorunu çözdü (bu satırların bazılarının zaten mevcut olduğunu bulmalısınız):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Xubuntu için sadece son ikisine ihtiyacım vardı.

— Philip Kearns
kaynak

0

Bu mesaj aynı zamanda çoklu denenmiş ssh saldırılarından da kaynaklanabilir. Bu mesajı kayıtlarınızda görüyorsanız, kaba kuvvet şifresi teşebbüsleri kullanarak makinenize kötü amaçlı bir kaynak girmeye çalışıyor olabilir.

Denemeleri yavaşlatmak için "fail2ban" paketini kurun:

sudo apt-get install fail2ban

Gönderen fail2ban wiki :

Fail2ban, günlük dosyalarını tarar (örn / / var / log / apache / error_log) ve zararlı işaretleri gösteren IP'leri yasaklar - çok fazla şifre hatası, istismar arayışı, vb. belirli bir süre için

— Liloulinx
kaynak

1

Lütfen bunun neden işe yarayacağına dair daha fazla ayrıntı ile cevabınızı açıklayın

— DnrDevil