SSH Permission denied (publickey): असली समाधान

02:10 पर एक डिप्लॉय उस लाइन पर मरा जिसे मैंने हज़ार बार टाइप किया है: ssh deploy@staging → Permission denied (publickey). कुंजी ठीक थी। पेशकश खराब थी।

TL;DR: Permission denied (publickey) का मतलब है कि क्लाइंट की हर पेशकश सर्वर ने ठुकरा दी — यह पासवर्ड की गलती नहीं, एक पेशकश-नामंज़ूरी का फ़ैसला है। पहचानें ssh -vvv से (कौन-सी कुंजियाँ पेश हुईं) और सर्वर लॉग journalctl -u ssh से (कौन-सी ठुकराई गईं, क्यों)। फिर चार कारणों में से एक ठीक करें: गलत यूज़र, कुंजी का authorized_keys में न होना, खुली अनुमतियाँ, या OpenSSH 8.8+ की ठुकराई ssh-rsa कुंजी। ssh-copy-id ज़्यादातर दोहराव रोक देता है।

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

यह त्रुटि संकेत नहीं, फ़ैसला है: पेशकश की हर चीज़ ठुकरा दी गई थी।

SSH “Permission denied (publickey)” क्यों कहता है?

सार्वजनिक कुंजी से प्रमाणीकरण एक पेशकश-नामंज़ूरी बातचीत है। क्लाइंट हर कुंजी पेश करता है जो उसे मिल सकती है — एजेंट की पहचानें, आपकी ~/.ssh/config, डिफ़ॉल्ट फ़ाइलनाम (id_ed25519, id_rsa) और -i से दी गई हर चीज़। सर्वर हर पेशकश को लक्ष्य खाते की ~/.ssh/authorized_keys से मिलाता है। जब कुछ नहीं टिकता और पासवर्ड प्रमाणीकरण बंद है या खत्म हो चुका है, तो क्लाइंट वह एक पंक्ति छापता है जो हर devops इंजीनियर को ज़ुबानी है।

डिबगिंग के लिए दो बातें मायने रखती हैं। पहली, संदेश नहीं बताता कि आप किस यूज़र तक पहुँचे — आधे मामलों में बिल्कुल सही कुंजी गलत खाते के authorized_keys में पड़ी रहती है। दूसरी, सर्वर कारण पहले ही बता चुका होता है: sshd हर ठुकराई पेशकश लॉग करता है। वह स्टैक-ट्रेस जिसे कोई नहीं माँगता पर हर किसी को चाहिए, वह है -vvv.

कैसे देखें कि SSH असल में कौन-सी कुंजी पेश कर रहा है?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

तीन पंक्तियाँ पढ़ें: Offering public key (क्लाइंट ने क्या पेश किया), Authentications that can continue (सर्वर और क्या स्वीकारेगा — अगर password नहीं है तो पासवर्ड का सवाल कभी नहीं आएगा) और अंतिम फ़ैसला। अगर आपकी कुंजी पेशकश-सूची में कभी दिखती ही नहीं, तो समस्या क्लाइंट-साइड है: गलत -i पथ, ~/.ssh/config में भूला हुआ IdentityFile, या कोई एजेंट (ssh-add -l) जो पुरानी पहचान लेकर पहले जवाब दे देता है।

चार असली कारण कौन-से हैं?

कारण	पहचान	इलाज
गलत यूज़र	कुंजी root@host पर चलती है, deploy@host पर फेल होती है	कुंजी उसी यूज़र के ~/.ssh/authorized_keys में होनी चाहिए
कुंजी इंस्टॉल नहीं	सर्वर लॉग हर पेशकश पर Failed publickey दिखाता है	ssh-copy-id user@host
अनुमतियाँ बहुत खुली	क्लाइंट: WARNING: UNPROTECTED PRIVATE KEY FILE — कुंजी छोड़ दी जाती है, पेश होती ही नहीं	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
पुरानी ssh-rsa कुंजी	सर्वर OpenSSH 8.8+ पर; पुरानी RSA कुंजी कभी स्वीकार नहीं होती	ed25519 में नई बनाएँ, या कुंजी अपग्रेड करें

