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

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

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

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

एक ही संदेश पांच अलग-अलग त्रुटियों को कवर करता है, और यह जानबूझकर अस्पष्ट रखा गया है। यदि 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 name से निर्धारित किया है।

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

Offering public key: ... आपके client द्वारा वास्तव में भेजी गई प्रत्येक 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 ब्लॉक भी 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

यदि इसके बजाय आपको यही संदेश दिखाई दे रहा है, तो server ने आपके सही key तक पहुँचने से पहले ही session बंद कर दिया। यह बहुत अधिक authentication failures का विषय है। IdentitiesOnly=yes प्रयास को आपके द्वारा दिए गए file तक सीमित करता है। ssh-add -l से देखें कि agent के पास कौन-कौन से keys मौजूद हैं। यदि उसमें वर्षों पुराने keys जमा हैं, तो ssh-add -D से उन्हें हटाएँ। इसके बाद settings लिखकर सुरक्षित रखें, ताकि अगला login 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 account की 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 उस account पर 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 कर रहे हैं, या इसके विपरीत। यह फाइल प्रति account होती है, और कोई साझा फाइल नहीं होती।
• provider के "add my key" बॉक्स ने इसे केवल image के default user के लिए लिखा, इसलिए आपके द्वारा बाद में बनाए गए account की .ssh directory खाली है।

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 को सही ढंग से set कर देता है।

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

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

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

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

debug1: send_pubkey_test: no mutual signature algorithm

इसका सही समाधान एक नई की (key) है: 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 को एक सॉकेट यूनिट से शुरू किया जाता है, इसलिए 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 में मौजूद नहीं है, या उस तक जाने वाला path group-writable है, या sshd config उस user को ब्लॉक कर रहा है। सर्वर लॉग इन स्थितियों को अलग-अलग स्पष्ट करता है।

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

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

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

क्योंकि StrictModes डिफ़ॉल्ट रूप से चालू रहता है, और या तो फाइल, .ssh डायरेक्टरी, या home डायरेक्टरी group या world द्वारा writable है, या किसी गलत अकाउंट के स्वामित्व में है। sshd ऐसे path पर भरोसा नहीं करेगा जिसे कोई और बदल सके, इसलिए यह ऐसे व्यवहार करता है जैसे कोई key मौजूद ही न हो। home डायरेक्टरी को 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 जो केवल उसी तरह से साइन कर सकती है, उसे अब अस्वीकार कर दिया जाता है। verbose client आउटपुट debug1: send_pubkey_test: no mutual signature algorithm दिखाता है। ssh-keygen -t ed25519 के साथ एक आधुनिक key उत्पन्न करें और उसकी .pub फाइल इंस्टॉल करें। यदि आपको तुरंत एक्सेस की आवश्यकता है, तो सर्वर पर PubkeyAcceptedAlgorithms +ssh-rsa पुराने हस्ताक्षरों को फिर से सक्षम कर देता है, और नई key के काम करने के बाद आपको उस लाइन को हटा देना चाहिए।

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

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