เซิร์ฟเวอร์ SSH ไม่ตอบการร้องขอการเชื่อมต่อ

ฉันกำลังพยายามตั้งค่าเซิร์ฟเวอร์ SSH บนเครื่องท้องถิ่นของฉันโดยใช้ OpenSSH เมื่อฉันพยายาม SSH จากรีโมตโฮสต์ไปยังเซิร์ฟเวอร์ SSH ในพื้นที่ของฉันเซิร์ฟเวอร์ SSH ไม่ตอบสนองและคำขอหมดเวลา ฉันค่อนข้างแน่ใจว่ามีการแก้ไขที่ชัดเจนมากสำหรับสิ่งนี้ที่ฉันมองเห็น

นี่คือสิ่งที่เกิดขึ้นเมื่อฉันพยายาม SSH จากโฮสต์ระยะไกล:

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

robotsโฮสต์ระยะไกลของฉันอยู่ที่ไหนและ99.3.26.94เป็นเซิร์ฟเวอร์ SSH ในพื้นที่ของฉัน

SSH กำลังทำงานอยู่

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

arnoldเซิร์ฟเวอร์ SSH ในพื้นที่ของฉันอยู่ที่ไหน

มีการตั้งค่าการส่งต่อพอร์ตบนเราเตอร์

ฉันมีเราเตอร์ที่บ้านของฉันตั้งค่าให้ส่งต่อพอร์ต 80 และ 22 ไปยังเซิร์ฟเวอร์ SSH ของฉัน ที่น่าสนใจคือพอร์ต 80 ทำงานได้โดยไม่ต้องติดขัด - ตรงไปที่สารบบเว็บ Apache พอร์ต 22 - ไม่มาก

NMap บอกว่ามันถูกกรอง

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

robotsโฮสต์ระยะไกลของฉันอยู่ที่ไหนและ99.3.26.94เป็นเซิร์ฟเวอร์ SSH ในพื้นที่ของฉัน

มันไม่ใช่ IPTables (ฉันคิดว่า)

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            

... และฉันไม่ได้มีไฟร์วอลล์อื่น ๆ ในสถานที่ - มันเป็นเดเบียน Netinst ที่ค่อนข้างใหม่

ถ้าเช่นนั้นแล้วจะมีอะไรอีก? ดูเหมือนว่ามันจะเป็นไฟร์วอลล์และไม่สนใจทราฟฟิก แต่ถ้าไม่ใช่เราเตอร์ก็ไม่ใช่ iptables และไม่ใช่ไฟร์วอลล์อีกตัวในเซิร์ฟเวอร์ SSH ... สิ่งอื่น ๆ ที่นั่นคืออะไร ??

แก้ไข: คำขอเชื่อมต่อจากข้อผิดพลาดเครือข่ายภายใน

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

การตอบคำถามด้วยตนเองที่น่าผิดหวังอย่างมาก

หลังจากที่วางปัญหานี้ไว้หนึ่งวันแล้วกลับมาฉันก็รู้สึกโล่งใจและยุ่งเหยิง (ตกอกตกใจมากกว่าโล่งใจ) เพื่อพบว่าทุกอย่างทำงานได้อย่างถูกต้องอย่างลึกลับ

ดังนั้นปัญหาคืออะไร

ไม่มีการเปลี่ยนแปลงหรือปรับการตั้งค่า - ไม่ได้อยู่ที่เราเตอร์ไม่ใช่ในเซิร์ฟเวอร์ SSH และไม่ได้อยู่ในเครื่องของลูกค้า SSH มันค่อนข้างปลอดภัยที่จะบอกว่ามันเป็นเราเตอร์ที่ไม่ได้จัดการปริมาณการใช้งานที่เข้ามาอย่างถูกต้องแม้จะมีการตั้งค่าที่เหมาะสม ระบุว่าซอฟแวร์เราเตอร์ Dinky ไม่ได้จริงๆออกแบบมาเพื่อจัดการกับการส่งต่อพอร์ตก็เอาคนที่ไม่ดีในขณะที่การดำเนินการเปลี่ยนแปลงที่จำเป็น

แต่มันก็เหมือน 6 ​​ชั่วโมง !!

ใช่เพื่อนฉันรู้ ฉันใช้เวลาตลอดทั้งวันเพื่อค้นหาว่ามีอะไรผิดปกติ - และไม่เคยพบมันเพราะไม่มีอะไรผิดปกติ เห็นได้ชัดว่าอาจใช้เวลา 6 ชั่วโมง - อาจมากกว่า - เพื่อให้การตั้งค่าเราเตอร์มีผล

ดังนั้นฉันจะรู้ได้อย่างไรว่านี่เป็นปัญหาของฉันหรือไม่

