SSH Permission denied (publickey) एरर कैसे ठीक करें

Permission denied (publickey) का वास्तविक अर्थ क्या है

Permission denied (publickey) का अर्थ है कि आपके client ने एक या अधिक public keys भेजीं और server ने उनमें से किसी को भी स्वीकार नहीं किया। Network ठीक है और sshd चल रहा है: यह अस्वीकृति authentication के अंतिम चरण में होती है। इसका समाधान कभी भी अनुमान लगाना नहीं होता, क्योंकि ssh -v आपको बताता है कि पाँच संभावित कारणों में से कौन सा कारण आपके मामले में लागू है।

कोष्ठक के अंदर लिखे शब्द वे तरीके हैं जिन्हें server स्वीकार करने के लिए तैयार था। यदि केवल Permission denied (publickey) दिखाई दे, तो इसका अर्थ है कि उस server पर password login बंद है, इसलिए वापस जाने के लिए कोई password विकल्प नहीं है। Permission denied (publickey,password) का अर्थ है कि password का विकल्प उपलब्ध था और आप उनमें भी विफल रहे।

एक ही संदेश पाँच अलग-अलग त्रुटियों को कवर करता है, और यह जानबूझकर अस्पष्ट रखा गया है। यदि कोई server "no such user" या "that key is not installed" जैसा उत्तर देता, तो यह वैध accounts की तलाश करने वाले किसी भी व्यक्ति की मदद करता। इसलिए, keys को बदलना या config files को edit करना शुरू न करें। एक command चलाएँ, output की तीन पंक्तियाँ पढ़ें, और पाँच संभावित कारण घटकर एक रह जाएंगे।

सबसे पहले ssh -v चलाएं और तीन पंक्तियाँ पढ़ें

जो कमांड विफल हुई उसे -v जोड़कर दोबारा चलाएं:

ssh -v deploy@203.0.113.10

एक संक्षिप्त लेकिन वास्तविक रन कुछ इस तरह दिखता है:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

तीन पंक्तियों में आपकी जरूरत की सारी जानकारी होती है।

Authenticating to 203.0.113.10:22 as 'deploy' वह username है जिसका वास्तव में उपयोग किया जाएगा। वह नहीं जो आप उपयोग करना चाहते थे: बल्कि वह जिसे ssh ने कमांड लाइन से, ~/.ssh/config से, या आपके स्थानीय login नाम से निर्धारित किया है।

Authentications that can continue: publickey सर्वर द्वारा स्वीकार किए गए तरीकों की सूची है, जिसे किसी भी key को आजमाने से पहले भेजा जाता है। यदि उस पहली सूची में publickey मौजूद नहीं है, तो सर्वर पर public key login बंद है, इसलिए कोई भी key काम नहीं कर सकती।

Offering public key: ... आपके क्लाइंट द्वारा वास्तव में भेजी गई प्रत्येक key के लिए एक पंक्ति है, जिसमें उस फ़ाइल का नाम और उसका SHA256 fingerprint होता है। जिस key के लिए कोई Offering पंक्ति नहीं है, वह सर्वर को कभी नहीं भेजी गई थी।

अब समस्या को दो भागों में विभाजित करें:

• आपके द्वारा अपेक्षित key के लिए कोई Offering public key पंक्ति नहीं है। गलती आपकी मशीन पर है, क्योंकि सर्वर ने आपकी key देखी ही नहीं है।
• key प्रस्तावित की जाती है और Authentications that can continue: publickey वापस आता है। सर्वर को वह key प्राप्त हुई और उसने उसे अस्वीकार कर दिया, इसलिए गलती सर्वर पर है।

नीचे दिए गए कारण इस आधार पर क्रमबद्ध हैं कि वे कितनी बार समाधान साबित होते हैं।

कारण 1: आप गलत username के साथ connect कर रहे हैं

सबसे आम कारण सबसे कम दिलचस्प भी होता है। sshd, जो SSH (secure shell) server daemon है, कभी यह नहीं बताता कि कोई account मौजूद नहीं है। यह एक काल्पनिक username के लिए पूरी प्रक्रिया चलाता है और अंत में उसी संदेश के साथ मना कर देता है, क्योंकि वैध account नामों का पता चलना हमलावर की मदद कर सकता है। username में एक typo बिल्कुल टूटी हुई key जैसा दिखता है।

