pam सेवा (sshd) अधिकतम रिट्रीज़ को अनदेखा कर रही है

Question

मेरे पास vps है जिसे मैं एक वेबसर्वर को चलाने के लिए उपयोग करता हूं, यह वर्तमान में ubuntu सर्वर 12.04 चलाता है। कुछ हफ़्तों से मुझे अपने ssh कंसोल में बहुत सारी त्रुटियाँ मिलती रहती हैं।

2014 Apr 11 08:41:18 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:21 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:24 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:25 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:26 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3

क्या कोई मुझे बता सकता है कि इन त्रुटियों का क्या अर्थ है। या कम से कम मुझे बताएं कि इन त्रुटियों को कैसे अक्षम किया जाए। जब मैं ssh पर काम कर रहा होता हूं तो यह वास्तव में बहुत निराशाजनक होता है और ये त्रुटियां मेरी स्क्रीन पर पूरी तरह से पॉप अप होती रहती हैं।

Answer 1

PAMआपको बता रहा है कि यह "रिट्री = 3" के साथ कॉन्फ़िगर किया गया है और यह उसी सत्र के भीतर sshd से किसी भी आगे के अनुरोध को अनदेखा कर देगा। SSHहालाँकि यह तब तक कोशिश करता रहेगा जब तक कि यह MaxAuthTries सेटिंग को समाप्त नहीं कर देता (जो कि 6 तक चूक करता है)।

आपको अधिकतम इन दोनों (एसएसएच और पीएएम) को अधिकतम ऑर्टिकल रिट्रीज़ के लिए समान मूल्य पर सेट करना चाहिए।

अपडेट किया गया

इस व्यवहार को बदलने के लिए:

के लिए sshdआप संपादित /etc/ssh/sshd_configऔर सेट MaxAuthTries 3। सेटिंग को प्रभावी करने के लिए SSH सर्वर को पुनः आरंभ करें।

के लिए PAM, आपको /etc/pam.dनिर्देशिका में कॉन्फ़िगरेशन के लिए देखना होगा (मुझे लगता है कि यह common-passwordउबंटू में फ़ाइल है), आपको retry=मूल्य बदलना होगा ।

नोट: मैं इन अनुरोधों के कारण के बारे में पीटर हॉमेल के उत्तर की भी जांच करने का सुझाव दूंगा, क्योंकि यह संभव है कि आपका SSH क्रूरतापूर्ण हो।

Comments

धन्यवाद, समस्या MaxAuthTries 3ssh config में जोड़कर और फिर सर्वर को रिबूट करके तय की गई थी ।

— जेरोडव

Answer 2

जबकि अन्य उत्तर आपको प्राप्त त्रुटि संदेश को समाप्त करने में सही हैं, पर विचार करें कि यह त्रुटि संदेश सिर्फ एक अन्य अंतर्निहित समस्या का लक्षण हो सकता है।

आपको ये संदेश मिलते हैं क्योंकि आपके सिस्टम पर ssh के माध्यम से कई असफल लॉगिन प्रयास हैं। हो सकता है कि कोई व्यक्ति आपके बॉक्स में घुसने की कोशिश कर रहा हो (जब मुझे अपने सिस्टम पर समान संदेश मिले)। अपने var/log/auth.logशोध के लिए पढ़ें ...

यदि यह स्थिति है, तो आप '' असफल 2बान '' ( sudo apt-get install fail2banउबंटू पर) जैसे उपकरण को स्थापित करने पर जोर देते हैं। यह स्वचालित रूप से आपके सिस्टम की लॉग फ़ाइलों को पढ़ता है, कई असफल लॉगिन प्रयासों की खोज करता है और आईपीएल के माध्यम से एक विन्यास योग्य समय के लिए दुर्भावनापूर्ण क्लाइंट को ब्लॉक करता है ...

Comments

यह एक बहुत अच्छी टिप्पणी है, मैंने अपने उत्तर को नोट के साथ अपडेट किया है ताकि आप किसी ऐसे व्यक्ति के लिए भी उत्तर पढ़ सकें जो इस पार आ सकता है।

