SSH Too Many Authentication Failures कैसे ठीक करें

"Too many authentication failures" का क्या अर्थ है

"Too many authentication failures" का अर्थ है कि आपके SSH client ने सर्वर को उसकी क्षमता से अधिक keys प्रदान कीं, और सर्वर ने आपकी सही key के प्रयास से पहले ही connection बंद कर दिया। यह लगभग हमेशा एक client-side समस्या होती है। key आपकी disk पर मौजूद है, सर्वर के authorized_keys में भी वह दर्ज है, लेकिन ये तथ्य किसी काम के नहीं हैं क्योंकि connection समय से पहले ही समाप्त हो गया।

इसकी प्रक्रिया इस प्रकार है। ssh-agent में वे सभी private keys होती हैं जिन्हें आपने load किया है। आपका client उन keys को एक-एक करके सर्वर को प्रदान करता है, क्योंकि उसे यह पता नहीं होता कि account कौन सी key स्वीकार करेगा। सर्वर हर उस key को अस्वीकार कर देता है जो authorized_keys में नहीं है, और वह प्रत्येक अस्वीकृति को एक विफल authentication प्रयास के रूप में गिनता है। sshd_config में स्थित MaxAuthTries यह सीमित करता है कि एक connection में कितनी विफलताएं स्वीकार्य हैं। डिफ़ॉल्ट सीमा 6 है। यदि आपके agent में दस keys हैं और सही key आठवें स्थान पर है, तो सर्वर उस तक पहुँचने से पहले ही connection काट देगा।

इसलिए इसका समाधान यह है कि client केवल एक ही key प्रदान करे: वह जो सही है।

सर्वर क्या गिनता है, और MaxAuthTries कहाँ काम आता है

Public key authentication एक अनुमान लगाने वाले खेल की तरह शुरू होता है। Client एक public key भेजता है और पूछता है कि क्या सर्वर उससे बने signature को स्वीकार करेगा। सर्वर हाँ या ना में जवाब देता है। एक "ना" का मतलब है एक विफल प्रयास, बिल्कुल गलत password की तरह।

sshd_config(5) manual page इस सीमा का वर्णन इस प्रकार करता है: "प्रति connection अनुमत authentication प्रयासों की अधिकतम संख्या निर्दिष्ट करता है। जब विफलताओं की संख्या इस मान की आधी तक पहुँच जाती है, तो अतिरिक्त विफलताओं को log किया जाता है। डिफ़ॉल्ट मान 6 है।"

Password टाइप करने वाले व्यक्ति के लिए छह प्रयास पर्याप्त हैं। दस keys रखने वाले agent के लिए यह बहुत कम है। जैसे ही विफलता की संख्या सीमा पार करती है, sshd connection काट देता है और system log में इस तरह की एक पंक्ति लिखता है:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

आपका client उसी घटना का दूसरा हिस्सा print करता है:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

यह SSH permission denied (publickey) error से अलग प्रकार की विफलता है। उस स्थिति में, सर्वर ने आपके द्वारा दी गई हर चीज़ को देखा और किसी को भी स्वीकार नहीं किया। यहाँ सर्वर ने देखना बंद कर दिया है। एक को दूसरे जैसा समझने के कारण ही लोग अपनी दोपहर उस key को फिर से copy करने में बर्बाद कर देते हैं जो पहले से ही सही थी।

आपके सहकर्मी के लैपटॉप से वही key क्यों काम करती है

Key या सर्वर में कोई अंतर नहीं है। उनके agent में दो keys हैं और आपके agent में बारह। उनके लिए जो offer सबसे पहले पहुँचता है, वह आपके लिए नौवें स्थान पर आता है, और तब तक connection समाप्त हो चुका होता है।

