SSH Bağlantı Hatası: Ana bilgisayara giden yol yok

Bu senaryoda üç makine vardır:

Masaüstü A: kullanici@1.23.xx
Dizüstü Bilgisayar A: kullanici@1.23.yy
Makine B: kullanici@192.168.zz

Tüm makinelerde Ubuntu 11.04 (Masaüstü A 64bit bir) ve hem openssh-server hem de openssh-istemcisine sahiptir.

Şimdi Masaüstü A'yı Dizüstü Bilgisayar A'ya bağlamaya çalıştığımda veya tersi tarafından ssh user@1.23.y.ybir hata alıyorum

port 22: No route to host

Her iki durumda da.

Her iki makineye de sahibim, şimdi arkadaşımın makinesinden aynı komutları uygularsam, yani Desktop B aracılığıyla, hem Laptop'uma hem de Desktop’a erişebiliyorum. Ancak Desktop B'ye Dizüstü bilgisayarımdan veya Desktop’tan erişmeye çalışırsam,

port 22: Connection timed out

Hatta ssh portunu değiştirmeyi bile denemedim. içinde ssh_configdosyanın ama hiçbir başarı.

Not : 'Laptop A' WiFi bağlantısını kullanırken, 'Makine A' Ethernet Bağlantısını kullanır ve 'Makine B' tamamen farklı bir ağdadır.

Dizüstü Bilgisayar A ve Masaüstü A -> Router / Nano_Rcvr bana ISS tarafından sağlandı. Böylece bir yönlendiriciye iki makina bağlanır ve aynı anda erişilebilir. iki makinede de ifconfig çıktısı: - Laptop

wlan0

Link encap:Ethernet  HWaddr X:X:X:X:00:bc  
inet addr:1.23.73.111  Bcast:1.23.95.255  Mask:255.255.224.0
inet6 addr: fe80::219:e3ff:fe04:bc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:108409 errors:0 dropped:0 overruns:0 frame:0
TX packets:82523 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:44974080 (44.9 MB)  TX bytes:22973031 (22.9 MB)

Masaüstü

eth0

Link encap:Ethernet  HWaddr X:X:X:X:c5:78  
inet addr:1.23.68.209  Bcast:1.23.95.255  Mask:255.255.224.0
inet6 addr: fe80::227:eff:fe04:c578/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:10380 errors:0 dropped:0 overruns:0 frame:0
TX packets:4509 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:1790366 (1.7 MB)  TX bytes:852877 (852.8 KB)
Interrupt:43 Base address:0x2000

— Nihar Sawant
kaynak

Bu, SSH ile ilgili bir sorun değil, ağ yapılandırmanızla ilgili bir sorun. Yanlış yere bakıyorsun. Ana makineye giden rota yok, makinenizin herhangi bir tür trafiğin diğer makineye nasıl yönlendirileceğini çözemediği anlamına gelir . Ağ yapılandırmasına tekrar bakın, ssh'yi denemeden ve düzeltmeden önce sıraya göre olduğundan emin olun.

— EightBitTony

Stackoverflow'ta aynı Q'yu yayınladım ve bana süper kullanıcı olarak koymamı söylediler. Bu sorunun nasıl çözüldüğünü biliyorsanız, cevabı arayabilmeniz için kaynakları bana verebilirsiniz.

— Nihar Sawant

Tamam, makine B farklı bir Ağda ama aynı yönlendiriciye bağlı mı? Tüm IPS’lerin harici değil dahili olduğunu tahmin ediyorum, bu makinelerin 1.23.xx olarak çalıştığı gerçek ağlar geçerli bir dahili aralık değil. Kullanmakta olduğunuz asıl adrese sahip olmanız yardımcı olacaktır. Ping sonuçları vb ...

— 0x7c0

MAC adresiniz (Macintosh değil Ethernet Ortam Erişim Denetleyicisi donanım adresi), kendiliğinden otomatik olarak yapılandırılmış IPv6 yerel bağlantı adresinize kodlanır ve herhangi bir MAC adresinin ilk yarısı, bakabileceğiniz Kurumsal Özgün Tanımlayıcı veya OUI adlı bir satıcı tanımlayıcısıdır. IEEE web sitesinde. Masaüstünüzün NIC'si Intel’dir veya bir Intel yonga seti kullanır.

— Spiff

Eğer bu halka açık bir kablosuz yönlendiriciyse (OFDM / MIMO’nun reklamını yaptıklarından beri ses çıkarırlar), intranetteki eşler arası bağlantıları engellemek için yapılandırılmış olabilir

— ernie

Yanıtlar:

-1

Telsizle ilgili bu tür kısmi bağlantı sorunları genellikle ARP'lerin güvenilir bir şekilde geçememelerine neden olan kırılmış çok noktaya yayın yönetimi ile sonuçlanır.

Bu Cevapta önerdiğim sorun giderme adımlarına bakın: WiFi Ağ, Macbook Pro ve Win XP için uygun, ancak Win Vista "Sınırlı Bağlantı"

— Spiff
kaynak

peki çoğu kişiyi anlayamıyorum;) WPA / WPA2 hariç. Bakın ISS, Tikona Digital Networks. Yani birileri WiFi kullanmak istiyorsa, Tikona yalnızca Windows için kullanılabilen bir WiFi Çevirici sağlar. Birkaç gün önce Ubuntu'dan WiFi Bağlantısının nasıl kullanılacağını öğrendim . Üzerinde de bir blog yazdım dewbot.posterous.com/… kontrol edin. Bağlantımı anlama konusunda sana yardımcı olabilir. Aksi halde WPA2'yi WEP olarak değiştirmeyi denedim, ancak çalışmıyor. Bağlantıyı bile kuramıyorum.

