"उपयोगकर्ता रूट के लिए बहुत अधिक प्रमाणीकरण विफलता" से कैसे उबरें

Question

मैंने पोटीन टर्मिनल का उपयोग करके उपयोगकर्ता रूट @ होस्ट के लिए SSH-Connecton स्थापित करने के कई प्रयास किए हैं। ऐसा करते समय मैंने कई बार गलत क्रेडेंशियल्स निर्दिष्ट किए और उसके बाद मैंने उन्हें सही तरीके से निर्दिष्ट किया है, और फिर क्रेडेंशियल्स स्वीकार किए जाने के बाद ssh सत्र ब्रेक के साथ

"सर्वर ने अनपेक्षित रूप से नेटवर्क संपर्क को बंद कर दिया है"।

यह त्रुटि पोटीन टर्मिनल द्वारा बताई गई है। स्थानीय कंसोल से रूट @ लोकलहोस्ट को ssh करने की कोशिश करते समय - यह ठीक काम करता है। यह भी ठीक काम करता है जब मैं दूसरे होस्ट से दूसरे होस्ट को होस्ट करता हूं। इसलिए नेटवर्क कनेक्टिविटी के मुद्दे दोषी नहीं हैं। एकमात्र त्रुटि जो मैं सोच रहा हूं, वह है: "उपयोगकर्ता रूट के लिए बहुत अधिक प्रमाणीकरण विफलताएं" हालांकि पोटीन ने एक अलग त्रुटि की सूचना दी।

सवाल यह है: इस त्रुटि की स्थिति से कैसे उबरें और फिर से पोटीन लॉगिन करें? Sshd को पुनः आरंभ करने से मदद नहीं मिलती है

Comments

superuser.com/questions/187779/…

— Ciro Santilli 改造 .com/ est est est at

अपने ssh एजेंट को निष्क्रिय करना सुनिश्चित करें (जैसे विंडोज पर पेजेंट) यदि आपको कोई Too many Authentication Failuresत्रुटि मिलती है, तो इससे पहले कि आप लॉगिन कर सकें ।

— महन

Answer 1

क्या आप सुनिश्चित हैं कि ssh को रूट लॉगिन की अनुमति है?

Sshd_config की जाँच करें और सत्यापित करें कि रूट लॉगिन की अनुमति है। यदि सेटिंग बदल जाती है तो sshd को फिर से शुरू करना होगा।

Answer 2

"उपयोगकर्ता रूट के लिए बहुत सारे प्रमाणीकरण विफलताएं" का अर्थ है कि आपका SSH सर्वर की MaxAuthTries सीमा पार हो गई थी । ऐसा इसलिए होता है कि आपका ग्राहक /home/USER/.ssh/ में संग्रहीत सभी संभावित कुंजियों को प्रमाणित करने का प्रयास कर रहा है।

इस स्थिति को इन तरीकों से हल किया जा सकता है:

1. ssh -i / path / to / id_rsa root @ host
2. /Home/USER/.ssh/config में होस्ट / आइडेंटिटीफाइल जोड़ी निर्दिष्ट करें ।
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. SSH सर्वर पर / etc / ssh / sshd_config (अनुशंसित नहीं) पर MaxAuthTries मान बढ़ाएँ ।

Comments

यह वास्तव में स्वीकृत उत्तर होना चाहिए!

— बेंजामिन

एक स्वीकृत उत्तर होने के लिए, उत्तर वास्तव में प्रश्न में वर्णित सॉफ़्टवेयर के बारे में होना चाहिए। =)

— rakslice

सीमा से अधिक होने का दूसरा कारण आपका ssh एजेंट हो सकता है। ssh -vvदो कुंजी (ssh- एजेंट द्वारा आपूर्ति) के कई संस्करणों की कोशिश की जा रही है। मुझे लगता है कि यह मेरे कारण बार-बार रिबूट करने और समाप्त होने वाली कुछ कुंजियों को बदलने के कारण है; जाहिरा तौर पर ssh- एजेंट नए लोगों के साथ पुरानी चाबियों को अधिलेखित नहीं करता है। मैंने ssh-agent को मार दिया और समस्या दूर हो गई।

— मार्क