tcpdumpเครื่องมือที่ดีฉันมาข้ามในระหว่างการหลบหนีนี้อยู่ คนตัวเล็กน้อยคนนี้สูดกลิ่นการจราจรให้คุณโดยนำเสนอข้อมูลเชิงลึกที่มีค่าเกี่ยวกับสิ่งที่เกิดขึ้นจริง นอกจากนี้เขามีฟีเจอร์การกรองขั้นสูงที่ช่วยให้คุณสามารถ จำกัด สิ่งที่คุณต้องการดู / เพื่อให้แคบลง ตัวอย่างเช่นคำสั่ง:

tcpdump -i wlan1 port 22 -n -Q inout

บอกtcpdumpจะมองหาการจราจรผ่านทางอินเตอร์เฟซ wlan1 ( -i'อินเตอร์เฟซ' =) เพียงผ่านพอร์ต 22 ไม่สนใจแก้ปัญหา DNS ชื่อ ( -n= 'ไม่มีการแก้ปัญหาชื่อ') และเราต้องการที่จะเห็นการจราจรทั้งขาเข้าและขาออก ( -Qยอมรับin, outหรือinout; inoutเป็นค่าเริ่มต้น)

ด้วยการรันคำสั่งนี้บนเซิร์ฟเวอร์ SSH ของคุณในขณะที่พยายามเชื่อมต่อผ่านเครื่องระยะไกลมันจะกลายเป็นที่ชัดเจนอย่างรวดเร็วในกรณีที่ปัญหาอยู่ มีความเป็นไปได้ 3 ประการ:

1. หากคุณเห็นทราฟฟิกที่เข้ามาจากเครื่องระยะไกล แต่ไม่มีทราฟฟิกขาออกจากเซิร์ฟเวอร์ภายในเครื่องของคุณปัญหาอยู่ที่เซิร์ฟเวอร์: อาจมีกฎไฟร์วอลล์ที่จำเป็นต้องเปลี่ยนแปลงเป็นต้น
2. หากคุณเห็นทั้งขาเข้าและขาออกแต่เครื่องระยะไกลของคุณไม่ได้รับการตอบสนองก็เป็นไปได้ว่าเราเตอร์ส่วนใหญ่: อนุญาตให้มีการรับส่งข้อมูลขาเข้า แต่ทิ้งแพ็กเก็ตขาออกของคุณ
3. หากไม่มีทราฟฟิกเลยนั่นอาจเป็นปัญหาของเราเตอร์เช่นกัน: เราเตอร์SYNจะมองข้ามแพ็กเก็ตของเครื่องระยะไกลและทิ้งไว้ก่อนที่จะถึงเซิร์ฟเวอร์ของคุณ

และเมื่อคุณค้นพบว่าปัญหาอยู่ที่ใดการแก้ไขนั้นเป็นเรื่องเล็กน้อย

ฉันกำลังใช้ Mint (Ubuntu)

ฉันทำทุกอย่าง ... กุญแจสาธารณะในรูปแบบที่ถูกต้องใน authorized_keys, chmodding, chowning, เริ่ม ssh และ sshd ฯลฯ ตามที่ได้รับการบันทึกไว้ทั่ว

สำหรับฉันมันคือไฟร์วอลล์ ufw การขาดการตอบสนองใด ๆ เลยทำให้ฉันได้รับสิ่งนี้ แต่ฉันก็สามารถปิงได้อย่างไม่มีปัญหาทั้งสองทางบน LAN

ฉันทดสอบโดย:

sudo ufw service stop

... และมันทำงานได้อย่างสมบูรณ์เช่นฉันได้รับการตอบกลับจากการโทร ssh

ดังนั้นเริ่มต้น ufw ใหม่อีกครั้ง:

sudo ufw service start

... และเพิ่มกฎ:

sudo ufw allow openssh

ทำงานได้ดีในขณะนี้

หากคุณเช่นฉันเปิดใช้งาน UFW (บน Linux, Ubuntu ในกรณีของฉัน) ลองสิ่งนี้:

sudo ufw enable OpenSSH

สิ่งนี้จะทำให้ OpenSSH ในไฟร์วอลล์

สำหรับคนอื่น ๆ :

ฉันต้องใช้ตัวเลือก -P ใน tcpdump แทน -Q

tcpdump -i wlan1 port 22 -n -P inout

ไฟร์วอลล์ส่วนใหญ่เป็นผู้ร้าย ทำและservice iptables stopservice ip6tables stop

หากบริการหยุดไม่ทำงานให้ทำ iptable flush

iptables --flush.

ถ้า VM ของมันทำเช่นเดียวกันในโฮสต์ด้วย