यदि macOS टर्मिनल “UNPROTECTED PRIVATE KEY FILE” रिपोर्ट करता है या कहता है कि आपकी SSH की (key) बहुत अधिक सुलभ है, तो प्राइवेट की तक पहुंच को प्रतिबंधित करें और .ssh डायरेक्टरी की जांच करें। टर्मिनल खोलें और वास्तव में आपके द्वारा उपयोग की जाने वाली की फ़ाइल पर chmod 600 चलाएं। यह इसे केवल आपके खाते द्वारा पढ़ने और लिखने योग्य बनाता है; SSH उन प्राइवेट की फ़ाइलों को अनदेखा कर देता है जिन्हें अन्य उपयोगकर्ता एक्सेस कर सकते हैं। OpenBSD ssh(1) मैन्युअल

प्राइवेट की (private key) की अनुमतियां ठीक करें

पहले की (key) फ़ाइल की पहचान करें। SSH के सामान्य डिफ़ॉल्ट प्राइवेट की नामों में id_ed25519 और id_rsa शामिल हैं, लेकिन आपका कोई अन्य नाम या स्थान हो सकता है। .pub प्रत्यय (suffix) पब्लिक की की पहचान करता है; इस समाधान को प्राइवेट की के बजाय उस फ़ाइल पर लागू न करें।

डिफ़ॉल्ट Ed25519 की (key) के लिए, यह दर्ज करें:

chmod 600 "$HOME/.ssh/id_ed25519"

किसी अन्य की (key) के लिए, id_ed25519 को उसके वास्तविक फ़ाइल नाम से बदलें। पथ (path) को कोट्स (quotes) में रखने से फ़ाइल नाम में मौजूद स्पेस और अन्य शेल कैरेक्टर सिंटैक्स के रूप में व्यवहार किए जाने से बच जाते हैं। यदि की (key) कहीं और है, तो कोट्स के अंदर इसके पूर्ण पथ का उपयोग करें। 600 स्वामी (owner) को पढ़ने और लिखने की अनुमति देता है तथा समूह (group) और अन्य उपयोगकर्ताओं के लिए एक्सेस हटा देता है। OpenBSD chmod(1) मैन्युअल

आप परिणामी मोड का निरीक्षण ls -l "$HOME/.ssh/id_ed25519" से कर सकते हैं। एक सामान्य प्रदर्शन -rw------- से शुरू होता है; फ़ाइल प्रकार के बाद के पहले तीन अनुमति वर्ण स्वामी की पहुंच दिखाते हैं, और शेष समूह समूह या अन्य के लिए कोई पहुंच नहीं दिखाते हैं। फ़ाइल का स्वामी भी आपका खाता होना चाहिए। यदि यह किसी अन्य उपयोगकर्ता का है, तो chmod विफल हो सकता है या SSH क्लाइंट अभी भी इसका उपयोग करने में असमर्थ हो सकता है। ls -l के साथ स्वामित्व की जांच करें; बिना सोचे-समझे स्वामित्व बदलने से बचें, विशेष रूप से sudo के साथ, क्योंकि सही सुधार इस बात पर निर्भर करता है कि फ़ाइल किसी अन्य की क्यों है।

.ssh डायरेक्टरी की जांच करें

SSH मैन्युअल अनुशंसा करता है कि ~/.ssh/ इसके स्वामी द्वारा पढ़ने, लिखने और खोजने योग्य होना चाहिए, और दूसरों के लिए दुर्गम होना चाहिए। यदि SSH स्वयं डायरेक्टरी के लिए अनुमतियों की समस्या की रिपोर्ट करता है, तो चलाएं:

chmod 700 "$HOME/.ssh"