यह संख्या चुपचाप बढ़ती रहती है। AddKeysToAgent yes में ~/.ssh/config आपके द्वारा उपयोग की जाने वाली प्रत्येक key को agent में जोड़ देता है और उसे वहीं छोड़ देता है। डेस्कटॉप keyring agents, जैसे Linux पर GNOME Keyring या macOS पर login keychain, login के समय बिना पूछे keys load कर लेते हैं। एक साल के दौरान एक client key, एक git host key और एक lab box key जोड़ें, और एक दिन ऐसा सर्वर जो हमेशा काम करता था, आपको access देने से मना करने लगेगा। सर्वर पर कुछ भी नहीं बदला। आपका agent भर गया है।

ssh -v के साथ offers कैसे देखें

विफल हो रहे connection को -v के साथ चलाएं और trace को पढ़ें।

ssh -v deploy@203.0.113.10

दो प्रकार की line मायने रखती हैं। Will attempt key: उन identities की सूची देता है जिन्हें client ने इकट्ठा किया है, उसी क्रम में जिसमें वह उनका उपयोग करेगा। Offering public key: हर उस key के लिए एक बार दिखाई देती है जिसे वास्तव में server को भेजा गया है।

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

आपके paths, key types और fingerprints अलग होंगे। आप disconnect होने से पहले Offering public key: lines की संख्या गिन रहे हैं। यदि offers आगे बढ़ जाती हैं और session आपकी इच्छित key के दिखाई दिए बिना ही समाप्त हो जाता है, तो समस्या का निदान स्पष्ट है। line के अंत में agent शब्द का अर्थ है कि वह identity ssh-agent से आई है। explicit शब्द का अर्थ है कि यह किसी IdentityFile line से या command line पर -i से आई है।

फिर agent से पूछें कि उसके पास क्या है:

ssh-add -l

output की प्रत्येक line एक loaded key है। यदि यह The agent has no identities. print करता है, तो agent आपकी समस्या नहीं है, और आपको इसके बजाय ~/.ssh/config में IdentityFile lines को देखना चाहिए। यदि यह Could not open a connection to your authentication agent. print करता है, तो कोई agent नहीं चल रहा है, और offers आपकी default key files से आ रही हैं।

Fix 1: IdentitiesOnly के साथ प्रति host एक key

IdentitiesOnly yes ssh को यह निर्देश देता है कि वह केवल आपके द्वारा कॉन्फ़िगर की गई identities का ही उपयोग करे और agent द्वारा दी जाने वाली अतिरिक्त identities को अनदेखा करे। इसे IdentityFile लाइन के साथ जोड़ें, जिससे client केवल एक ही key का प्रस्ताव भेजेगा।

Host vps
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_vps
  IdentitiesOnly yes

इसे ~/.ssh/config में save करें, फिर chmod 600 ~/.ssh/config चलाएँ। यदि file group-writable या world-writable है, तो ssh इसे चलाने से मना कर देगा और Bad owner or permissions on /home/you/.ssh/config error देगा। अब ssh vps केवल एक key का प्रस्ताव देगा, और ssh -v vps में ठीक एक Offering public key: लाइन दिखाई देनी चाहिए।

यहाँ दो विवरण लोगों को हैरान करते हैं।

• IdentitiesOnly yes का अकेले उपयोग करने का अर्थ "एक key" नहीं होता है। डिफ़ॉल्ट identity files भी कॉन्फ़िगर की गई identities में गिनी जाती हैं, इसलिए ssh अभी भी ~/.ssh/id_ed25519, ~/.ssh/id_rsa और अन्य डिफ़ॉल्ट files को आज़माता है। आपको IdentityFile लाइन की भी आवश्यकता होती है।
• signing का काम अभी भी agent ही करता है। IdentitiesOnly यह नियंत्रित करता है कि कौन सी keys प्रस्तावित की जाएंगी, यह नहीं कि उन्हें sign कौन करेगा। यदि IdentityFile द्वारा निर्दिष्ट private key agent में loaded है, तो agent signature तैयार कर देगा और आपसे कभी passphrase नहीं माँगा जाएगा। आप IdentityFile को संबंधित .pub file की ओर भी इंगित कर सकते हैं, जो तब किया जाता है जब private key केवल agent में या hardware token पर मौजूद हो।