— फूप्स

Answer 3

ऐसा लगता है कि उपरोक्त विश्लेषण पूरी तरह से सही नहीं है। इसमें pam प्रमाणीकरण के लिए एक रिट्री = विकल्प नहीं लगता है (मुझे pam_cracklib के लिए एक मिला, लेकिन यह केवल "पासवर्ड" अनुभाग में पासवर्ड बदलने की चिंता करता है, "pam" अनुभाग में प्रमाणीकरण नहीं है)। इसके बजाय, pam_unix में 3. की ​​एक अधिकतम अधिकतम संख्या होती है। 3 पुन: प्रयास के बाद, pam_MAXRETRIES त्रुटि कोड को sshd को सूचित करता है।

sshd को वास्तव में इस मामले में प्रयास करना बंद कर देना चाहिए, भले ही उसके खुद के MaxAuthTries हों। यह नहीं है, जो मुझे लगता है कि एक बग है (जिसे मैंने अभी ओपनश के साथ रिपोर्ट किया है )।

जब तक वह बग ठीक नहीं हो जाता, तब तक ऐसा लगता है कि MaxAuthTries को सेट करना <= 3 इस संदेश को दिखाने से रोकने का एकमात्र तरीका है।

Comments

बग को संस्करण 7.3p1

— डेनिस नोल्टे

Answer 4

Ssh क्लाइंट एक या अधिक कुंजियों के साथ प्रमाणित करने का प्रयास कर सकता है। कोई भी कुंजी जो अधिकृत_की में सूचीबद्ध नहीं है, विफल हो जाएगी, sshd के रिट्रीज़ का एक उपभोग करना। ग्राहक हर ssh कुंजी को तब तक आजमाएगा जब तक कि कोई सफल न हो जाए या सभी विफल न हो जाए, इसलिए यह अच्छा है कि sshd आपको कई प्रयास करने देता है।

यदि कोई कुंजी नहीं मिलती है, तो sshd आपको पासवर्ड आज़माने की अनुमति दे सकता है। इनमें से प्रत्येक प्रयास sshd के स्वीकृत रिट्रीज़ में से एक का उपभोग करता है। लेकिन, यह PAM के स्वीकृत रिट्रीजों में से एक का भी उपभोग करता है।

तो, 6 ssh ऑक्टोरिअम ट्राइसेज़ और 3 pam ऑर्टिज़ ट्राइसेज़ का संयोजन एक अच्छी बात है: इसका मतलब है कि ssh 6 ऑर्टिकल टोटल (की या पासवर्ड) की अनुमति देगा, लेकिन केवल 3 पासवर्ड ट्राई करता है।

जैसा कि दूसरों ने कहा है, यदि आप अक्सर अपने लॉग में देखते हैं, तो कोई आपके सिस्टम में अपने तरीके से बल देने की कोशिश कर रहा है। IP पते से पैकेट को पूरी तरह से ब्लॉक करने के लिए विफलता 2ban का उपयोग करने पर विचार करें जिससे ये प्रयास उत्पन्न होते हैं।

Answer 5

डेबियन 6 से डेबियन 7 में अपग्रेड करने के बाद, मैं उसी परेशानी में भाग गया। अचानक ये sshd त्रुटियाँ मेरे कंसोल में आ गईं।

2014 Oct 15 13:50:12 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:17 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:18 vps456 PAM service(sshd) ignoring max retries; 6 > 3

मेरे मामले में, समस्या यह थी कि rsyslogडेबियन अपग्रेड के बाद अब स्थापित नहीं किया गया था।

Rsyslog स्थापित करने के बाद ये त्रुटियाँ मेरे कंसोल से गायब हो गईं: apt-get install rsyslog

Comments

यह केवल उन्हें कंसोल के बजाय दूसरी जगह दिखाई देता है। मेरा उत्तर अपग्रेड के बाद SSH / PAM मिसकॉन्फ़िगरेशन के कारण त्रुटि के कारण को ठीक करता है।