यह समूह और अन्य एक्सेस को हटा देता है जबकि आपके खाते को पूर्ण डायरेक्टरी एक्सेस की अनुमति देता है। यदि की (key) किसी भिन्न फ़ोल्डर में संग्रहीत है, तो उसके पथ में प्रत्येक डायरेक्टरी की जांच करें: फ़ाइल तक पहुंचने के लिए खाते को खोज (execute) अनुमति की आवश्यकता होती है। पहले समाधान के रूप में अपनी संपूर्ण होम डायरेक्टरी या .ssh फ़ोल्डर पर पुनरावर्ती (recursively) रूप से chmod न चलाएं; यह भिन्न आवश्यकताओं वाली असंबंधित फ़ाइलों पर अनुमतियों को बदल सकता है। OpenBSD ssh(1) मैन्युअल

पुष्टि करें कि SSH उस की (key) का उपयोग कर रहा है

एक सुधारी गई की (key) अभी भी काम न करती हुई प्रतीत हो सकती है यदि SSH कहीं और देख रहा है या कोई भिन्न पहचान (identity) प्रस्तुत कर रहा है। किसी एक कनेक्शन के लिए की निर्दिष्ट करने के लिए -i का उपयोग करें। उदाहरण खाते और होस्ट को अपने खाते और होस्ट से बदलें:

ssh -i "$HOME/.ssh/id_ed25519" user@example.com

-i विकल्प पब्लिक-की प्रमाणीकरण के लिए उपयोग की जाने वाली पहचान फ़ाइल का चयन करता है। OpenBSD ssh(1) मैन्युअल अधिक विस्तृत कनेक्शन लॉग के लिए, -v जोड़ें:

ssh -v -i "$HOME/.ssh/id_ed25519" user@example.com

यदि आप कई होस्ट प्रबंधित करते हैं, तो आप ~/.ssh/config में IdentityFile सेट कर सकते हैं; Host ब्लॉक यह निर्धारित करता है कि कौन सी कनेक्शन सेटिंग्स लागू होती हैं। क्लाइंट ssh-agent द्वारा प्रदान की गई कीज़ (keys) का भी प्रयास कर सकता है। जब किसी एजेंट के पास कई कीज़ लोड होती हैं, तो IdentitiesOnly yes कॉन्फ़िगर की गई पहचान फ़ाइलों तक प्रस्तुत पहचानों को सीमित कर सकता है। OpenBSD ssh_config(5) मैन्युअल

जानें कि त्रुटि कहीं और कब है

एक स्थानीय प्राइवेट-की अनुमति चेतावनी Permission denied (publickey) से भिन्न होती है। बाद वाले का अर्थ यह हो सकता है कि सर्वर मेल खाती पब्लिक की को नहीं पहचानता है, उपयोगकर्ता नाम गलत है, या SSH किसी अन्य पहचान का प्रयास कर रहा है। आपकी प्राइवेट की के अनुरूप पब्लिक की को रिमोट होस्ट पर खाते के लिए अधिकृत किया जाना चाहिए; स्थानीय अनुमतियों को बदलने से सर्वर पर वह पब्लिक की स्थापित नहीं होती है। OpenBSD ssh(1) मैन्युअल

यदि chmod “Operation not permitted” लौटाता है, तो जांचें कि क्या आप फ़ाइल के स्वामी हैं और क्या पथ उस की (key) की ओर इंगित करता है जो आप चाहते थे। चेतावनी को शांत करने के लिए प्राइवेट की को व्यापक रूप से पठनीय बनाने से बचें: SSH का प्रतिबंध क्रेडेंशियल की सुरक्षा करता है, और इसे हटाने से क्लाइंट की (key) को अस्वीकार कर सकता है। एक बार जब प्राइवेट की और उसकी डायरेक्टरी में उपयुक्त अनुमतियां हों, तो -v के साथ पुनः प्रयास करें और स्थानीय फ़ाइल समस्या को प्रमाणीकरण या सर्वर-साइड समस्या से अलग करने के लिए डायग्नोस्टिक आउटपुट का पालन करें।

स्रोत