~/.ssh/config में एक गलती इस सुधार को चुपचाप विफल कर देती है। अधिकांश keywords पहला मिला मान (value) स्वीकार करते हैं, इसीलिए विशिष्ट Host blocks को Host * के ऊपर रखा जाता है। IdentityFile इस नियम का पालन नहीं करता है। manual कहता है: "कॉन्फ़िगरेशन फ़ाइलों में कई identity files निर्दिष्ट की जा सकती हैं; ये सभी identities क्रम में आज़माई जाएंगी।" Host * के अंतर्गत कोई भी IdentityFile आपकी प्रति-host वाली सेटिंग में जुड़ जाता है, न कि उसे बदलता है। इसलिए, यदि कोई global लाइन भूलवश रह जाए, तो वह हर connection में एक अतिरिक्त key का प्रस्ताव जोड़ देगी।

यदि आप एक global सुरक्षा कवच चाहते हैं, तो केवल flag को file के अंत में सेट करें:

Host *
  IdentitiesOnly yes

इसके बाद हर host के लिए अपनी IdentityFile की आवश्यकता होगी, जो कि आप चाहते भी हैं। प्रति सर्वर एक key रखने से भविष्य में किसी एक मशीन का access रद्द करना संभव हो जाता है, बिना सब कुछ दोबारा जारी किए। यह आदत जल्दी डालना फायदेमंद है: देखें मशीन के अनुसार SSH keys को कैसे manage करें।

Fix 2: agent को prune करें या restart करें

यदि आप अभी config को edit नहीं कर सकते हैं, तो agent को खाली करें और केवल वही load करें जिसकी आपको आवश्यकता है।

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

यदि ssh-add -D के तुरंत बाद connection काम करता है, तो समस्या agent के कारण थी। इसे सुधार के बजाय एक परीक्षण के रूप में देखें। एक desktop keyring agent आपके अगले login पर अपनी keys को reload करता है, इसलिए समस्या कल फिर से आ जाएगी। ~/.ssh/config में एक IdentitiesOnly line reboot के बाद भी बनी रहती है। एक खाली agent ऐसा नहीं करता है।

आप किसी key को lifetime भी दे सकते हैं ताकि agent उसे आपके लिए हटा दे:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

key को add किए जाने के 1800 seconds बाद उसे हटा दिया जाता है। agent को restart करना भी काम करता है, और आप इसे कैसे करते हैं यह इस पर निर्भर करता है कि इसे किसने शुरू किया था। आपके द्वारा launch किया गया ssh-agent, ssh-agent -k के साथ रुक जाता है। यदि आप इसे अपने द्वारा लिखे गए systemd user unit से run करते हैं, तो उस unit को systemctl --user restart <unit> के साथ restart करें। एक keyring agent आपके desktop session के साथ restart होता है।

उपाय 3: ऐसे सर्वर के लिए एक बार चलने वाली कमांड जिसे आप केवल एक बार एक्सेस करते हैं

ऐसे होस्ट के लिए जिसे आप अपनी कॉन्फ़िगरेशन में नहीं जोड़ेंगे, कमांड लाइन पर ही समान सेटिंग्स का उपयोग करें:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

-i का अकेले उपयोग करना सबसे आम गलत उपाय है। -i पहचान की सूची में एक की (key) जोड़ता है। यह सूची से एजेंट की अन्य कीज़ को नहीं हटाता है, इसलिए अन्य सभी कीज़ आपकी की से पहले भेजी जाती हैं और कनेक्शन सीमा पर पहुँचते ही समाप्त हो जाता है। ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 को IdentitiesOnly के बिना चलाएं और आप देखेंगे कि एजेंट की कीज़ सबसे पहले ऑफर की जा रही हैं। -i के साथ -o IdentitiesOnly=yes का होना आवश्यक है।