वृद्धि से क्या कमी होगी MaxAuthTries? मुझे संदेह है कि बहुत सारी अलग-अलग चाबियों का प्रयास करके कई हमले किए गए हैं। इसके अलावा अगर कोई हमलावर ऐसा करना चाहता है, तो वे कनेक्शन को बंद कर सकते हैं और हर बार एक नई सीमा खोल सकते हैं। वे वैसे भी एक कुंजी को मजबूर करने में सफल नहीं होने जा रहे हैं।

— कास्परड सेप

@ मर्क धन्यवाद! Ssh-agent को पुनः आरंभ करके मेरे लिए इसे ठीक कर दिया!

— विंडपोय

Answer 3

यदि आपको निम्न SSH त्रुटि मिलती है:

$ Received disconnect from host: 2: Too many authentication failures for root

ऐसा हो सकता है यदि आपके पास (मेरी प्रणाली पर डिफ़ॉल्ट) पाँच या अधिक डीएसए / आरएसए पहचान फ़ाइलें आपकी .sshनिर्देशिका में संग्रहीत हैं । इस स्थिति में यदि -iविकल्प कमांड लाइन पर निर्दिष्ट नहीं है, तो ssh क्लाइंट पहले प्रत्येक पहचान (निजी कुंजी) का उपयोग करके लॉगिन करने का प्रयास करेगा और पासवर्ड प्रमाणीकरण के लिए अगला संकेत देगा। हालांकि, sshd पांच खराब लॉगिन प्रयासों (फिर से डिफ़ॉल्ट भिन्न हो सकता है) के बाद कनेक्शन को छोड़ देता है।

इसलिए यदि आपके पास अपनी .ssh निर्देशिका में कई निजी कुंजियाँ हैं, तो आप वैकल्पिक तर्क Public Key Authenticationका उपयोग करके कमांड लाइन पर अक्षम कर सकते हैं -o।

उदाहरण के लिए:

$ ssh -o PubkeyAuthentication=no root@host

Comments

आपको बहुत - बहुत धन्यवाद! यहाँ उबंटू सर्वर का उपयोग करना, जिसे मैं केवल SSH द्वारा ही एक्सेस कर सकता हूँ। मैंने इंटरनेट पर एक ट्यूटोरियल के बाद आँख बंद करके "MaxAuthTries 1" सेट किया था।

— आंद्रे फिगयेरिडो

तुमने तो मेरी जान बचा ली! मुख्य उत्तर का उपयोग नहीं कर रहे हैं ताकि अन्य उत्तर मदद नहीं कर रहे हैं। यह यह soooo आसानी से हल !!

— जॉर्ज ग्रीन

यह वह जगह है इस सवाल का जवाब

— smac89

मैंने पासवर्ड प्रमाणीकरण का उपयोग करके बस अपनी कुंजी फिर से कॉपी की, और अब यह हर बार काम करता है। मेरी .sshनिर्देशिका में कई कुंजियाँ हैं , मुझे नहीं लगता कि यह वह राशि है जो मायने रखती है।

— केन शार्प

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

— स्प्रिंटरफ्रेक

Answer 4

दूरस्थ मशीन पर खुला / etc / sshd_config और मूल्य बदलें

MaxAuthTries 30