— Nihar Sawant,

Yani halka açık bir Wi-Fi ortak erişim noktası ağı mı kullanıyorsunuz? Veya ISS'niz Wi-Fi yönlendiricinizin ayarlarını değiştirmenize izin vermiyor mu? Cevabım, kendi Wi-Fi yönlendiricinizi yeniden yapılandırma yeteneğiniz olduğunu varsayıyordu.

— Spiff

@ Spiff MIMO kullanan kablosuz bir ISS bağlantısı gibi görünüyor, muhtemelen ABD’de Clearwire’ın sunduğu hizmete benziyor. Yönlendiricilerin eşler arası bağlantıları engellediğini tahmin ediyorum.

— ernie

Bu, başka bir Süper Kullanıcı cevabına yalnızca bağlantı içeren bir cevaptır .

— JakeGould

-1

Kötü bir hata mesajı. Bu ssh hataları, bir ağ sorunu olmadığına inanmanıza neden olabilir. Uzak makineye giden yol iyi olabilir ancak o zamanlar ssh'yi bloke eden iptables (ve bugün hala CentOS6.7’de)ssh: connect to host ec239dict port 22: No route to host

Diğer TCP trafiği makineye güvenilir bir şekilde geliyorsa, bu bir ağ yolu sorunu değildir. Ssh dışında, bağlantıyı test etmek için başka hangi servisleri denediniz? http? ping? Tracepath? Bir web sunucusu gayet iyi çalışır ancak ssh çalışmaz.

Aşağıdaki / etc / sysconfig / iptables dosyası bir CentOS6.7 (Aralık 2015) makinesinden alınmıştır ve bu makineye ssh bağlantısı denemesi sonucu ssh: connect to host ec239dict port 22: No route to host Güvenlik duvarı sorunu, gelen ssh bağlantılarına hiçbir zaman ulaşılmaması nedeniyle, taşınması gereken 12 numaralı hattır. 10. satırdaki REJECT öncesinde.

 1  # Firewall configuration written by system-config-firewall
 2  # Manual customization of this file is not recommended.
 3  *filter
 4  :INPUT ACCEPT [0:0]
 5  :FORWARD ACCEPT [0:0]
 6  :OUTPUT ACCEPT [0:0]
 7  -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 8  -A INPUT -p icmp -j ACCEPT
 9  -A INPUT -i lo -j ACCEPT
10  -A INPUT -j **REJECT** --reject-with icmp-host-prohibited
11  -A FORWARD -j **REJECT** --reject-with icmp-host-prohibited
12  -A INPUT -m state --state NEW -m tcp -p tcp -**-dport 22 -j ACCEPT**
13  COMMIT

İşin garibi, güvenlik duvarı portu açık ancak ssh arka plan programı çalışmıyorsa, hata o zaman ssh hata mesajları daha da kötüleşir
ssh: connect to host ec239dict port 22: Connection refused.
" Bağlantı reddedildi " kesin olarak bağlantı girişimini engelleyen bir güvenlik duvarı gibi geliyor, ancak aslında güvenlik duvarı açık ancak ssh arka plan programı kapalıyken hata mesajı. Yine, ssh hata mesajlarında bir hata var. Ssh arka plan programının çalıştığından emin olun:

netstat -tunap | grep 22
chkconfig --list | grep ssh
/etc/init.d/ssh? status

Şimdi, sizin durumunuzda, muhtemelen yol boyunca bir yerde yanlış yapılandırılmış bir donanım veya yazılım güvenlik duvarı var.

— rjt
kaynak

Bu bir cevap değil. Bu bir yorum. Size yararlı bir şey bulursanız, o zaman bu soruyu ya da cevabı oy vermelisiniz. Yorum yapmak istiyorsanız, yorum bırakmalısınız.

— JakeGould

Evet, CentOS ve Fedora'da sıkça karşılaştığım bir sorun olduğu için bu bir cevap. Ssh "ana bilgisayara giden yol yok" bildirdiğinde, bu bir ağ yönlendirme problemi değildi, fakat genellikle uzak ana bilgisayardaki ssh'yi reddeden yanlış yapılandırılmış bir iptables idi. @ Nihar-Siwant, iptables'larını geri bildirmiş olsa da, ona ssh'nin açılacağı limanın bu yazıdaki tüm reddetme sonrasında olduğunu göstermiş olabilirim . Forums.fedoraforum.org/showthread.php?t=254683 .

— saat

Hayır, bu bir cevap değil. Sözde cevabınız sadece yorum olarak gönderilmesi gereken - ve yorum yapmak için kesinlikle yeterli cevaba sahip olduğunuz - ve IPTables fikirleriniz / içgörüleriniz hakkında herhangi bir bilgi içermeyen bir soru dizisidir ve orijinal posterin belirtisi yoktur. makinelerinde çalışan IPTable'lar (ya da herhangi bir güvenlik duvarı) vardı.

— JakeGould

2011 yılında, Linux dağıtımlarının hemen hemen hepsinde varsayılan olarak iptables kullanılabilirdi. 'iptables -Ln | grep 22 'firewall ile bir ilgisi olabilir.

— saat

@JakeGould, "Bu ssh hataları, bir tane olmadığında bir ağ sorunu olduğuna inanmanıza yol açabilir" orijinal cevabın önde gelen cümlesiydi.

— 15'te