एक कनेक्शन के लिए एजेंट को पूरी तरह से हटाने हेतु:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

इसके बाद ssh डिस्क से प्राइवेट की को पढ़ता है और यदि उसमें कोई पासफ़्रेज़ है, तो उसे पूछता है।

ssh पर आधारित टूल्स भी समान विकल्प स्वीकार करते हैं:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

दूसरे हॉप पर त्रुटि क्यों दिखाई देती है

ForwardAgent yes के साथ, एजेंट सॉकेट उस सर्वर पर उपलब्ध कराया जाता है जिससे आप कनेक्ट करते हैं। उस सर्वर पर चलाया गया ssh कमांड फॉरवर्ड किए गए सॉकेट के माध्यम से आपकी सभी कुंजियों के साथ आपके स्थानीय एजेंट का उपयोग करता है। यही कारण है कि जंप होस्ट से अंतिम सर्वर तक के हॉप पर त्रुटि दिखाई दे सकती है, जबकि पहला हॉप ठीक काम कर रहा था। मध्य मशीन पर echo $SSH_AUTH_SOCK चलाएं: सॉकेट पथ का मतलब है कि एक फॉरवर्ड किया गया एजेंट पहुंच में है, और खाली आउटपुट का मतलब है कि कोई एजेंट नहीं है।

एजेंट फॉरवर्डिंग की एक दूसरी कीमत भी है। उस मध्य मशीन पर root एक्सेस वाला कोई भी व्यक्ति आपके सत्र के खुले रहने तक आपकी ओर से प्रमाणित करने के लिए आपके एजेंट का उपयोग कर सकता है। ProxyJump दोनों समस्याओं से बचाता है:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump जंप होस्ट के माध्यम से एक कनेक्शन खोलता है और आपकी अपनी मशीन से अंतिम सर्वर पर प्रमाणित करता है, इसलिए आपका स्थानीय ~/.ssh/config हर हॉप पर लागू होता है, जिसमें IdentitiesOnly भी शामिल है। ForwardAgent को बंद करना VPS पर SSH को सुरक्षित करने का एक मानक चरण है।

क्या आपको सर्वर पर MaxAuthTries को बढ़ाना चाहिए?

आमतौर पर नहीं। पहले वर्तमान मान (value) की जाँच करें:

sudo sshd -T | grep -i maxauthtries

sshd -T प्रभावी कॉन्फ़िगरेशन को प्रिंट करता है, जिसमें डिफ़ॉल्ट मान भी शामिल होते हैं, इसलिए यह वास्तविक मान दिखाता है, भले ही sshd_config में इसके बारे में कुछ न लिखा हो। यदि आप Match ब्लॉक का उपयोग करते हैं तो -C user=deploy,host=example.com,addr=203.0.113.10 जोड़ें, क्योंकि इनका मूल्यांकन प्रति कनेक्शन किया जाता है और अन्यथा इन्हें छोड़ दिया जाता है।

सीमा बढ़ाने से काम तो चलता है, इस सीमित अर्थ में कि एक बड़ी संख्या गलत व्यवहार करने वाले क्लाइंट को अधिक अवसर देती है:

MaxAuthTries 20

फ़ाइल को वैलिडेट करें और सर्विस को रीलोड करें, और ऐसा करते समय एक दूसरा सेशन खुला रखें:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

यदि systemctl is-enabled ssh.socket, Ubuntu 24.04 पर enabled रिपोर्ट करता है, तो sshd सॉकेट-एक्टिवेटेड है: प्रत्येक कनेक्शन के लिए एक नया प्रोसेस शुरू होता है और sshd_config को फिर से पढ़ता है, इसलिए नए कनेक्शन अपने आप बदलाव को लागू कर लेते हैं।