यह विशिष्ट समस्या है जब आपने कई कुंजियाँ स्थापित की हैं या कई कनेक्शन खोले हैं। सर्वर प्रत्येक चरण को चरणबद्ध तरीके से जाँचता है और यदि MaxAuthTries 3 पर सेटअप है तो पहले 3`rd के बाद आपको डिस्कनेक्ट कर देगा। विशिष्ट ssh सुरक्षा।

मेरा सुझाव है कि आप समस्या का विश्लेषण करने के लिए रिमोट मशीन के कनेक्शन के दौरान वर्बोज़ मोड का उपयोग करें।

ssh -v -p port_number user @ servername

इस मंच पर अधिकांश कवियों की तरह अनुमान लगाना गलत और समय की बर्बादी है। पहले समस्या का विश्लेषण करने की कोशिश करें, फिर से जानकारी इकट्ठा करें और फिर पूछें।

मज़े करो।

Comments

मेरे विशिष्ट मामले में, समस्या यह थी कि मुझे एजेंट फॉरवर्डिंग के साथ लॉग इन किया गया था, एक स्क्रिप्ट को चलाने की कोशिश कर रहा था जो इसका उपयोग स्वयं एसएसएच पहचान थी। जब मैंने इसे एजेंट फॉरवर्डिंग के साथ चलाया, तो इससे पहले कि यह अपना था, यह बहुत अधिक पहचान थी। इसलिए मैंने एजेंट पर्यावरण को गिराने के लिए स्क्रिप्ट की स्थापना की और इसे मंजूरी दे दी। मैं MaxAuthTries भी बढ़ा सकता था, लेकिन मुझे इस मामले में ज़रूरत नहीं थी।

— सीन रिफ़्शिनडर

धन्यवाद। -vमेरे ssh क्लाइंट को कई कुंजियों का उपयोग करने की कोशिश करते हुए दिखाया (मेरे पास अभी कुछ है)। मैंने उन्हें एजेंट से साफ कियाssh-add -D

— joeytwiddle

Answer 5

यह बुरा अभ्यास है। बस रिमोट बॉक्स पर एक नियमित उपयोगकर्ता है और इसका उपयोग करके ssh से कनेक्ट करें, फिर su / sudo का उपयोग करके रूट एक्सेस प्राप्त करें।

Answer 6

मेरे लिए यह समस्या उस होस्ट के लिए नीचे ssh_config बनाकर हल की गई थी जिससे मैं जुड़ रहा था।

(~ / .Ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

समस्या इसलिए हुई क्योंकि मेरे पास अपने ~/.sshफ़ोल्डर में बहुत सी ssh कुंजियाँ हैं , जैसे 16 या। और उन दोनों के बिना IdentityFileऔर IdentitiesOnlyconfig में निर्देशों, मेरी मशीन जाहिरा तौर पर की में से सभी में कोशिश कर रहा था ~/.sshऔर सही IdentityFile प्रयास करने से पहले प्रयासों की अधिकतम संख्या तक पहुंच गया।

Answer 7

मैं आपको सलाह दूंगा, जैसा कि Anon ऊपर पोस्ट किया गया है, ssh एक्सेस प्राप्त करने के लिए किसी अन्य उपयोगकर्ता का उपयोग करें और फिर एक्सेस प्राप्त करने के लिए suकमांड का rootउपयोग करें।

सर्वर पर फ़ाइल PermitRootLoginमें सक्षम करना भी सुनिश्चित करें /etc/ssh/sshd_config।

Answer 8

मुझे भी इसी मुद्दे का सामना करना पड़ा। यह आसानी से हो सकता है यदि आप पेजेंट का उपयोग कर रहे हैं और इसमें बड़ी संख्या में कुंजी भरी हुई है , क्योंकि ये सर्वर एक सार्वजनिक कुंजी के प्रत्येक प्रस्ताव को प्रमाणीकरण प्रयास के रूप में गिनते हैं।

(यह सलाह यहां से ली गई है ।)

Comments

हम लिंक के बारे में बहुत उत्सुक नहीं हैं, केवल इधर-उधर उत्तर देते हैं, जैसे कि लिंक सड़ता है, और उत्तर बेकार हो जाता है। लिंक को हर तरह से रखें, लेकिन यदि आप एक या दो पैराग्राफ में समाधान को संक्षेप में प्रस्तुत कर सकते हैं, तो आपके पास अपने आप में एक उत्तर देने योग्य उत्तर हो सकता है।

— मदहैटर

मुझे आशा है कि आप मेरे बाद के संपादन को माफ कर देंगे; अब (मुझे आशा है) यह स्पष्ट करता है कि आप जिस सलाह का उल्लेख करते हैं वह वह सलाह है जो आप देते हैं, लेकिन फिर भी मूल स्रोत को श्रेय देता है। अपने उत्तर को बेहतर बनाने के लिए कड़ी मेहनत करने के लिए मुझसे +1!

— मध्याह्न

मुझे पुट्टी में "बहुत अधिक प्रमाणीकरण विफलताओं" समस्या थी। PageAnt से अन्य सभी कुंजी निकालने के बाद, अंत में सफलतापूर्वक लॉग इन किया।

— klor

Answer 9

मैंने निम्न कमांड चलाकर अपने सिस्टम में इस समस्या को ठीक किया:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

फिर रिमोट मशीन में ssh की कोशिश कर रहा है

Answer 10

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

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Answer 11

मुझे इसी तरह की समस्या ने काट लिया था। हालाँकि असली कारण यह था कि मेरे पास ForwardAgent yesपाइप के साथ मशीन की कॉन्फिग फाइल थी। मैं मशीन A से मशीन B से मशीन C से कनेक्ट कर रहा था।

त्रुटि संदेश को B -> C से ssh प्रयास में दिखाया गया था, लेकिन यह A के द्वारा अग्रेषित सक्रिय होने के कारण हुआ था। इसलिए C को पहले A से सभी चाबियों को परोसा गया था, और उसके बाद ही B से प्राप्त की गई।

यह अचानक दिखाई दिया जब मैंने ए के लिए एक और कुंजी जोड़ी।

Answer 12

मैंने अपने मैक पर इस मुद्दे को तय किया:

1. "sudo passwd रूट" के साथ रूट पासवर्ड सेट करना
2. ssh config फाइल को "नैनो / etc / ssh_config" के साथ संपादित करना और सहेजना
3. RSAAuthentication को "हाँ" के बजाय "नहीं" में बदलना।

Answer 13

ठीक है, तो मेरे मामले में यह बहुत अजीब था, यहाँ यह जाता है ...

मेरे पास SSH कुंजी के साथ एक मानक आवारा वीएम है और मैं इसे पोटीन का उपयोग करके एसएसएच कर सकता हूं। PHPStorm में तैनाती के दौरान इसे प्राप्त करने की कोशिश करते समय मुझे too many authentication failuresत्रुटि मिलती है। इसलिए मैंने MaxAuthTriesअपने में वृद्धि की sshd_configऔर फिर मैं Auth failedगलती से मारा और फिर Auth cancel।

अब, मैं यह नहीं जानता कि मैंने यह कोशिश क्यों की ... लेकिन मैंने PHPStorm में तैनाती विंडो में अपने SSH कुंजी पथ के अंत में डॉट जोड़ा। तो यह इस तरह था:

C:\Users\Deadpool\\.ssh\chimichanga

और अब यह इस तरह है:

C:\Users\Deadpool\\.ssh\chimichanga.

और यह काम करता है ... मेरे ".ssh" फ़ोल्डर में मेरे पास अधिक फाइलें हैं:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

मुझे यकीन नहीं है कि fcuking डॉट क्या करता है, लेकिन .ppkफ़ाइल का उपयोग करना काम नहीं करता है, इसलिए मुझे लगता है कि यह जादू की तरह है;) ओह, और मैं उस "डॉट ट्रिक" के बाद मैक्सऑथ्रीट्स से छुटकारा पा सकता हूं।

Answer 14

अन्य उत्तर आपको जड़ के रूप में, और उस के सुरक्षा निहितार्थ से जुड़ने का सबसे अच्छा तरीका बताते हैं, लेकिन आपका स्पष्ट प्रश्न था

इस त्रुटि की स्थिति से कैसे उबरें और पोटीन को फिर से लॉगिन करें?

आप अंतिम समय पर उल्लेख करते हैं कि आप कनेक्ट हो गए हैं फिर दूरस्थ सर्वर ने कनेक्शन को गिरा दिया।

मुझे क्या लगता है कि आप पा सकते हैं कि रिमोट सर्वर फेल 2बन (*) चल रहा है और यह आपके सफल लॉगिन के बाद आपके आईपी को "जेल" कर रहा है। आप फिर से लॉग इन करने का प्रयास करके इसका परीक्षण कर सकते हैं, और आपको लॉगिन प्रॉम्प्ट भी नहीं मिलेगा।

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

(*) fail2ban एक सुपर आसान डेमॉन है जो समय-समय पर विभिन्न लॉग फ़ाइलों की जांच कर सकता है और सर्वर को "गायब" बनाने के लिए फ़ायरवॉल नियमों को समायोजित कर सकता है जब यह क्लाइंट से संभावित दुर्भावनापूर्ण व्यवहार का पता लगाता है। डेबियन पर, यह एक विशेष आईपी से कई विफल ssh लॉगिन का पता लगाने के लिए कॉन्फ़िगर किए गए बॉक्स से बाहर आता है, और 3 के बाद (मुझे लगता है) यह उस आईपी से सभी पैकेट छोड़ देगा। उन पटकथा, जानवर बल के हमलों को रोकने के लिए शानदार ढंग से काम करता है।

Answer 15

जैसा कि @sufferer ने एक अन्य उत्तर में उल्लेख किया है, कुछ लिनक्स डिस्ट्रो में एसएसएच जैसी बाहरी दृश्यमान सेवाओं पर क्रूर बल के हमलों से बचाने के लिए मॉनिटर शामिल हैं, उदाहरण के लिए DenyHostsया fail2ban। ये मॉनिटर विफल प्रयासों की तलाश में लॉग फाइलों की जांच करते हैं और आईपी पते को ब्लॉक करने के लिए फिल्टर जोड़ते हैं जिनमें बहुत अधिक विफलताएं हैं (संख्या कॉन्फ़िगर करने योग्य और sshd कॉन्फ़िगरेशन से स्वतंत्र है)।

यदि आपके डिस्ट्रो में शामिल हैं fail2ban, जो iptables फ़ायरवॉल में नियमों को जोड़ने वाली सेवाओं की रक्षा करते हैं, तो आप जांच सकते हैं कि कमांड का उपयोग करके कौन सी सेवाएं या "जेल" की निगरानी की जाती है:

sudo fail2ban-client status

SSH सेवा के लिए जेल sshd है, इसलिए यह जांचने के लिए कि क्या आपके द्वारा उपयोग किए जाने वाले प्रतिबंधित IP हैं:

sudo fail2ban-client status sshd

और कुछ आईपी abcd unban करने के लिए:

sudo fail2ban-client set sshd unbanip a.b.c.d

यदि आपके पास है DenyHosts, तो प्रतिबंधित सूची फ़ाइल /etc/hosts.deny में है; आप इस फ़ाइल को सीधे रूट के रूप में संपादित कर सकते हैं। कुछ IP abcd स्थायी पहुँच प्रदान करने के लिए, आप sshd:a.b.c.dफ़ाइल /etc/hosts.allow में लाइन जोड़ सकते हैं ।

हमेशा की तरह, manकमांड आपका दोस्त है:

man fail2ban
man hosts.deny

अन्य समान उपयोगिताओं का अस्तित्व होना चाहिए, लेकिन मैंने केवल इन का उपयोग किया है।

ध्यान दें कि sshd कॉन्फ़िगरेशन में अनुमत रिट्रीज़ की संख्या में वृद्धि करने से आईपी प्रतिबंधित नहीं होता है, केवल उसी कनेक्शन में अधिक विफलताओं की अनुमति देता है। यदि अनुमत संख्या पार हो गई है, तो उपयोगकर्ता / हमलावर बस n गुना अधिक प्रयास करने के लिए फिर से जुड़ता है।

अन्य सेवाओं में प्रतिबंध सूची एकीकृत थी (जैसा कि वीएनसी सर्वर को फिर से शुरू करने के बारे में रजनीश ठाकुर के उत्तर में दिखाया गया है)।

Answer 16

मैंने अपने Ubuntu 16.04 सर्वर पर दो सरल चरणों द्वारा इस समस्या को हल किया -

पहले मेरे vnc सर्वर को बंद करो या इस प्रक्रिया को मार डालो -

vncserver -kill :1

और फिर इसे फिर से शुरू करें -

vncserver

इसके बाद इसे दूरस्थ डेस्कटॉप क्लाइंट से कनेक्ट करें -

192.0.2.99:5901

किया हुआ !!

Comments

इसका सवाल से कोई लेना-देना नहीं है।

— केन शार्प

Answer 17

कृपया नीचे दिए गए चरणों का पालन करें

1. बैक अप / आदि / ssh / sshd_config
2. Sshd_config में MaxAuthTries का मान बढ़ाएं
3. stoprc -s sshd; startrc -s sshd

और उपरोक्त परिवर्तनों के बाद फिर से जांच करें

Answer 18

मेरे पास एक ही मुद्दा था जहां मुझे "एसएसएवर डिस्कनेक्टेड संदेश टाइप 2 (प्रोटोकॉल त्रुटि) भेजा गया: बहुत सारे प्रमाणीकरण विफल रहे"

मैंने अपनी सभी ssh (.ppk कुंजियाँ) निकालकर इस समस्या को हल किया और फिर AD इंटरग्रेटेड सर्वर में लॉग इन किया।

Comments

यह उत्तर उपयोगी नहीं है, और .ppk फ़ाइलों को हटाने की अनुशंसा करना खतरनाक है। कृपया लोगों को, यदि आपको लगता है कि आपको .ppk फ़ाइलों को हटाने की आवश्यकता है (और मैं एक अच्छा कारण नहीं सोच सकता हूँ जो आप चाहते हैं), उन्हें किसी और चीज़ का नाम दें, उन्हें हटाएं नहीं। उनमें आपकी चाबियां होती हैं, जिनकी आपको शायद जरूरत होती है।

— कानून २