SSH Sunucusu bağlantı isteklerini yanıtlamıyor

OpenSSH kullanarak yerel makinemde bir SSH sunucusu kurmaya çalışıyorum. Uzak bir ana bilgisayardan yerel SSH sunucuma SSH denemeye çalıştığımda, SSH sunucusu yanıt vermiyor ve istek zaman aşımına uğruyor. Eminim ki bu göz ardı ettiğim çok açık bir düzeltme var.

Uzak bir ana bilgisayardan SSH kullanmaya çalıştığımda şöyle olur:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

robotsUzak ana bilgisayarım ve 99.3.26.94yerel SSH sunucum nerede .

SSH Çalışıyor

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

arnoldYerel SSH sunucum nerede .

Yönlendirici Üzerinde Bağlantı Noktası İletme Ayarlandı

Ev yönlendiricimi 80 ve 22 numaralı bağlantı noktalarını SSH sunucuma iletecek şekilde ayarladım. İlginç bir şekilde, bağlantı noktası 80 sorunsuz bir şekilde çalıştı - doğrudan Apache web dizinine gidiyor. Port 22 - çok fazla değil.

NMap Filtrelendiğini Söyledi

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

robotsUzak ana bilgisayarım ve 99.3.26.94yerel SSH sunucum nerede .

IPTable Değil (Bence)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

... Ve başka güvenlik duvarım yok - nispeten taze bir Debian ağı.

Öyleyse, başka ne olabilir ki? Kesinlikle trafiği görmezden gelmek için bir güvenlik duvarı-y gibi bir şey gibi görünüyor, ancak yönlendirici değilse, iptables değil ve SSH sunucusunda başka bir güvenlik duvarı değil, ... başka ne var?

EDIT: Dahili Ağ Hatası Bağlantı İsteği

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

Çok Hayal Kırıcı Bir Kendine Cevap

Bu problemi bir günlüğüne bir kenara bırakıp geri döndükten sonra, her şeyin gizemli bir şekilde düzgün çalıştığını bulmak için hem rahatladım hem de rahatsız oldum (rahatladım).

Peki Sorun Neydi?

Hiçbir ayar değiştirilmedi veya ayarlanmadı - yönlendiricide değil, SSH sunucusunda değil, SSH istemcisinin makinesinde değil. Doğru ayarlara rağmen, yönlendiricinin gelen trafiği düzgün bir şekilde işlemediğini söylemek oldukça güvenlidir. Dinky ev yönlendirici yazılımının gerçekten port yönlendirme ile başa çıkmak için tasarlanmadığı göz önüne alındığında , zavallı adama gerekli değişiklikleri uygulamak biraz zaman aldı.

Ama 6 Saat Oldu !!

Evet ahbap, biliyorum. Ben neyin yanlış olduğunu anlamaya çalışırken bütün gün geçirdi - ve orada çünkü hiç bulamadık değildi yanlış bir şey. Açıkçası, yönlendirici ayarlarının geçerli olması 6 saat - muhtemelen daha fazla - sürebilir.

Peki bu benim sorunum olup olmadığını nasıl bilebilirim?

Bu kaçış sırasında karşılaştığım şık bir araç tcpdump. Bu yalın küçük adam, gerçekte olup bitenler hakkında değerli bilgiler sunan trafiği kokluyor. Ayrıca, tam olarak bakmak istediğiniz şeyi daraltmanıza izin veren bazı süper filtreleme özellikleri var. Örneğin, komut:

tcpdump -i wlan1 port 22 -n -Q inout

Söyler tcpdumpwlan1 arayüzüne (aracılığıyla trafiğe aramaya -i= 'arayüz'), DNS ad çözümlemesi (görmezden sadece port 22 üzerinden -n= 'no ad çözümlemesi') ve biz de gelen ve giden trafiği (görmek istiyorum -Qkabul in, outya inout; inoutvarsayılan değerdir).

Uzak bir makine üzerinden bağlanmaya çalışırken SSH sunucunuzda bu komutu çalıştırarak sorunun tam olarak nerede yattığı hemen anlaşılır. Esasen 3 olasılık vardır:

1. Uzak makineden gelen trafiği görüyorsanız , ancak yerel sunucunuzdan giden trafik görmüyorsanız , sorun sunucuda yatmaktadır: muhtemelen değiştirilmesi gereken bir güvenlik duvarı kuralı vardır.
2. Hem gelen hem de giden görüyorsanız , ancak uzak makineniz yanıt almıyorsa, büyük olasılıkla yönlendirici: gelen trafiğe izin veriyor, ancak giden paketlerinizi bırakıyor.
3. Hiç trafik yoksa , bu muhtemelen bir yönlendirici sorunudur: uzak makinenin SYNpaketleri sunucunuza ulaşmadan yönlendirici tarafından yok sayılır ve düşürülür.

Ve sorunun nerede olduğunu keşfettikten sonra, bir düzeltme (genellikle) önemsizdir.

Mint (Ubuntu) kullanıyorum.

Her şeyi yaptım ... yetkili anahtar anahtarları, chmodding, chowning, ssh ve sshd vb. Yeniden başlatma doğru formatta.

Benim için ufw güvenlik duvarıydı. Herhangi bir ssh yanıtı eksikliği bana bu uçlu, ama ben bir LAN her iki yönde de sorun ping olabilir.

Tarafından test ettim:

sudo ufw service stop

... ve mükemmel çalıştı, yani bir ssh çağrısından yanıt aldım.

Yani, ufw'yi tekrar başlatın:

sudo ufw service start

... ve kuralı ekleyin:

sudo ufw allow openssh

Şimdi hepsi iyi çalışıyor.

Benim gibi UFW'yi (Linux'ta, benim durumumda Ubuntu) etkinleştirdiyseniz, şunu deneyin:

sudo ufw enable OpenSSH

Bu, güvenlik duvarında OpenSSH'ye izin verir.

Sadece diğerleri için:

-Q yerine tcpdump -P seçeneğini kullanmak zorunda kaldı

tcpdump -i wlan1 port 22 -n -P inout

Çoğu zaman güvenlik duvarı bir suçludur. Yap service iptables stopve service ip6tables stop.

Durdurma hizmeti çalışmazsa, iptable sifonu yapın.

iptables --flush.

Eğer onun bir VM sonra da aynı şeyi yapmak