किसी भी अन्य चीज़ से पहले Authenticating to ... as लाइन की जाँच करें। यदि इसमें server account के बजाय आपके laptop का login नाम है, तो आपने command से username हटा दिया है।

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

default account उस image पर निर्भर करता है जिसे आपका provider बनाता है। अगस्त 2026 तक, Ubuntu cloud images आमतौर पर ubuntu account के साथ आती हैं, Debian images debian या admin के साथ, Rocky Linux और AlmaLinux rocky और almalinux के साथ, और कई VPS providers इसके बजाय आपकी key को सीधे root में install कर देते हैं। आपके provider का control panel यह record रखता है कि उसने कौन सा account बनाया है। server के बाहर से चलाई गई कोई भी command यह नहीं पूछ सकती।

~/.ssh/config में एक Host block भी username सेट करता है, और यह आपके local login नाम से अधिक प्रभावी होता है:

Host vps-prod
  HostName 203.0.113.10
  User deploy

यदि आपने account खुद बनाया है और फिर आप उसमें login नहीं कर पाए, तो संभवतः key image के default user के लिए install की गई थी और उसे कभी copy नहीं किया गया। वह चरण नए VPS पर शुरुआती दस मिनट का हिस्सा है, और इसे छोड़ना आसान है।

कारण 2: आप जिस key को भेज रहे हैं, वह वास्तव में भेजी नहीं जा रही है

डिफ़ॉल्ट रूप से ssh केवल उन keys को प्रदान करता है जो ssh-agent में मौजूद होती हैं, साथ ही ~/.ssh में निर्धारित फ़ाइल नामों का एक सेट: id_ed25519, id_ecdsa, id_rsa, और उन नामों के हार्डवेयर तथा DSA वेरिएंट। ~/.ssh/vps-prod के रूप में सहेजी गई key तब तक ssh को दिखाई नहीं देती जब तक आप उसका नाम निर्दिष्ट नहीं करते, यही कारण है कि verbose आउटपुट में इसके लिए कोई Offering public key लाइन नहीं दिखाई देती है।

फ़ाइल का नाम निर्दिष्ट करें, और agent keys को उसका स्थान लेने से रोकें:

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

जब agent के पास keys होती हैं, तो केवल -i पर्याप्त नहीं है, क्योंकि ssh अभी भी agent की keys को पहले और निर्दिष्ट फ़ाइल को अंत में प्रदान करता है। यह महत्वपूर्ण है, क्योंकि सर्वर प्रत्येक अस्वीकृत key को MaxAuthTries के विरुद्ध गिनता है, जो डिफ़ॉल्ट रूप से 6 पर सेट होता है। यदि agent के पास सात keys हैं, तो आपकी सही key तक पहुँचने से पहले ही सीमा समाप्त हो सकती है, और संदेश बदलकर यह हो जाता है:

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

IdentitiesOnly=yes प्रयास को केवल उस फ़ाइल तक सीमित करता है जिसे आपने पास किया है। ssh-add -l के साथ देखें कि agent के पास कौन सी keys हैं, और यदि इसमें वर्षों पुरानी keys जमा हो गई हैं तो ssh-add -D के साथ इसे साफ़ करें। फिर सेटिंग्स को लिख लें ताकि अगली बार लॉगिन करते समय आपको flags याद रखने की आवश्यकता न पड़े:

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

क्लाइंट-साइड पर एक और समस्या। ssh ऐसी private key का उपयोग करने से इनकार कर देता है जिसे आपके अपने मशीन पर अन्य accounts पढ़ सकते हैं। यह एक चेतावनी प्रिंट करता है और फिर key को अनदेखा कर देता है, इसलिए key कभी प्रदान नहीं की जाती और सर्वर उसे कभी नहीं देख पाता:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod इसे ठीक करता है। USB स्टिक या Windows share के माध्यम से key को स्थानांतरित करने पर अक्सर mode की जानकारी खो जाती है। keys कहाँ रहती हैं और उन्हें क्या नाम देना है, यह SSH key management basics में कवर किया गया है।

