Secure Shell
Ssh समस्याओं को डीबग करना

निजी कुंजी स्वीकार नहीं की जाती है (OpenSSH क्लाइंट डिबग)

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

मान लें कि आप ssh (या अन्य OpenSSH क्लाइंट जैसे sftp या scp ) का उपयोग करके सर्वर example.com से जुड़ रहे हैं और आपकी निजी कुंजी सर्वर द्वारा स्वीकार नहीं की जाती है और सर्वर पासवर्ड मांगता है (या कनेक्शन को अस्वीकार करता है):

$ ssh example.com
[email protected]'s password: 

चलाने के लिए प्रयास करें ssh के साथ -vvv स्विच, जो बाहर सभी डिबग संदेश लिखने होंगे। यह बहुत सारी जानकारी होगी, लेकिन कुछ समय बाद, यह समझना बहुत आसान है:

$ ssh -vvv example.com

सबसे आम समस्या यह है कि कुंजी अपेक्षित स्थान पर नहीं है। आप लापता फ़ाइलों के बारे में शिकायत करने के लिए इसी तरह की लाइनों की उम्मीद कर सकते हैं। यह देखना कि आपकी फ़ाइल वास्तव में पढ़ी गई है, एक अच्छी शुरुआत है:

debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_dsa-cert type -1

हम प्रमाणीकरण भाग को जारी रख सकते हैं। कुंजी की पेशकश की जा सकती है, लेकिन सर्वर द्वारा खारिज कर दिया गया, क्योंकि सर्वर कॉन्फ़िगरेशन में समस्या है। लॉग कुछ इस तरह दिख सकता है:

debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: username@localhost
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

रेस्ट हाउस की पहचान बदल गई है!

ssh का उपयोग करने वाली सामान्य त्रुटि को त्रुटि की तरह देखना है

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:L5ri/Xdgpuals893ej1z5F1wlg1n2YNeBf/tsABX+QQ.
Please contact your system administrator.
Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/username/.ssh/known_hosts:12
RSA host key for *IP address* has changed and you have requested strict checking.
Host key verification failed.

इसका मतलब है कि आप पहले एक ही सर्वर से जुड़े थे और विभिन्न होस्ट कुंजी का उपयोग करके इसकी पहचान की गई थी। यदि आप जानते हैं कि आपने सर्वर कुंजियों को बदल दिया है, तो सर्वर को पुनः इंस्टॉल किया है या सर्वर व्यवस्थापक ने कुछ बदलावों की घोषणा की है, आमतौर पर पुरानी कुंजी को हटाना और ssh को अपना नया स्टोर करने देना ठीक है।

ssh-keygen का उपयोग करके पुरानी कुंजी को पारदर्शी रूप से हटाया जा सकता है:

ssh-keygen -R *IP address*

और अगला कनेक्शन आपको नए फिंगरप्रिंट को सत्यापित करने के लिए कहना चाहिए:

ssh192.168.0.128
The authenticity of host '192.168.0.128 (192.168.0.128)' can't be established.
ECDSA key fingerprint is SHA256:L5ri/Xdgpuals893ej1z5F1wlg1n2YNeBf/tsABX+QQ.
Are you sure you want to continue connecting (yes/no)? 

यदि आप उपरोक्त में से किसी के बारे में नहीं जानते हैं, तो सबसे अच्छा यह सुनिश्चित करने के लिए अपने सर्वर व्यवस्थापक से संपर्क करना है कि सब कुछ ठीक है। यदि नहीं, तो संभावित हमलावर आपकी प्रमाणीकरण जानकारी और सभी स्थानांतरित डेटा प्राप्त करने में सक्षम होगा!

कनेक्शन नहीं हो सका

यदि आपका क्लाइंट किसी दूरस्थ सर्वर होस्ट के लिए कनेक्शन अनुरोध भेजता है, तो "कनेक्शन अस्वीकृत" त्रुटि उत्पन्न होगी, और दूरस्थ होस्ट का कहना है कि यह अनुरोध को स्वीकार करने से इनकार करता है। "कनेक्शन अस्वीकृत" त्रुटि का अनिवार्य रूप से अर्थ है कि कंप्यूटर अनुरोधित आईपी पते और पोर्ट के कनेक्शन को स्वीकार नहीं कर रहा है।

"कनेक्शन अस्वीकृत" एक फ़ायरवॉल के कारण हो सकता है जो कनेक्शन अनुरोधों को रोक रहा है। एक फ़ायरवॉल जो एक विशेष समापन बिंदु पर कनेक्शन को ब्लॉक करने के लिए कॉन्फ़िगर किया गया है, कनेक्शन अनुरोधों को छोड़ने के लिए सेट किया जा सकता है - जिस स्थिति में ग्राहक को कभी भी प्रतिक्रिया नहीं मिलेगी और अंततः समय समाप्त हो जाएगा। या फ़ायरवॉल कनेक्शन कनेक्शन अनुरोधों को प्रतिक्रिया प्रतिक्रिया के साथ जवाब दे सकता है।