अब देखें कि उस बदलाव ने क्या किया। क्लाइंट ऐसी कुंजियाँ (keys) भेज रहा है जिन्हें यह सर्वर कभी स्वीकार नहीं करेगा। सीमा बढ़ाने का मतलब है कि सर्वर प्रत्येक कनेक्शन के लिए और इंटरनेट पर मौजूद हर पासवर्ड गेसर के लिए छह के बजाय बीस अस्वीकृत प्रयासों को प्रोसेस करेगा। प्रत्येक प्रयास के लिए सर्वर को authorized_keys में लुकअप करना पड़ता है। आपका अपना लॉगिन धीमा ही रहेगा, क्योंकि सही कुंजी अभी भी लाइन में सबसे अंत में है। अपने एजेंट में तेरहवीं कुंजी जोड़ें और आप वापस वहीं पहुँच जाएंगे, जहाँ से शुरू किया था, फिर से एक बड़ी संख्या की मांग करते हुए।

इसे केवल तभी बढ़ाएं जब किसी वैध क्लाइंट को वास्तव में कई पहचान (identities) प्रस्तुत करने की आवश्यकता हो। बाकी सभी मामलों में क्लाइंट को ठीक करें। एक बार जब हर उपयोगकर्ता कॉन्फ़िगर की गई कुंजी के साथ लॉग इन कर ले, तो इसे कम करना एक उचित सुरक्षा उपाय है, क्योंकि एक छोटी संख्या गेसर को प्रति कनेक्शन कम प्रयास करने का मौका देती है।

Fail2ban आपको इसके लिए क्यों ban कर सकता है

अपने डिफ़ॉल्ट log level पर, sshd प्रत्येक अस्वीकृत public key को रिकॉर्ड करता है:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

एक full agent से आने वाला एक connection एक या दो सेकंड के भीतर एक ही address से ऐसी कई लाइनें उत्पन्न करता है। fail2ban का sshd jail sshd की failure लाइनों को गिनता है और findtime के भीतर maxretry तक पहुँचने पर source address को ban कर देता है। ये विंडो डिफ़ॉल्ट रूप से छोटी होती हैं, इसलिए एक broken connection के दो बार retry करने पर ही आपका अपना address ban होने के लिए पर्याप्त हो सकता है।

इसके बाद लक्षण बदल जाता है, और यही वह हिस्सा है जो लोगों को भ्रमित करता है। आप "Too many authentication failures" देखना बंद कर देते हैं और कुछ भी नहीं देख पाते: connection hang हो जाता है और अंततः timeout हो जाता है, क्योंकि firewall अब आपके packets का उत्तर देने के बजाय उन्हें drop कर रहा है। एक timeout जहाँ आपको पहले error message मिलता था, वह एक संकेत है, और उस अंतर को SSH connection refused बनाम connection timed out में कवर किया गया है।

अपने provider के console से, या किसी अन्य address से, jail की जाँच करें और ban हटाएँ:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

जब तक आप client को ठीक कर रहे हों, तब तक अपने address को jail.local में ignoreip में डालें, और काम पूरा होने पर इसे वापस हटा दें। jail को स्वयं Ubuntu 24.04 के लिए fail2ban गाइड में सेट किया गया है।

ऐसा क्या करें कि यह समस्या दोबारा न आए

हर सर्वर के लिए ~/.ssh/config में अपना एक अलग Host ब्लॉक बनाएँ, जिसमें HostName, User, IdentityFile और IdentitiesOnly yes शामिल हों। इसके बाद, ssh vps टाइप करना छोटा हो जाता है, यह केवल एक की (key) प्रदान करता है, और आपका एजेंट चाहे कितना भी भर जाए, यह MaxAuthTries को ट्रिगर नहीं कर सकता। यह ssh -v के आउटपुट को भी इतना संक्षिप्त रखता है कि जिस दिन कुछ और खराब हो, आप उसे आसानी से पढ़ सकें।

FAQ

"Too many authentication failures" को अभी कैसे ठीक करें?