कारण 3: public key कभी authorized_keys तक नहीं पहुँची

यदि ssh -v यह दिखाता है कि key भेजी जा चुकी है और सर्वर फिर भी access देने से मना कर रहा है, तो अगला प्रश्न यह है कि क्या वह key अकाउंट की authorized_keys फाइल में मौजूद है। इसे जाँचने के लिए अपने provider के console को खोलें, क्योंकि आप SSH के माध्यम से login करके इसे नहीं देख सकते।

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

authorized_keys फाइल पर ssh-keygen -lf चलाने से प्रत्येक entry का एक fingerprint प्रिंट होता है:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

इनकी तुलना अपनी Offering public key लाइन के fingerprint से करें। यदि यह सूची में नहीं है, तो key उस अकाउंट पर install नहीं हुई है, चाहे आपको कुछ भी याद हो।

इसके गलत होने के चार सामान्य तरीके हैं:

• आपने .pub फाइल के बजाय private key को paste कर दिया। एक public key लाइन ssh-ed25519 या ssh-rsa से शुरू होती है। एक private key -----BEGIN OPENSSH PRIVATE KEY----- से शुरू होती है।
• paste करते समय key कई लाइनों में टूट गई। प्रत्येक entry को ठीक एक लाइन में होना चाहिए, इसलिए टूटी हुई key को कई खंडित entries के रूप में पढ़ा जाता है और वह किसी से match नहीं करती।
• key /root/.ssh/authorized_keys में चली गई जबकि आप deploy के रूप में login कर रहे हैं, या इसके विपरीत। यह फाइल प्रति अकाउंट होती है, और कोई साझा फाइल नहीं होती।
• provider के "add my key" बॉक्स ने इसे केवल image के default user के लिए लिखा, इसलिए बाद में आपके द्वारा बनाए गए अकाउंट की .ssh डायरेक्टरी खाली है।

console से root के रूप में key जोड़ने का सुरक्षित तरीका:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

इसके बाद फिर से sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys चलाएँ। नया fingerprint अब सूची में होना चाहिए। ऐसी मशीन से जो अभी भी password के साथ login कर सकती है, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 वही काम करता है और आपके लिए modes को सही ढंग से सेट करता है।

कारण 4: जब permissions बहुत अधिक खुली हों तो sshd authorized_keys को अनदेखा क्यों करता है

StrictModes yes, sshd का डिफ़ॉल्ट है। इसके अंतर्गत, यदि authorized_keys फ़ाइल, .ssh डायरेक्टरी, या अकाउंट की होम डायरेक्टरी को ओनर के अलावा कोई और लिख (write) सकता है, तो sshd उसे पढ़ने से मना कर देता है। इसका कारण स्पष्ट है: यदि ग्रुप या कोई अन्य व्यक्ति आपकी होम डायरेक्टरी में लिख सकता है, तो उस एक्सेस वाला कोई भी अकाउंट authorized_keys को बदल सकता है और लॉगिन पर कब्जा कर सकता है। sshd एक अविश्वसनीय पाथ (untrusted path) के साथ ऐसा व्यवहार करता है जैसे कि कोई की (key) मौजूद ही न हो।

क्लाइंट को केवल Permission denied का साधारण संदेश दिखाई देता है। सर्वर लॉग में वास्तविक कारण दर्ज होता है:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

या, जब समस्या स्वयं फ़ाइल के साथ हो:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

sshd क्या स्वीकार करेगा:

• होम डायरेक्टरी: ग्रुप-राइटेबल या वर्ल्ड-राइटेबल नहीं होनी चाहिए। 755, 750 और 700 सभी मान्य हैं। 775 और 777 विफल हो जाते हैं।
• ~/.ssh: मोड 700।
• ~/.ssh/authorized_keys: मोड 600।
• ओनरशिप: तीनों का ओनर वही अकाउंट होना चाहिए जिससे आप लॉगिन करते हैं, न कि root।

ओनरशिप उतनी ही महत्वपूर्ण है जितना कि मोड। /home/deploy/.ssh के अंदर की कोई फ़ाइल यदि root के स्वामित्व में है, तो वह भी उसी चेक में विफल हो जाएगी। ऐसा तब होता है जब आप इसे sudo nano के साथ बनाते हैं और ओनरशिप वापस बदलना भूल जाते हैं। दोनों को एक साथ ठीक करें:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