फायरवॉल से, SSH के मामले में, "कनेक्शन से इनकार" के कुछ संभावित कारण हैं:

• आप कनेक्ट करने के लिए गलत पोर्ट नंबर का उपयोग कर सकते हैं। SSH के लिए मानक पोर्ट संख्या 22 है, लेकिन कुछ लोग अनधिकृत पहुंच प्रयासों को रोकने के लिए एक अलग पोर्ट पर ssh सेवा चलाते हैं।

• आप गलत कंप्यूटर से कनेक्ट करने का प्रयास कर सकते हैं। आपने होस्टनाम या आईपी पते को गलत लिखा होगा। या कंप्यूटर डायनामिक रूप से असाइन किए गए पते का उपयोग कर रहा होगा जो बदल गया है।

• Ssh सर्वर प्रक्रिया नहीं चल सकती है:

  • यदि सिस्टम शुरू करने की प्रक्रिया में है तो यह अभी तक शुरू नहीं हुआ है।
  • यह अक्षम हो सकता है; उदाहरण के लिए जब सिस्टम एकल-उपयोगकर्ता मोड में है।
  • हो सकता है कि इसे गलत तरीके से अंजाम दिया गया हो, जिससे यह शुरू होने में विफल रहा हो।
  • कंप्यूटर में SSH सर्वर सेट नहीं हो सकता है। एमएस विंडोज सिस्टम में आमतौर पर एक एसएसएच सर्वर शामिल नहीं होता है। कुछ लिनक्स सिस्टम पर, SSH सर्वर एक वैकल्पिक घटक हो सकता है। ओएस एक्स में एक एसएसएच सर्वर शामिल है, लेकिन यह डिफ़ॉल्ट रूप से अक्षम है।

• SSH सर्वर प्रक्रिया उस विशिष्ट IP इंटरफ़ेस पर कनेक्शन के लिए नहीं सुन सकती है जिसे आप कनेक्ट करने का प्रयास कर रहे हैं। अधिकांश कंप्यूटरों में कम से कम दो आईपी इंटरफेस होते हैं, एक "लोकलहोस्ट" इंटरफेस और एक या अधिक नेटवर्क इंटरफेस। प्रत्येक सक्रिय इंटरफ़ेस में एक आईपी एड्रेस होगा जो इससे जुड़ा होगा। एक एसएसएच सर्वर आमतौर पर किसी भी आईपी इंटरफेस पर कनेक्शन स्वीकार करने के लिए कॉन्फ़िगर किया गया है। लेकिन इसे केवल विशेष इंटरफेस पर कनेक्शन स्वीकार करने के लिए कॉन्फ़िगर किया जा सकता है। उस स्थिति में, कंप्यूटर एक IP पते पर कनेक्शन से इंकार कर देगा जो SSH सर्वर नहीं सुन रहा है, भले ही कनेक्शन अनुरोध में सही पोर्ट हो।

• सर्वर एक ही पोर्ट के लिए कनेक्शन अनुरोधों का एक बैकलॉग हो सकता है। यह दुर्लभ और असामान्य है, लेकिन यदि होस्ट कनेक्शन कनेक्शन अनुरोध तेजी से प्राप्त कर रहा है, तो उन्हें नियंत्रित किया जा सकता है, मेजबान अंततः अन्य कनेक्शन अनुरोधों को अस्वीकार करना शुरू कर देगा।

ध्यान दें कि, एक तरफ फ़ायरवॉल, "कनेक्शन मना कर दिया" का अर्थ है कि आप दूरस्थ कंप्यूटर के साथ संचार कर रहे हैं - यह आपके कनेक्शन अनुरोध को स्वीकार नहीं कर रहा है।

कनेक्शन का समय समाप्त

"कनेक्शन टाइम आउट आउट" त्रुटि तब होती है जब दूरस्थ सिस्टम टीसीपी / आईपी कनेक्शन को खोलने के लिए क्लाइंट के प्रयास का जवाब नहीं देता है। सबसे आम कारणों में शामिल हैं:

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

कनेक्शन टाइमआउट के मूल कारण का निदान करना मुश्किल है।

ssh_exchange_identification: पढ़ें: सहकर्मी द्वारा कनेक्शन रीसेट

यह त्रुटि संदेश OpenSSH ssh क्लाइंट द्वारा निर्मित किया जा सकता है। इसका अर्थ है कि क्लाइंट और सर्वर के बीच टीसीपी कनेक्शन को स्वीकार किए जाने के तुरंत बाद सर्वर द्वारा असामान्य रूप से बंद कर दिया गया था। इस संदेश के सामान्य कारणों में शामिल हैं:

• SSH सर्वर प्रक्रिया खराबी है - उदाहरण के लिए, यह दुर्घटनाग्रस्त हो गई।
• क्लाइंट और सर्वर के बीच फ़ायरवॉल, राउटर या अन्य नेटवर्क डिवाइस, SSH कनेक्शन के साथ हस्तक्षेप कर रहा है।

त्रुटि संदेश में दिए गए वाक्यांश विशेष रूप से इंगित करते हैं कि क्या हुआ है:

ssh_exchange_identification: 1. SSH क्लाइंट SSH सर्वर से संबंध बनाने के बाद, SSH प्रोटोकॉल को शुरू करने के लिए पहला कदम सर्वर के लिए क्लाइंट के लिए अपना सॉफ्टवेयर संस्करण भेजता है। "Ssh_exchange_identification" वाली त्रुटि इंगित करती है कि त्रुटि टीसीपी कनेक्शन बनाने के तुरंत बाद हुई थी, जबकि क्लाइंट सर्वर से सॉफ़्टवेयर संस्करण की प्रतीक्षा कर रहा था।

कनेक्शन रीसेट: कनेक्शन रीसेट का मतलब है कि टीसीपी कनेक्शन "असामान्य रूप से बंद" था। आप इसे प्राप्त कर सकते हैं यदि सॉफ्टवेयर प्रक्रिया टीसीपी कनेक्शन क्रैश में से एक को पकड़े। टीसीपी कनेक्शन को ब्लॉक करने के साधन के रूप में कनेक्शन रीसेट का उपयोग करने के लिए नेटवर्क फायरवॉल को कॉन्फ़िगर किया जा सकता है।

सहकर्मी द्वारा इसका मतलब है कि टीसीपी कनेक्शन कनेक्शन के "दूसरे छोर" से बंद हो गया था। इस स्थिति में, "अन्य छोर" दूरस्थ SSH सर्वर है।

ध्यान दें कि यह त्रुटि किसी भी प्रकार की प्रमाणीकरण विफलता का संकेत नहीं देती है। सर्वर ने इसे स्वीकार करने के तुरंत बाद टीसीपी कनेक्शन को बंद कर दिया। क्लाइंट और सर्वर ने अभी तक किसी भी डेटा का आदान-प्रदान नहीं किया है। सर्वर ने अभी तक क्लाइंट को होस्ट कुंजी नहीं भेजी है, और क्लाइंट ने अभी तक सर्वर के साथ प्रमाणित करने की कोशिश नहीं की है।

ssh_exchange_identification: दूरस्थ होस्ट द्वारा बंद किया गया कनेक्शन

यह त्रुटि संदेश OpenSSH ssh क्लाइंट द्वारा निर्मित किया जा सकता है। इसका मतलब है कि क्लाइंट और सर्वर के बीच टीसीपी कनेक्शन स्वीकार किए जाने के तुरंत बाद सर्वर द्वारा बंद कर दिया गया था। यह संदेश आम तौर पर इंगित करता है कि SSH सर्वर को किसी कारण से क्लाइंट से कनेक्शन स्वीकार नहीं करने के लिए कॉन्फ़िगर किया गया है:

• क्लाइंट के आईपी पते से कनेक्शन को मना करने के लिए सर्वर को कॉन्फ़िगर किया जा सकता है।
• सर्वर सक्रिय SSH कनेक्शन की संख्या पर एक सीमा के साथ कॉन्फ़िगर किया जा सकता है।
• ग्राहक किसी ऐसी चीज से जुड़ा हो सकता है जो SSH सर्वर नहीं है।

त्रुटि संदेश में दिए गए वाक्यांश विशेष रूप से इंगित करते हैं कि क्या हुआ है:

ssh_exchange_identification: 1. SSH क्लाइंट SSH सर्वर से संबंध बनाने के बाद, SSH प्रोटोकॉल को शुरू करने के लिए पहला कदम सर्वर के लिए क्लाइंट के लिए अपना सॉफ्टवेयर संस्करण भेजता है। "Ssh_exchange_identification" वाली त्रुटि इंगित करती है कि त्रुटि TCP कनेक्शन बनाने के तुरंत बाद हुई, जबकि क्लाइंट सर्वर से सॉफ़्टवेयर संस्करण की प्रतीक्षा कर रहा था।

कनेक्शन बंद: इसका मतलब है कि टीसीपी कनेक्शन सामान्य तरीके से बंद हो गया था। यह इंगित करता है कि SSH सर्वर ने जानबूझकर कनेक्शन बंद कर दिया है। यह "कनेक्शन रीसेट" के विपरीत है, जो यह संकेत दे सकता है कि एसएसएच सर्वर दुर्घटनाग्रस्त हो गया या खराब हो गया।

दूरस्थ होस्ट द्वारा इसका मतलब है कि कनेक्शन के "दूसरे छोर" से टीसीपी कनेक्शन बंद था। इस स्थिति में, "अन्य छोर" दूरस्थ SSH सर्वर है।

ध्यान दें कि यह त्रुटि किसी भी प्रकार की प्रमाणीकरण विफलता का संकेत नहीं देती है। सर्वर ने इसे स्वीकार करने के तुरंत बाद टीसीपी कनेक्शन को बंद कर दिया। क्लाइंट और सर्वर ने अभी तक किसी भी डेटा का आदान-प्रदान नहीं किया है। सर्वर ने अभी तक क्लाइंट को होस्ट कुंजी नहीं भेजी है, और क्लाइंट ने अभी तक सर्वर के साथ प्रमाणित करने की कोशिश नहीं की है।