सभी keys के बजाय केवल एक key का उपयोग करें। तत्काल कनेक्शन के लिए, ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host चलाएँ। स्थायी समाधान के लिए, ~/.ssh/config में एक ब्लॉक जोड़ें जिसमें HostName, User, IdentityFile उस key की ओर इशारा करते हों, और IdentitiesOnly yes, फिर chmod 600 ~/.ssh/config का उपयोग करें। इसे ssh -v के साथ सत्यापित करें: आपको उस host के लिए एक Offering public key: लाइन दिखनी चाहिए।

ssh -i अभी भी मेरी अन्य keys क्यों भेजता है?

क्योंकि -i सूची में एक identity जोड़ता है, यह सूची को सीमित नहीं करता है। ssh-agent में लोड की गई keys सूची में बनी रहती हैं और अभी भी भेजी जाती हैं, अक्सर आपकी key से पहले, इसलिए सर्वर आपकी key तक पहुँचने से पहले ही MaxAuthTries तक पहुँच सकता है। -o IdentitiesOnly=yes वह विकल्प है जो ssh को आपके द्वारा निर्दिष्ट identities तक सीमित करता है। -i और -o IdentitiesOnly=yes का एक साथ उपयोग करें, या उस एक कनेक्शन के लिए agent को पूरी तरह से अनदेखा करने के लिए -o IdentityAgent=none का उपयोग करें।

क्या इसे ठीक करने के लिए मुझे सर्वर पर MaxAuthTries बढ़ाना चाहिए?

नहीं, लगभग हर मामले में ऐसा न करें। client ऐसी keys भेज रहा है जिन्हें यह सर्वर कभी स्वीकार नहीं करेगा, और एक बड़ी सीमा केवल सर्वर को प्रति कनेक्शन अधिक अस्वीकृत प्रस्तावों का मूल्यांकन करने के लिए मजबूर करती है, हर client और हर brute force प्रयास के लिए जो उस तक पहुँचता है। जैसे ही आपके agent में एक और key जुड़ती है, यह फिर से काम करना बंद कर देता है। यदि आप उत्सुक हैं तो sudo sshd -T | grep -i maxauthtries के साथ प्रभावी मान की जाँच करें, फिर IdentitiesOnly के साथ client को ठीक करें।

यह उस सर्वर पर क्यों शुरू हुआ जो पिछले महीने ठीक काम कर रहा था?

आपका agent बड़ा हो गया है। ~/.ssh/config में AddKeysToAgent yes आपके द्वारा उपयोग की जाने वाली प्रत्येक key को लोड रखता है, और desktop keyring agents लॉगिन के समय अपने आप keys लोड कर लेते हैं। एक बार जब लोड की गई keys की संख्या सर्वर की MaxAuthTries से अधिक हो जाती है, तो कोई भी सर्वर जिसकी key प्रस्ताव क्रम में देर से आती है, विफल होने लगता है। ssh-add -l चलाएँ और सर्वर पर मौजूद सीमा के साथ संख्या की तुलना करें।

क्या इससे मेरा IP address fail2ban द्वारा बैन हो सकता है?

हाँ। प्रत्येक अस्वीकृत key सर्वर लॉग में एक Failed publickey for ... लाइन उत्पन्न करती है, इसलिए एक कनेक्शन आपके address से सेकंडों में कई विफलताएं उत्पन्न कर सकता है, और fail2ban sshd jail तब address को बैन कर देती है जब findtime के भीतर maxretry तक पहुँच जाते हैं। इसका संकेत यह है कि त्रुटि एक hang में बदल जाती है और फिर timeout हो जाती है, क्योंकि packets का उत्तर देने के बजाय उन्हें drop किया जा रहा होता है। इसे console से sudo fail2ban-client set sshd unbanip <your address> के साथ साफ़ करें, और पुनः कनेक्ट करने से पहले client को ठीक करें।