अंतिम कमांड परिणाम दिखाती है। आप होम डायरेक्टरी पर drwxr-xr-x या उससे अधिक सख्त परमिशन और .ssh पर drwx------ चाहते हैं। यदि ये स्ट्रिंग्स अभी स्पष्ट नहीं हैं, तो लाइव सर्वर पर मोड बदलने से पहले drwxr-xr-x जैसी परमिशन स्ट्रिंग को कैसे पढ़ें देखें।

Rocky Linux और AlmaLinux पर, संदिग्धों की सूची में SELinux (security-enhanced Linux) को भी जोड़ें। असामान्य तरीके से बनाई गई .ssh डायरेक्टरी में गलत फ़ाइल लेबल हो सकता है, जिससे परमिशन सही दिखने के बावजूद sshd को रीड एक्सेस नहीं मिलता। sudo restorecon -Rv /home/deploy/.ssh लेबल्स को वापस सही कर देता है, और sudo ausearch -m avc -ts recent यह दिखाता है कि क्या SELinux ही वह घटक था जो एक्सेस से मना कर रहा था।

कारण 5: sshd आपको अस्वीकार करने के लिए कॉन्फ़िगर है

वर्तमान Ubuntu या Debian सिस्टम पर केवल /etc/ssh/sshd_config पढ़ना पर्याप्त नहीं है। वह फ़ाइल Include /etc/ssh/sshd_config.d/*.conf से शुरू होती है, और OpenSSH किसी भी सेटिंग के लिए मिलने वाले पहले मान को ही रखता है। इसलिए, 50-cloud-init.conf जैसी ड्रॉप-इन फ़ाइल सबसे पहले पढ़ी जाती है और मुख्य फ़ाइल में नीचे किए गए किसी भी बदलाव पर प्रभावी रहती है। यही कारण है कि एक संपादन सही दिख सकता है लेकिन कोई बदलाव नहीं करता है।

sshd से उस कॉन्फ़िगरेशन के बारे में पूछें जिसका वह वास्तव में उपयोग कर रहा है:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

एक सही उत्तर इस तरह दिखता है:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

अपने आउटपुट में क्या देखें:

• pubkeyauthentication no। कोई भी कुंजी कभी स्वीकार नहीं की जाएगी। यह ssh -v में भी पहले Authentications that can continue: के रूप में दिखाई देता है जिसमें कोई publickey नहीं है।
• authorizedkeysfile जो कहीं और इंगित कर रहा हो, उदाहरण के लिए /etc/ssh/authorized_keys/%u। तब आपकी होम डायरेक्टरी वाली फ़ाइल को पूरी तरह से अनदेखा कर दिया जाता है, और नए पथ पर कारण 4 के मोड नियम लागू होते हैं।
• allowusers या allowgroups मौजूद होना। सूचीबद्ध न होने वाले किसी भी खाते को बिना किसी स्पष्टीकरण के ठीक इसी त्रुटि के साथ अस्वीकार कर दिया जाता है। denyusers और denygroups विपरीत रूप से यही काम करते हैं।
• permitrootlogin no जब आप root के रूप में लॉग इन करने का प्रयास कर रहे हों। prohibit-password एक उपयोगी मध्य सेटिंग है: root कुंजी का उपयोग कर सकता है लेकिन पासवर्ड का नहीं।

Match ब्लॉक एक सामान्य sshd -T में दिखाई नहीं देते हैं, क्योंकि उनका परिणाम इस पर निर्भर करता है कि कौन कनेक्ट कर रहा है। एक विशिष्ट कनेक्शन के बारे में पूछें:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

एक और सेटिंग पुरानी कुंजियों को प्रभावित करती है। OpenSSH 8.8 ने डिफ़ॉल्ट रूप से SHA-1 हस्ताक्षर (ssh-rsa) स्वीकार करना बंद कर दिया है, इसलिए वर्षों से काम कर रही RSA कुंजी सर्वर अपग्रेड के ठीक बाद काम करना बंद कर सकती है। क्लाइंट इसे स्पष्ट रूप से बताता है:

debug1: send_pubkey_test: no mutual signature algorithm

इसका सही समाधान एक नई कुंजी है: ssh-keygen -t ed25519 -C "deploy@vps-prod", फिर ऊपर दिखाए अनुसार .pub फ़ाइल इंस्टॉल करें। सर्वर पर PubkeyAcceptedAlgorithms +ssh-rsa सेट करने से पुराने हस्ताक्षर फिर से सक्षम हो जाते हैं और आप आज प्रवेश कर सकते हैं, इसलिए इसे बॉक्स तक पहुँचने का एक तरीका मानें, न कि काम का अंत। सर्वर-साइड सेटिंग्स का शेष भाग जिन्हें समीक्षा करने की आवश्यकता है, वे VPS पर SSH सर्वर को सुरक्षित करने में हैं।

यह कैसे सिद्ध करें कि private key, installed public key से मेल खाती है

इस त्रुटि में अधिकांश अनुमान इस कारण होते हैं क्योंकि यह पता नहीं होता कि क्या दो फाइलें एक जोड़ा हैं। एक कमांड इसका उत्तर देती है:

ssh-keygen -y -f ~/.ssh/vps-prod

यह कमांड private key से प्राप्त public key को प्रिंट करती है। यह इसके बगल में मौजूद .pub फाइल को नहीं पढ़ती है, इसलिए यह आपको बताती है कि private key वास्तव में क्या है, न कि वह जो एक पुरानी .pub फाइल दावा करती है। यदि key में passphrase है, तो कमांड उसे मांगती है, जो यह भी सिद्ध करता है कि आप अभी भी passphrase जानते हैं।

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

पहली कमांड एक public key फाइल का fingerprint प्रिंट करती है। दूसरी कमांड उन fingerprints को प्रिंट करती है जिन्हें आपका agent होल्ड कर रहा है। अब एक ही स्ट्रिंग के चार दृश्यों को मिलाएं: ssh -v से Offering public key लाइन पर मौजूद fingerprint, आपकी .pub फाइल का fingerprint, सर्वर की authorized_keys पर ssh-keygen -lf में मौजूद fingerprints, और सर्वर लॉग में मौजूद fingerprint। जिस बिंदु पर वे मेल खाना बंद कर देते हैं, वही आपकी गलती है।

लॉगिन विफल होने पर सर्वर लॉग पढ़ें

सुरक्षा कारणों से क्लाइंट को कोई उपयोगी जानकारी नहीं दी जाती है। सर्वर वास्तविक कारण को लॉग में लिखता है। कंसोल सत्र पर एक लॉग फॉलोअर शुरू करें, फिर अपने लैपटॉप से विफल हो रहे ssh कमांड को चलाएं।

sudo journalctl -u ssh -f

Ubuntu 24.04 डिफ़ॉल्ट रूप से rsyslog इंस्टॉल नहीं करता है, इसलिए /var/log/auth.log वहां मौजूद नहीं हो सकता है। Rocky Linux और AlmaLinux पर यूनिट का नाम sshd है और वही रिकॉर्ड /var/log/secure में भी दर्ज होते हैं।

sshd कॉन्फ़िगरेशन में LogLevel VERBOSE सेट करें और सर्विस को रिलोड करें। इसके बाद हर प्रयास उस फिंगरप्रिंट को लॉग करेगा जो सर्वर को वास्तव में प्राप्त हुआ है:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

वह लाइन आपको बताती है कि गलती किस तरफ है। यदि आप फिंगरप्रिंट को पहचानते हैं, तो इसका मतलब है कि आपकी की (key) सर्वर तक पहुँच गई और अस्वीकार कर दी गई, इसलिए कारण 3, 4 और 5 देखें। यदि आप फिंगरप्रिंट को नहीं पहचानते हैं, तो इसका मतलब है कि आपके क्लाइंट ने वह की भेजी है जिसे आप नहीं भेजना चाहते थे, इसलिए कारण 2 पर वापस जाएं।

जब लॉग अभी भी स्पष्ट न हो, तो एक अलग पोर्ट पर डिबग मोड में दूसरा sshd चलाएं। यह फोरग्राउंड में रहता है, एक कनेक्शन को सर्व करता है, अपना तर्क प्रिंट करता है और फिर बाहर निकल जाता है:

sudo /usr/sbin/sshd -ddd -p 2222

उसी सर्वर पर कंसोल सत्र से, लूपबैक एड्रेस के माध्यम से इससे कनेक्ट करें:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 का उपयोग करने से फ़ायरवॉल परीक्षण से बाहर रहता है। डिबग आउटपुट उस फ़ाइल का नाम बताता है जिसे उसने खोला, जिस फिंगरप्रिंट की उसने तुलना की, और सटीक अस्वीकृति का कारण, जिसमें Authentication refused: bad ownership or modes for directory /home/deploy जैसी लाइनें शामिल हैं। जब आपको अपना उत्तर मिल जाए तो Ctrl+C दबाएं। पोर्ट 22 पर वास्तविक sshd पूरी प्रक्रिया के दौरान अप्रभावित रहता है।

खुद को लॉक होने से कैसे बचाएं

सर्वर कॉन्फ़िगरेशन में बदलाव करने वाले हर चरण के लिए एक ऐसा बैकअप रास्ता होना चाहिए जो SSH पर निर्भर न हो। इसे तब सेट करें जब SSH अभी काम कर रहा हो, न कि इसके बंद होने के बाद।

1. अपने प्रोवाइडर के कंसोल को सीरियल या VNC (virtual network computing) के माध्यम से खोलें और पुष्टि करें कि आप वहां लॉग इन कर सकते हैं।
2. सुनिश्चित करें कि आपके पास sudo अधिकार वाले अकाउंट के लिए एक काम करने वाला लोकल पासवर्ड है। यदि आपके पास यह नहीं है, तो पहले प्रोवाइडर कंसोल से root पासवर्ड रीसेट करें।
3. अपने वर्तमान SSH सेशन को खुला रखें। एक खुला सेशन systemctl restart ssh के बाद भी बना रहता है, इसलिए यदि नया कॉन्फ़िगरेशन गलत है तो यह वापस अंदर जाने का एक रास्ता बना रहता है।
4. रीस्टार्ट करने से पहले सिंटैक्स की जांच करें: sudo sshd -t फाइल वैध होने पर कुछ भी प्रिंट नहीं करता है, और अमान्य होने पर फाइल और लाइन नंबर प्रिंट करता है।
5. पहला टर्मिनल बंद करने से पहले एक दूसरा टर्मिनल खोलें और नए सिरे से लॉग इन करें। खराब कॉन्फ़िगरेशन नए लॉगिन को रोकता है लेकिन मौजूदा लॉगिन को प्रभावित नहीं करता है, इसलिए जिस सेशन में आप काम कर रहे हैं, वह आपको यह नहीं बता पाएगा कि बदलाव ने काम किया या नहीं।

Debian और Ubuntu पर sudo systemctl restart ssh के साथ, या Rocky Linux और AlmaLinux पर sudo systemctl restart sshd के साथ रीस्टार्ट करें। Ubuntu 24.04 पर sshd को एक socket unit से शुरू किया जाता है, इसलिए Port या ListenAddress में किसी भी बदलाव के प्रभावी होने से पहले sudo systemctl restart ssh.socket की भी आवश्यकता होती है।

FAQ

जब वही key दूसरे सर्वर पर काम करती है, तो मुझे Permission denied (publickey) क्यों मिलता है?

क्योंकि key सही है लेकिन उसके आसपास की कोई चीज़ गलत है। ssh -v चलाएँ और Offering public key लाइन ढूँढें। यदि आपकी key वहां सूचीबद्ध नहीं है, तो ssh ने उसे कभी भेजा ही नहीं: वह फाइल ~/.ssh में डिफ़ॉल्ट नाम से नहीं है और agent में लोड नहीं है, इसलिए -i /path/to/key -o IdentitiesOnly=yes जोड़ें। यदि key सूचीबद्ध है और सर्वर फिर भी मना कर रहा है, तो वह key अकाउंट की authorized_keys में मौजूद नहीं है, उसका पाथ group-writable है, या sshd कॉन्फ़िगरेशन उस यूजर को ब्लॉक कर रहा है। सर्वर लॉग इन स्थितियों को अलग-अलग दिखाता है।

मैं यह कैसे देखूँ कि SSH वास्तव में कौन सी key भेज रहा है?

ssh -v host प्रत्येक key के लिए एक debug1: Offering public key: लाइन प्रिंट करता है, जिसमें सोर्स फाइल और SHA256 फिंगरप्रिंट का नाम होता है। ssh-add -l उन फिंगरप्रिंट्स को सूचीबद्ध करता है जो agent के पास हैं। ssh-keygen -lf ~/.ssh/id_ed25519.pub एक सिंगल key फाइल का फिंगरप्रिंट प्रिंट करता है, और ssh-keygen -y -f ~/.ssh/id_ed25519 वह public key प्रिंट करता है जो वास्तव में एक private key से बनती है। लॉगिन सफल होने के लिए, Offering लाइन का फिंगरप्रिंट सर्वर की authorized_keys के विरुद्ध चलाए गए ssh-keygen -lf में भी दिखाई देना चाहिए।

sshd मेरी authorized_keys फाइल को अनदेखा क्यों कर रहा है?

क्योंकि StrictModes डिफ़ॉल्ट रूप से चालू रहता है, और या तो फाइल, .ssh डायरेक्टरी, या होम डायरेक्टरी group या world द्वारा writable है, या फिर किसी गलत अकाउंट के स्वामित्व में है। sshd ऐसे पाथ पर भरोसा नहीं करेगा जिसे कोई और बदल सके, इसलिए यह ऐसे व्यवहार करता है जैसे कोई key मौजूद ही न हो। होम डायरेक्टरी को 755 या उससे अधिक सुरक्षित रखें, .ssh को 700 पर सेट करें, authorized_keys को 600 पर सेट करें, और सुनिश्चित करें कि तीनों का स्वामित्व लॉगिन अकाउंट के पास हो। LogLevel VERBOSE के साथ सर्वर Authentication refused: bad ownership or modes for directory /home/deploy/.ssh रिकॉर्ड करता है।

सर्वर अपग्रेड के तुरंत बाद मेरी key ने काम करना बंद कर दिया। क्या बदला है?

यदि यह एक RSA key है, तो यह सबसे अधिक संभावना SHA-1 बदलाव के कारण है। OpenSSH 8.8 ने डिफ़ॉल्ट रूप से ssh-rsa SHA-1 सिग्नेचर को डिसेबल कर दिया है, इसलिए ऐसी key जो केवल उस तरह से साइन कर सकती है, उसे अब अस्वीकार कर दिया जाता है। वर्बोस क्लाइंट आउटपुट debug1: send_pubkey_test: no mutual signature algorithm दिखाता है। ssh-keygen -t ed25519 के साथ एक आधुनिक key जनरेट करें और उसकी .pub फाइल इंस्टॉल करें। यदि आपको तुरंत एक्सेस की आवश्यकता है, तो सर्वर पर PubkeyAcceptedAlgorithms +ssh-rsa पुराने सिग्नेचर को फिर से इनेबल कर देता है, और नई key काम करने के बाद आपको उस लाइन को हटा देना चाहिए।

मैंने sshd_config को एडिट किया और अब मैं बिल्कुल भी लॉगिन नहीं कर पा रहा हूँ। मैं वापस कैसे जाऊँ?

अपने प्रदाता के कंसोल का उपयोग करें, जो SSH के माध्यम से नहीं जाता है। वहां लोकल पासवर्ड के साथ लॉगिन करें, सिंटैक्स एरर और उसकी लाइन नंबर देखने के लिए sudo sshd -t चलाएँ, बदलाव को पूर्ववत (undo) करें, और सर्विस को रीस्टार्ट करें। फिर रनिंग वैल्यूज की पुष्टि करने के लिए sudo sshd -T की जाँच करें, क्योंकि /etc/ssh/sshd_config.d/ में कोई फाइल मुख्य कॉन्फ़िगरेशन को ओवरराइड कर रही हो सकती है। यदि आपके पास कोई लोकल पासवर्ड नहीं है, तो पहले कंसोल से root पासवर्ड रीसेट करें, फिर फाइल को ठीक करें।