एसएसएच सर्वर कनेक्शन अनुरोध का जवाब नहीं


4

मैं ओपनएसएसएच का उपयोग करके अपने स्थानीय मशीन पर एक एसएसएच सर्वर स्थापित करने का प्रयास कर रहा हूं। जब मैं अपने स्थानीय 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 सर्वर है।

एसएसएच रनिंग है

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

कहा पे arnold मेरा स्थानीय SSH सर्वर है।

पोर्ट अग्रेषण राउटर पर सेट है

मुझे मेरा होम राऊटर अपने SSH सर्वर पर पोर्ट 80 और 22 को फॉरवर्ड करने के लिए मिला है। दिलचस्प है, पोर्ट 80 ने अड़चन के बिना काम किया - सीधे अपाचे वेब निर्देशिका में जाता है। पोर्ट 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            

... और मेरे पास कोई अन्य फायरवॉल नहीं है - यह अपेक्षाकृत ताजा डेबियन नेटस्टीन है।

तो फिर: यह और क्या हो सकता है? यह निश्चित रूप से यातायात को अनदेखा करने के लिए फ़ायरवॉल-वाई तरह की बात प्रतीत होती है, लेकिन अगर यह राउटर नहीं है, तो यह iptables नहीं है, और यह SSH सर्वर पर एक और फ़ायरवॉल नहीं है, ... और क्या है?

संपादित करें: नेटस्टैट सर्वर आउटपुट

SSH सर्वर से:

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

क्या आपको पोर्ट 22 खुला दिखाई देता है, जब आप चलाते हैं sudo netstat -ntlup ssh सर्वर पर? यदि NMAP ने कहा कि इसका फ़िल्टर किया गया है, तो पोर्ट दुर्गम है। आपका आईएसपी भी ssh कनेक्शन प्रयासों को अपस्ट्रीम ब्लॉक कर सकता है। एक अलग पोर्ट (1024 से ऊपर की चीज़) आज़माएँ, और देखें कि यह किसके साथ दिखाई दे रहा है canyouseeme.org आपके द्वारा पोर्ट फ़ॉरवर्डिंग सेट करने के बाद।
Frank Thomas

धन्यवाद, @FrankThomas - पोर्ट के माध्यम से खुला होना प्रतीत होता है netstat (एडिट देखें), लेकिन SSH सर्वर के पोर्ट 22 पर राउटर को 22999 पोर्ट करने के लिए आगे ट्रैफ़िक को निर्देश देना एक ही निराशाजनक परिणाम देता है - NMap का कहना है कि यह फ़िल्टर्ड है।
kittykittybangbang

क्या अर्नोल्ड की तुलना में एक अलग लैन पर रोबोट हैं?
Frank Thomas

एक परीक्षण के रूप में, अपाचे के लिए नेटस्टैट आउटपुट देखें यह भी 0 ::: xx है? और एक अन्य परीक्षण के रूप में, 83 के लिए नैम्प को आज़माएं (एक ऐसा पोर्ट जहां आपके पास कोई सर्वर नहीं है और कोई पोर्ट फ़ॉरवर्डिंग नहीं है, क्या आप बंद या फ़िल्टर किए गए हैं ..) और अभी तक एक अन्य परीक्षण के रूप में, ssh सर्वर को पोर्ट 80 पर डालने का प्रयास करें यदि nmap देखता है यह, देखें कि क्या ssh क्लाइंट इसे देखता है
barlop

जवाबों:


1

एक बहुत ही निराशाजनक स्व-उत्तर

इस समस्या को एक दिन के लिए अलग रख दिया और वापस आकर, मैं दोनों को राहत मिली और हैरान रह गई (राहत से ज्यादा परेशान) यह खोजने के लिए कि सब कुछ, रहस्यमय तरीके से, ठीक से काम कर रहा था।

तो, मुद्दा क्या था?

कोई सेटिंग परिवर्तित या समायोजित नहीं की गई - न कि राउटर पर, एसएसएच सर्वर पर नहीं, और एसएसएच क्लाइंट की मशीन पर नहीं। यह कहना काफी सुरक्षित है कि यह राउटर उचित सेटिंग्स के बावजूद, आने वाले ट्रैफ़िक को ठीक से नहीं संभाल रहा था। यह देखते हुए कि डंकी होम राउटर सॉफ्टवेयर नहीं है वास्तव में पोर्ट फ़ॉरवर्डिंग से निपटने के लिए डिज़ाइन किया गया है, इसमें आवश्यक बदलावों को लागू करने में गरीब आदमी को थोड़ी देर लगी।

लेकिन यह 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 पैकेटों को अनदेखा किया जा रहा है और राउटर द्वारा गिरा दिया जाता है इससे पहले कि वे आपके सर्वर तक पहुंचें।

और एक बार जब आप पता लगा लेते हैं कि समस्या कहाँ है, तो एक समाधान (आमतौर पर) तुच्छ है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.