SSH - सॉफ़्टवेयर ने एकल लॉगिन के लिए कनेक्शन गर्भपात का कारण बना

Question

मैं यहाँ एक पूर्ण पृष्ठभूमि दूंगा, यह सुनिश्चित नहीं होगा कि इसमें से कुछ कितना प्रासंगिक होगा लेकिन यह चोट नहीं पहुँचा सकता है ...

तो मेरे पास एक VM चल रहा था ubuntu सर्वर 13.10 जो मैंने हाल ही में 14.04 LTS अपग्रेड किया था।

अपग्रेड के बाद, यह दिखाई दिया कि मैं मशीन में नहीं जा पा रहा था। स्थानीय कंसोल के माध्यम से लॉगिन ठीक था, और ssh आउट ठीक था।

कुछ फिडलिंग के बाद, मुझे पता चला कि ssh केवल एक विशेष उपयोगकर्ता नाम के लिए विफल रहता है। एक दूसरे उपयोगकर्ता नाम का उपयोग करना सफल साबित हुआ।

मैंने कई ssh क्लाइंट की कोशिश की है और हर बार मुझे उस एक उपयोगकर्ता के लिए एक ही त्रुटि मिलती है:

Software caused connection abort.

अब, मैं जो इकट्ठा करता हूं, वह विंडोज से ही आता है, इसलिए मैं आपसे पूछता हूं कि इसके क्या संभावित कारण हो सकते हैं?

PuTTY लॉग सार्वजनिक कुंजी प्रमाणीकरण को सफल दिखाता है, और फिर अचानक बिना किसी स्पष्ट कारण के, डिस्कनेक्ट हो रहा है:

Event Log: Access granted
Outgoing packet #0x8, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
...
Outgoing raw data
...
Event Log: Network error: Software caused connection abort

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

अद्यतन करें

इसलिए, चिराग 64 के सुझाव के बाद, ssh 127.0.0.1ठीक जोड़ता है, हालांकि ssh <baduser>@127.0.0.1एक ही त्रुटि संदेश के साथ विफल रहता है।

मैंने समूह सदस्यता, प्रमाणीकरण और उपयोगकर्ता शेल की जाँच की है, जो सभी कार्यशील उपयोगकर्ता के साथ मेल खाते हैं।

su baduser मुझे उस उपयोगकर्ता को बदलने की अनुमति देता है, और आउटगोइंग ssh कनेक्शन बनाता है, हालांकि वर्तमान उपयोगकर्ता विफल रहता है का उपयोग कर लूपबैक के लिए एक ssh कनेक्शन।

यह सिर्फ किसी एक कारण या किसी अन्य के लिए उस उपयोगकर्ता के लिए आने वाले कनेक्शन प्रतीत होता है।

Comments

एक ही सिस्टम से सिस्टम में sshing की कोशिश करें। शश कुछ ऐसा है 127.0.0.1।

— चिराग भाटिया

ssh 127.0.0.1अच्छे उपयोगकर्ता से ठीक जुड़ता है, ssh <baduser>@127.0.0.1"असफल लिखें: टूटा हुआ पाइप"

— लौटाता है

अपनी /etc/ssh/sshd_configफ़ाइल में, इन सेटिंग्स को आज़माएँ:ClientAliveInterval 120 ServerAliveInterval 120 TCPKeepAlive no

— चिराग भाटिया - चिराग़ ६४

ServerAliveInterval 120रेखा की वजह से सर्वर नए कनेक्शन मना करने के लिए। उस को हटाना और छोड़ना ClientAliveInterval 120और TCPKeepAlive noकोई बदलाव नहीं करना मुझे डर है।

— अहह्भिस्टो

Answer 1

"सॉफ्टवेयर के कारण कनेक्शन गर्भपात होता है" इसका मतलब है कि सर्वर कनेक्शन को छोड़ रहा है, इसलिए यह संभवत: कोई फर्क नहीं पड़ता कि आप किस क्लाइंट प्रोग्राम का उपयोग कर रहे हैं।

जांच करने वाली पहली चीज उबंटू सर्वर पर उपयोगकर्ता के लिए फाइल सिस्टम अनुमति है। उपयोगकर्ता के होम निर्देशिका, उपयोगकर्ता .shsh निर्देशिका और .ssh निर्देशिका के भीतर फ़ाइलों के लिए अनुमतियों की जाँच करें। काम कर रहे उपयोगकर्ता के लिए उनकी समान अनुमतियों से तुलना करें। OpenSSH सर्वर इन अनुमतियों के बारे में बहुत उपयुक्त है, और कुछ विन्यास में यह किसी उपयोगकर्ता को कनेक्ट नहीं होने देगा यदि यह संभव है कि किसी और ने उपयोगकर्ता की फ़ाइलों को संशोधित किया हो।

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

/path/to/sshd -ddd -p 10022

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

यदि आप अभी भी समस्या का पता नहीं लगा सकते हैं, तो आप इसके sshdमाध्यम से चलने की कोशिश कर सकते हैं strace:

strace -f /path/to/sshd -ddd -p 10022

stracesshdप्रोग्राम द्वारा की जा रही सिस्टम कॉल को प्रिंट करेगा । sshdकनेक्शन ड्रॉप करने से पहले अंतिम बार कॉल की गई कुछ सिस्टम कॉल आपको यह अंदाजा दे सकती हैं कि यह उस समय क्या जाँच कर रही थी।

Comments

इसलिए डिबग इंस्टेंस चलाना उपयोगी साबित हुआ। मुझे मिल debug3: safely_chroot: checking '/' debug3: safely_chroot: checking '/home/' debug3: safely_chroot: checking '/home/<baduser>' bad ownership or modes for chroot directory "/home/<baduser>"रहा है मैं त्रुटि को अनुमति या स्वामित्व में नहीं रख सकता। उपयोगकर्ता / समूह दोनों उपयोगकर्ता नाम हैं, और अनुमति सेट 0755 है।

— अहह्भिस्टो

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

— अहहभिस्तो

Answer 2

मेरे पास समान मुद्दे हैं और हर बार, यह .bashrc के साथ किसी भी समस्या को देखने की कोशिश करता है।

संपादित करें: उस विशिष्ट उपयोगकर्ता के लिए (/home//.bashrc)