अनुमति वाले कारण की अलग बात ज़रूरी है, क्योंकि OpenSSH इसे सख़्ती से लागू करता है: निजी कुंजी जिसे ग्रुप या अन्य पढ़ सकते हैं, उसे क्लाइंट खुद ठुकरा देता है और वह चुपचाप पेशकश से बाहर हो जाती है। इलाज दो कमांड हैं:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

ssh-rsa वाला कारण पुरानी CI इमेज और Raspberry Pi पर बिझता है: OpenSSH 8.8 (रिलीज़ 2021-10-01, openssh.com/txt/release-8.8) ने ssh-rsa हस्ताक्षर — SHA-1 वाला रूप — डिफ़ॉल्ट रूप से बंद कर दिया। रिलीज़ नोट्स के शब्दों में, “the ssh-rsa signature scheme is … disabled by default”. 2018 में बनी RSA कुंजी खराब नहीं है; उसका हस्ताक्षर-फ़ॉर्मैट अब बोला ही नहीं जाता। ed25519 कुंजी बनाना (ssh-keygen -t ed25519) टिकाऊ जवाब है, और क्लाउड कंसोल आपको सीरियल कंसोल देते हैं ताकि बीच में बाहर निकले तो वापस आ सकें।

कॉन्फ़िग एडिट करते वक़्त sshd खुद शुरू न हो रहा हो, तो वह दूसरी शिकार है — देखें systemd service not starting.

कैसे देखें कि सर्वर ने कुंजी क्यों ठुकराई?

सर्वर-साइड लॉग ईमानदार गवाह है। Ubuntu (systemd) पर sshd हर पेशकश का फ़ैसला लॉग करता है:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

अनजान फ़िंगरप्रिंट के साथ Failed publickey का मतलब है कि क्लाइंट ने सोची हुई से दूसरी कुंजी पेश की — वापस -vvv पर जाएँ। आपके फ़िंगरप्रिंट के साथ Failed publickey का मतलब है कि कुंजी सही है पर उस खाते के लिए इंस्टॉल नहीं, या सर्वर-साइड होम डायरेक्टरी की अनुमतियाँ गलत हैं (वही 700/600 नियम सर्वर के ~/.ssh और ~/.ssh/authorized_keys पर भी लागू)।

अपनी कुंजी सही तरीके से कैसे इंस्टॉल करें?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # बिना इंटरैक्शन का सबूत

ssh-copy-id आपकी सार्वजनिक कुंजी को लक्ष्य खाते के authorized_keys में ठीक अनुमतियों के साथ जोड़ता है — यह कमांड इसलिए है कि authorized_keys में हाथ से पेस्ट करना ठीक इतनी बार फेल होता है: आख़िरी न्यूलाइन या गायब डायरेक्टरी। BatchMode जाँच असली परीक्षा है: यह सारे प्रॉम्प्ट बंद कर देता है, तो सफलता का मतलब है कि लॉगिन अकेले कुंजी ने उठाया। कुंजी चल पड़ी तो scp और rsync वही प्रमाणीकरण मुफ़्त में पा लेते हैं — दोनों में चुनाव बैंडविड्थ का सवाल है, क्रेडेंशियल का नहीं (rsync vs scp)।

30 सेकंड का ट्रायाज

ssh -vvv user@host 2>&1 | grep -i offering      # 1. कौन-सी कुंजियाँ पेश हुईं?
journalctl -u ssh -n 50 | grep -i publickey     # 2. क्यों ठुकराई गईं?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600 है?
ssh-copy-id user@host                           # 4. इंस्टॉल करें, फिर BatchMode से जाँचें

Permission denied (publickey) पासवर्ड का प्रॉम्प्ट नहीं, बातचीत का नतीजा है — सर्वर ने पेशकश की हर कुंजी ठुकरा दी, और उसका लॉग कारण पहले से जानता है।

चार कमांड क्रम से चलाइए, और खराबी रहस्य नहीं रहती: हर बार उनमें से एक दोषी का नाम ले देता है। मेरे यहाँ सही कुंजी से पहले जवाब देने वाली एक पुरानी एजेंट पहचान थी — ssh-add -d, और 02:31 तक डिप्लॉय फिर हरा हो गया।