— फूप्स

Answer 6

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

क्या वे उपयोगकर्ता नामों की कोशिश करना शुरू कर सकते हैं जो लॉगिन कर सकते हैं, यह एक अलग बात होगी, लेकिन अगर किसी के पास अच्छे पासवर्ड हैं, तो मुझे कोई जोखिम नहीं दिखता है। लॉगिन पासवर्ड (एन्क्रिप्शन कुंजी के विपरीत) केवल इतनी तेजी से कोशिश की जा सकती है।

फेल 2 एबन जैसी किसी चीज का उपयोग करना अनावश्यक जटिलता लगता है जो कुछ भी नहीं खरीदता है (यदि आपके पास अच्छे पासवर्ड हैं) और जटिलता सुरक्षा के लिए खराब है। प्रयास थ्रॉटलिंग कुछ है कि sshd, को लागू करना चाहिए कुछ है कि कुछ ऐड-ऑन ... से किया जा सकेगा और sshd नहीं है करता है थ्रोटल प्रयास। अच्छा।

-kb, केंट जो केवल अच्छे पासवर्ड का उपयोग करता है, और विभिन्न साइटों के बीच कभी भी पुनर्नवीनीकरण नहीं करता है।

Comments

Ssh कीज़ का उपयोग करना और पासवर्ड को अक्षम करना सफल ब्रूट-फोर्स हमलों को रोकने में बेहतर है।

— HBruijn 15

हाँ, लेकिन तब समस्या आपके ssh कीज़ की सुरक्षा करने में बदल जाती है। वे कहां हैं? क्या वे एन्क्रिप्टेड हैं? कितना अच्छा एक कुंजी उन्हें बचाता है? यदि किसी पासवर्ड को X-कोशिश के वर्षों में क्रैक नहीं किया जा सकता है, तो उसे X-ट्राई करने के वर्षों में क्रैक नहीं किया जा सकता है, इसके लिए आपको "बेहतर" क्या चाहिए? मैं अपना पासवर्ड प्रबंधित करने में बहुत समय लगाता हूं, और मैं उन्हें टाइप कर सकता हूं, उनमें से कई मुझे याद हैं। लेकिन ssh कुंजी का एक गुच्छा? उन्हें रखने के लिए कुछ जगह सुरक्षित चाहिए।

— केंट बोर्ग

Brute-मजबूर पासवर्ड (आमतौर पर 20 वर्णों से कम लंबा और अक्सर बुरी तरह से चुना हुआ) SSH के माध्यम से पहुँच प्राप्त करने के लिए 1024 बिट निजी कुंजी (एक 128 वर्ण पासवर्ड के समतुल्य सरलीकृत) के लिए brute की तुलना में बहुत सरल है। चलो सेब के साथ सेब की तुलना करने के लिए छड़ी। - - जब तक आप एक पूर्ण बेवकूफ नहीं होते (उदाहरण के लिए आपके सार्वजनिक जीथब में अपनी निजी कुंजी संग्रहीत करना) तब तक आपकी निजी ssh कुंजी प्राप्त करना मुश्किल है क्योंकि इसे आपके कार्य केंद्र को छोड़ने की आवश्यकता नहीं है। एक बार आपकी निजी कुंजी के साथ छेड़छाड़ करने के बाद हम यादृच्छिक हमलों में नहीं रह जाते हैं, लेकिन लक्षित हमलों के दायरे में प्रवेश कर रहे हैं ...

— HBruijn

@ पता है कि आप पासवर्ड की रक्षा कर सकते हैं आप SSH चाबियाँ? इसके अलावा, आप कहते हैं कि फेल 2 एबन अनावश्यक है, लेकिन यह सुझाव देना जारी रखें कि एसएसएच को इस सुविधा को अपने आप में लागू करना चाहिए। इसके अलावा, यदि आप उन अनुरोधों को ब्लॉक नहीं करते हैं, जो आपके सिस्टम को बहुत आसान बना सकते हैं।

— फूप्स