SSH Server Tidak Menanggapi Permintaan Koneksi


4

Saya mencoba mengatur server SSH pada mesin lokal saya menggunakan OpenSSH. Ketika saya mencoba SSH dari host jarak jauh ke server SSH lokal saya, server SSH tidak merespons dan permintaannya habis. Saya cukup yakin ada perbaikan yang sangat jelas untuk ini yang hanya saya abaikan.

Inilah yang terjadi ketika saya mencoba masuk SSH dari host jarak jauh:

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

Di mana robotsremote host saya, dan 99.3.26.94server SSH lokal saya.

SSH Sedang Berlari

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

Di mana arnoldserver SSH lokal saya.

Port Forwarding Diatur Di Router

Router rumah saya sudah diatur untuk meneruskan port 80 dan 22 ke server SSH saya. Menariknya, port 80 bekerja tanpa hambatan - langsung ke direktori web Apache. Port 22 - tidak begitu banyak.

NMap Mengatakan Itu Difilter

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

Di mana robotsremote host saya, dan 99.3.26.94server SSH lokal saya.

Ini Bukan IPTables (saya pikir)

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            

... Dan saya tidak memiliki firewall lain di tempat - ini adalah netianst Debian yang relatif segar.

Jadi, lalu: Apa lagi itu? Tampaknya memang semacam firewall-y untuk mengabaikan lalu lintas, tetapi jika itu bukan router, itu bukan iptables, dan itu bukan firewall lain di server SSH, ... apa lagi yang ada ??

EDIT: Output Server NetStat

Dari Server SSH:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd       

apakah Anda melihat port 22 terbuka ketika Anda menjalankan sudo netstat -ntluppada server ssh? Jika NMAP mengatakan itu disaring, maka port tidak dapat diakses. ISP Anda bahkan mungkin memblokir upaya ssh upstream. coba port lain (sesuatu di atas 1024), dan uji apakah port tersebut terlihat dengan canyouseeme.org setelah Anda mengatur port forwarding.
Frank Thomas

Terima kasih, @FrankThomas - port tampaknya terbuka melalui netstat(lihat sunting), tetapi menginstruksikan router untuk meneruskan lalu lintas ke port 22999 ke port SSH server 22 memberikan hasil yang sama mengecewakan - NMap mengatakan itu disaring.
kittykittybangbang

Apakah robot pada LAN berbeda dari Arnold?
Frank Thomas

Sebagai tes, lihat output netstat untuk apache apakah itu juga 0 ::: xx? Dan sebagai tes lain, Coba nmap ke port 83 (port di mana Anda tidak memiliki server dan tidak ada port forwarding, apakah Anda ditutup atau difilter ..) Dan sebagai tes lain, coba letakkan ssh server pada port 80 untuk melihat apakah nmap melihat itu, lihat apakah klien ssh melihatnya
barlop

Jawaban:


1

Jawaban-sendiri yang Sangat Mengecewakan

Setelah mengesampingkan masalah ini selama sehari dan kembali ke sana, saya merasa lega dan gelisah (lebih gelisah daripada lega) untuk menemukan bahwa semuanya, secara misterius, berfungsi dengan baik.

Jadi, Apa Masalahnya?

Tidak ada pengaturan yang diubah atau disesuaikan - tidak pada router, tidak pada server SSH, dan tidak pada mesin klien SSH. Ini cukup aman untuk mengatakan itu adalah router tidak menangani lalu lintas yang masuk dengan benar, terlepas dari pengaturan yang tepat. Mengingat bahwa perangkat lunak router rumah mungil tidak benar - benar dirancang untuk berurusan dengan port forwarding, butuh orang miskin beberapa saat untuk mengimplementasikan perubahan yang diperlukan.

Tapi Sudah Seperti 6 Jam !!

Ya bung, aku tahu. Saya menghabiskan sepanjang hari untuk mencari tahu apa yang salah - dan tidak pernah menemukannya karena tidak ada yang salah. Jelas, itu bisa memakan waktu 6 jam - mungkin lebih - untuk pengaturan router berlaku.

Jadi Bagaimana Saya Tahu Jika Ini Masalah Saya?

Alat bagus yang saya temui selama petualangan ini adalah tcpdump. Si kecil yang ramping ini mengendus lalu lintas untuk Anda, menawarkan wawasan berharga tentang apa yang sebenarnya terjadi. Selain itu, ia memiliki beberapa fitur pemfilteran super yang memungkinkan Anda mempersempit apa yang ingin Anda lihat. Sebagai contoh, perintah:

tcpdump -i wlan1 port 22 -n -Q inout

Menceritakan tcpdumpuntuk mencari lalu lintas melalui antarmuka wlan1 ( -i= 'antarmuka'), hanya melalui port 22, mengabaikan resolusi nama DNS ( -n= 'tidak ada nama resolusi'), dan kami ingin melihat kedua lalu lintas masuk dan keluar ( -Qmenerima in, outatau inout; inoutadalah default).

Dengan menjalankan perintah ini di server SSH Anda saat mencoba untuk terhubung melalui mesin jarak jauh, dengan cepat menjadi jelas di mana tepatnya masalahnya terletak. Ada, pada dasarnya, 3 kemungkinan:

  1. Jika Anda melihat lalu lintas masuk dari mesin jarak jauh, tetapi tidak ada lalu lintas keluar dari server lokal Anda, masalahnya ada pada server: mungkin ada aturan firewall yang perlu diubah, dll.
  2. Jika Anda melihat keduanya masuk dan keluar , tetapi mesin jarak jauh Anda tidak menerima respons, kemungkinan besar router: itu memungkinkan lalu lintas masuk, tetapi menjatuhkan paket keluar Anda.
  3. Jika tidak ada lalu lintas sama sekali , itu mungkin masalah router juga: SYNpaket mesin remote diabaikan dan dijatuhkan oleh router bahkan sebelum mereka mencapai server Anda.

Dan begitu Anda telah menemukan di mana masalahnya, perbaikan adalah (biasanya) sepele.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.