110

मैं अपने लोकल मशीन से भी एक लाइनकोड (Ubuntu 12.04 LTS पर चलने वाला) कनेक्ट करने की कोशिश कर रहा हूं (Ubuntu 12.04 LTS भी चला रहा हूं)

मैंने अपनी स्थानीय मशीन पर एक निजी और सार्वजनिक कुंजी बनाई है और अपनी सार्वजनिक कुंजी को मेरे लिनोड की अधिकृत_की फ़ाइल में कॉपी किया है। हालाँकि, जब भी मैं अपने Linode को ssh करने की कोशिश करता हूँ मुझे त्रुटि संदेश मिलता है Permission denied (publickey)।

यह मेरे लिनोड पर ssh की स्थापना कैसे की जाती है, इसके बारे में कोई समस्या नहीं है क्योंकि मैं इसे अपने विंडोज मशीन से कुंजी प्रमाणीकरण का उपयोग करके ssh कर सकता हूं।

.sshमेरी स्थानीय उबंटू मशीन पर मेरी निर्देशिका में, मेरे पास id_rsaऔर id_rsa.pubफाइलें हैं। क्या मुझे अपनी स्थानीय मशीन पर एक अधिकृत_की फ़ाइल बनाने की आवश्यकता है?

संपादित करें: यह वही है जो मुझे चलाने पर मिलता है ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

server permissions ssh

— Pattle
स्रोत

4

1) एसएसएच सर्वर पर लॉग्स उस समय के बारे में क्या कहते हैं जब आपके पास क्लाइंट पर यह त्रुटि है? ( /var/log/auth.log२) आपने सार्वजनिक कुंजी को सर्वर पर कैसे स्थानांतरित किया? हमेशा ssh-copy-idअनुमतियों के बारे में सुनिश्चित करने के लिए उपयोग करें। आपकी होम निर्देशिका, .sshनिर्देशिका और authorized_keysफ़ाइल की सख्त अनुमति आवश्यकताएँ हैं। (देखें sshd(8) का मैनपेज ~/.ssh/authorized_keys) 3) क्या आपने उबंटू पर एक नया कीपर बनाया? यदि आपने विंडोज से कुंजी का पुन: उपयोग किया है - तो आपको इसे पहले ओपनएसएसएच प्रारूप में बदलना होगा।

— gertvdijk

1

कमांड होना चाहिए था ssh -vvv -i .ssh/id_rsa ....(id_rsa के लिए पथ पर ध्यान दें!) - कृपया बदलें - पुराना लॉग केवल दिखाता है कि "हम" के पास भेजने के लिए कोई pubKey नहीं था।

— गुंटबर्ट

@guntbert मैं .ssh से चूक गया क्योंकि मैं पहले से ही .ssh निर्देशिका में था। मैंने इसे .ssh / id_rsa के साथ भी आज़माया था, लेकिन मुझे एक ही परिणाम मिला

— 11

मैं देख रहा हूं, इसलिए मैं गलत समझ रहा हूं - कृपया @gertvdijk से सवालों के जवाब दें।

— गुंटबर्ट

क्या कोई stackoverflow.com/questions/51254328/unable-to-ssh-to-bitbucket पर टिप्पणी कर सकता है, मुझे भी इसी तरह की समस्या है।

— मृण्मय कालिता

90

PubKeyAuthentication

अपना क्लाइंट सेट करें

अपनी कुंजी उत्पन्न करें
- ssh-keygen
कुंजी का उपयोग करने के लिए ssh कॉन्फ़िगर करें
- vim ~/.ssh/config
अपनी कुंजी को अपने सर्वर पर कॉपी करें
- ssh-copy-id -i /path/to/key.pub SERVERNAME

चरण 2 से आपकी कॉन्फ़िग फ़ाइल में निम्नलिखित के समान कुछ होना चाहिए:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

आप IdentitiesOnly yesयह सुनिश्चित करने के लिए जोड़ सकते हैं कि प्रमाणीकरण के दौरान और कोई अन्य कीफ़ाइल्स sshका उपयोग IdentityFileन हो, जिससे समस्या हो सकती है और यह एक अच्छा अभ्यास नहीं है।

समस्या निवारण

"-vvv" विकल्प का उपयोग करें
सुनिश्चित करें कि सर्वर के पास आपकी सार्वजनिक कुंजी (.pub) है।
सुनिश्चित करें कि आपकी पहचान कुंजी आपकी निजी कुंजी को इंगित करती है।
सुनिश्चित करें कि आपकी .ssh निर्देशिका में 700 हैं और आपकी फ़ाइलें 700 अनुमतियाँ हैं (rwx ------)।
tail -f /var/log/auth.log (सर्वर पर) और लॉगिन करने का प्रयास करते समय त्रुटियों की निगरानी करें
यदि आपके पास कई महत्वपूर्ण फाइलें हैं, IdentitiesOnly yesतो एकल, निर्दिष्ट कुंजी का उपयोग करने के लिए प्रमाणीकरण को सीमित करने का प्रयास करें।

— earthmeLon
स्रोत

1

FYI करें, मैंने github.com/centic9/generate-and-send-ssh-key पर एक छोटी सी स्क्रिप्ट बनाई जो एक ही बार में आवश्यक कदम उठाती है और इसके साथ ही सभी फ़ाइल / निर्देशिका अनुमतियों को सुनिश्चित करती है जिससे मुझे हमेशा सिरदर्द होता है ...

— centic

1

बस चरण 2 को विस्तृत करने के लिए: IdentityFile~ / .ssh / config में लाइन को निजी कुंजी को इंगित करना चाहिए।

— डैनी शूमैन

वास्तव में ।

— EarthmeLon

3

मुझे आश्चर्य है कि आप चरण 4 में अनुमति निष्पादित करने के लिए फाइलें क्यों सेट करना चाहते हैं?

— टोड वाल्टन

यह प्रति उपयोगकर्ता बहुत महत्वपूर्ण सही अनुमतियाँ हैं (chown और chmod का उपयोग करें) अन्यथा आपको एक प्रमाणीकरण से इनकार कर दिया जाएगा भले ही आपके सर्वर में आपकी सार्वजनिक कुंजी हो।

— joseluisq

61

कभी-कभी समस्या अनुमति और स्वामित्व से आती है। उदाहरण के लिए, यदि आप रूट के रूप में लॉग इन करना चाहते हैं /root, .sshऔर authorized_keysरूट से संबंधित होना चाहिए। अन्यथा, sshd उन्हें नहीं पढ़ पाएगा और इसलिए यह नहीं बता पाएगा कि उपयोगकर्ता लॉग इन करने के लिए अधिकृत है या नहीं।

अपने घर निर्देशिका में:

chown -R your_user:your_user .ssh

अधिकारों के लिए, 700 के लिए .sshऔर 600 के लिए जाओauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

— Buzut
स्रोत

1

इस जवाब से मुझे मदद मिली। मैंने इस पोस्ट से सलाह ली थी और authorized_keysअपनी एन्क्रिप्टेड होम डायरेक्टरी के बाहर अपनी फाइल स्थानांतरित कर दी थी । ऐसा करने में, मैंने अनजाने में स्वामित्व बदल दिया था root:root।

— जॉर्डन ग्रांट

काश मैं दो बार उत्थान कर सकता, एक बार फ़ोल्डर के लिए और एक बार फ़ाइल के लिए। बहुत महत्वपूर्ण है कि अनुमतियाँ सटीक हैं।

— श्री ग्रिवर

हाँ, यह सभी के साथ अनुमतियाँ थी।

— a3y3

इस एक ने मेरे मुद्दे को हल किया, इसके लिए धन्यवाद।

— sathiyarajan

14

आपको authorized_keysअपने ग्राहक की आवश्यकता नहीं है ।

आपको वास्तव में आपके द्वारा बनाई गई कुंजी का उपयोग करने के लिए ssh-client को बताना होगा। ऐसा करने के कई तरीके हैं। बस परीक्षण प्रकार के लिए ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]। आपको हर बार अपना पासफ़्रेज़ प्रदान करना होगा जो आप सर्वर से कनेक्ट करना चाहते हैं।

अगर है कि आप के लिए महत्वपूर्ण जोड़ सकते हैं काम ssh-agentके साथ ssh-add .ssh/id_rsa(आप केवल एक बार इस बात के लिए पासफ़्रेज़ प्रदान करना होगा और यह जब तक आप लॉगआउट नहीं है के रूप में काम करना चाहिए / रिबूट)

— guntbert
स्रोत

आपकी मदद के लिए धन्यवाद, मैंने अपने उत्तर को यह दिखाने के लिए संपादित किया है कि जब मैं टाइप करता हूं तो आप क्या सुझाव देते हैं।

— मोती

2

क्लाइंट पर एक कुंजी स्थानांतरित करने के लिए, ssh-copy-id

— Panther

@ bodhi.zazen धन्यवाद, लेकिन मैंने पहले ही कुंजी को स्थानांतरित कर दिया है, यह समस्या नहीं है

— मवेशी

4

"आपको ssh-client को वास्तव में आपके द्वारा बनाई गई कुंजी का उपयोग करने के लिए कहना चाहिए।" नहीं, डिफ़ॉल्ट रूप से यह डिफ़ॉल्ट पथ में कुंजी के लिए दिखेगा, उदा ~/.ssh/id_rsa। इसके अलावा, एक मुख्य एजेंट का उपयोग पूरी तरह से वैकल्पिक है और इस मुद्दे पर असंबंधित है जहां तक मैं देख सकता हूं।

— gertvdijk

@gertvdijk, आप यहाँ ऐसी धारणाएँ बना रहे हैं जो अभी तक तथ्यों से समर्थित नहीं हैं - हमें नहीं पता कि सिस्टम पर क्या हुआ है।

— गुंटबर्ट

10

इसके अलावा के मूल्य की जाँच PasswordAuthenticationमें /etc/ssh/sshd_configऔर अगर यह noयह करने के लिए बदल yes। उसके बाद ssh सर्विस को रीस्टार्ट करना न भूलें।

— ईमान
स्रोत

4

ओपी पासवर्ड प्रमाणीकरण का उपयोग करने की कोशिश नहीं कर रहा है। उनके पास कुछ समझदारी है और वे सार्वजनिक / निजी कुंजी का उपयोग कर रहे हैं।

— सीटीएल-एल्ट-डेलोर

9

मेरे पास जो समस्या थी वह क्लाइंट पर गलत कुंजी का उपयोग करने की थी। मैंने कुछ और नाम id_rsa और id_rsa.pub का नाम बदल दिया था। आप या तो उन्हें उनके डिफ़ॉल्ट पर वापस नामांकित कर सकते हैं, या जब आप ssh कमांड जारी करते हैं, तो इसे इस तरह से उपयोग करें

ssh -i ~/.ssh/private_key username@host

— टोड
स्रोत

1

नहीं, सार्वजनिक कुंजी का उपयोग करें

— St3an

@ St3an आप सर्वर पर सार्वजनिक कुंजी डालते हैं, लेकिन जब आप टोड की तरह जुड़े हुए हैं तो यहां ऊपर है, आप अपनी निजी कुंजी का उपयोग करते हैं

— नाथन एफ।

@NathanFiscaletti आपको अपनी निजी कुंजी को कभी उजागर नहीं करना चाहिए, इसीलिए यह निजी है। निजी कुंजी का उपयोग आपके स्थानीय ssh एजेंट द्वारा यह जांचने के लिए किया जाता है कि आप वास्तव में एक सार्वजनिक कुंजी देते हैं जो आपके निजी से मेल खाती है। मशीनों के बीच SSH एजेंट फिर गारंटी दे सकते हैं कि उपयोगकर्ता वे हैं जो वे होने का दिखावा करते हैं :-)

— St3an

1

ठीक ठीक। यही कारण है कि जब आप कनेक्ट करते हैं, तो आप ssh-client को अपनी निजी कुंजी प्रदान करते हैं। सर्वर आपकी सार्वजनिक कुंजी संग्रहीत करता है। ऊपर दिए गए पोस्ट में कमांड बिल्कुल वैसी ही है जैसे निजी कुंजियों का उपयोग किया जाना चाहिए।

— नाथन एफ।

7

यह भी सुनिश्चित करें कि उपयोगकर्ता की होम डायरेक्टरी (सर्वर पर) वास्तव में उपयोगकर्ता के पास ssh'ing है (जो मेरे मामले में रूट: रूट पर सेट है)।

होना चाहिये था:

sudo chown username:username /home/username;

— दुलारना
स्रोत

मैं अपने स्थानीय लिनक्स बॉक्स (उदाहरण के लिए एबीसी) पर उपयोगकर्ता के साथ सार्वजनिक / निजी कुंजी के साथ ssh करने में सक्षम हूं, दूरस्थ सर्वर पर उपयोगकर्ता से अलग (जैसे def@123.456.789)। मुझे बस यह सुनिश्चित करना था कि स्थानीय उपयोगकर्ता के पास स्थानीय .ssh फ़ाइलों का स्वामित्व हो (उदाहरण के लिए abc: abc, root नहीं: abc) `

— Michael

इसने मेरे मामले में काम किया

— Zerquix18

3

मैं हाल ही में अपने वेब सर्वर के साथ इस मुद्दे पर भागा।

मैं आमतौर पर अपने सभी सर्वरों में अधिकृत कुंजी की एक सूची रखता हूँ ~/.ssh/authorized_keys2। मेरे अनुभव से, डिफ़ॉल्ट रूप से या के sshdलिए दिखेगा ।~/.ssh/authorized_keys~/.ssh/authorized_keys2

मेरे वेबसर्वर के मामले में, /etc/ssh/sshd_configयह रेखा थी

AuthorizedKeysFile    %h/.ssh/authorized_keys

के बजाय

AuthorizedKeysFile    %h/.ssh/authorized_keys2

मैंने बाद को लागू किया, अपने ssh डेमॉन को फिर से शुरू किया, और अपने pubkey का उपयोग करके ssh के साथ लॉगिंग में मेरी समस्या को हल किया।

— जस्टिन सी
स्रोत

बहुत बहुत धन्यवाद, इसने मुझे यह पता लगाने में मदद की कि यह रेखा पूरी तरह से विन्यास से बाहर टिप्पणी की गई थी!

— क्रिश्चियन डी।

2

एक और संभावित कारण AllowedUsersकॉन्फ़िगरेशन में हो सकता है /etc/ssh/sshd_conf। ध्यान दें: जैसा कि मैंने कठिन तरीका सीखा है, सूची अंतरिक्ष सीमांकित है (अल्पविराम नहीं)।

AllowUsers user1 user2 user3

— cmbind55
स्रोत

1

यदि अन्य सभी विफल रहे, तो जांचें कि आपका लॉगिन उपयोगकर्ता ssh के AllowedGroup का है। अर्थात्, आपके उपयोगकर्ता /etc/ssh/sshd_configसर्वर पर निम्न पंक्ति में दिखाए गए समूह के सदस्य हैं :

AllowGroups ssh #Here only users of 'ssh' group can login

— biocyberman
स्रोत

1

मेरा मामला है, ग्राहक ubuntu 14.04lts है, सर्वर 2012 सर्वर cygwin चल जीत रहा था। मैं 'ssh एडमिनिस्ट्रेटर @ xxxx' का उपयोग कर रहा था, जब 2012 में सर्गविन में सर्वर डायरेक्टरी / होम / एडमिनिस्ट्रेटर था। इसलिए यह संवेदनशील था, जब मैंने 'ssh एडमिनिस्ट्रेटर @ xxxx' की कोशिश की (एडमिनिस्ट्रेटर पर राजधानी ए नोट करें) तो यह ठीक काम कर गया।

'उपयोगकर्ता नहीं मिला' जैसे एक त्रुटि संदेश ने मुझे 'अनुमति से वंचित (publickey, कीबोर्ड-इंटरैक्टिव)' की तुलना में बहुत तेजी से समाधान के लिए प्रेरित किया।

— केंट
स्रोत

किसी को ssh प्रोजेक्ट के साथ एक समस्या को लॉग इन करना चाहिए जो सुझाव दे। मैं इसी तरह के मुद्दे पर भाग गया।

— बेन क्रेसी 11

1

मैं एक ही मुद्दा था जब एक नियमित उपयोगकर्ता (उदाहरण के लिए johndoe) की नकल करते हुए एक सार्वजनिक cPanel Centos सिस्टम से AWS पर उबंटू सर्वर पर। जैसा कि ऊपर gertvdijk द्वारा सुझाया गया है, मैंने जाँच की /var/log/auth.logऔर सुनिश्चित किया कि यह पर्याप्त है Authentication refused: bad ownership or modes for directory /home/johndoe। यह बताता है कि /home/johndoeजब मैं /home/johndoe/public_htmlapache2 के लिए डिफ़ॉल्ट virtualhost दस्तावेज़ रूट के रूप में सेट करने की कोशिश कर रहा था, तो यह गलत तरीके से 777'ed था (यह उस कार्य के लिए भी आवश्यक नहीं है)।

यहां और यहां के जवाब भी देखें

सर्वर के लिए केवल सार्वजनिक कुंजी होना आवश्यक है .ssh/authorized_keysऔर क्लाइंट (जिस कंप्यूटर पर आप काम कर रहे हैं) के लिए निजी कुंजी (.pem, या यदि फाइलज़िला, .ppk के साथ SFTP का उपयोग करना आवश्यक है) है।

— site80443
स्रोत

1

मेरे जैसे पोटी यूज़र्स जो इस धागे में आए हैं, आपको यह त्रुटि भी मिल सकती है यदि आप उपयोगकर्ता @ @ IP जोड़ना भूल गए हैं!

दूसरों को कुंजी फ़ाइल पर अनुमति दी जा रही है chmod 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file

— एलेक्स पुन्नन
स्रोत

1

यह वही है जो मेरे लिए काम करता है, फिक्स मेरा नहीं है, लेकिन मैं इसे यहां लिखूंगा अगर किसी और को एक ही समस्या है।

मूल लेखक ने इसे यहां पोस्ट किया है: डिजिटल-महासागर-सार्वजनिक-पहुंच-कुंजी-अस्वीकृत

sudo nano /etc/ssh/sshd_config

इसे बदलें

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

इसके साथ

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

फ़ाइल सहेजें और ssh को पुनरारंभ करें

reload ssh

ssh को अब पासवर्ड पूछकर काम करना चाहिए

— मौ
स्रोत

1

मुझे प्रश्न में वर्णित के रूप में एक ही समस्या थी। ssh -vvv -i id_rsa [youruser]@[yourLinode]क्लाइंट मशीन पर निष्पादित करने से आउटपुट प्रश्न में वर्णित के समान था। मैंने अन्य उत्तर में सलाह के अनुसार सभी फ़ाइल और निर्देशिका अनुमतियों की जाँच की, और वे सही थे।

यह पता चला है कि जब जनरेट की गई फाइल id_rsa.pubको सर्वर मशीन में कॉपी करते हैं , फाइल के रूप में ~username/.ssh/authorized_keys, मैं गलती से शब्द ssh-rsaको शुरू से छोड़ देता था । इसे जोड़ने से समस्या हल हो गई।

— तेमू लीस्टी
स्रोत

1

उबंटू 16.04 पर भी काम करता है।

समस्या sshd_configफ़ाइल के भीतर है

यहाँ अलग समाधान है:

एक रूट के रूप में आप के लिए Ubuntu सर्वर के रूप में लॉग इन करें

vi /etc/ssh/sshd_config

अब बहुत नीचे जाएं और मूल्य को "नहीं" से "हां" में बदलें।

इसे ऐसा दिखना चाहिए:

ट्यून किए गए स्पष्ट पाठ पासवर्ड को अक्षम करने के लिए नहीं में बदलें

PasswordAuthentication yes
service sshd reload

प्रभावी बनाना।

अब आप बस अपने LOCAL मशीन (उर्फ लैपटॉप आदि) से कमांड का उपयोग करके एक कुंजी ले सकते हैं

तो नई टर्मिनल विंडो खोलें और सर्वर में लॉग इन न करें, बस यह कमांड डालें:

ssh-copy-id john @ serverIPAddress

(अपने उपयोगकर्ता नाम के साथ जॉन बदलें)।

आपको जाना चाहिए

— गैलापागोस
स्रोत

1

कुछ लोग सोच रहे थे कि ssh एक्सेस को केवल रूट अकाउंट पर ही रखा जा सकता है, फिर एक नया उपयोगकर्ता बनाया और महसूस किया कि उन्हें इसकी आवश्यकता नहीं है

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

फिर पुनः प्रयास करें। [उपयोगकर्ता] को अपने नए उपयोगकर्ता खाते से बदलें।

जब आप सेटअप पर ssh-keys का उपयोग करते हैं तो DigitalOcean पर एक नया सर्वर सेट करते समय यह आम है।

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

— LpLrich
स्रोत

0

मेरे मामले में .sshएक पुरानी मशीन से एक निर्देशिका से अधिक कॉपी करने के कारण समस्या हुई थी । यह बताता है कि मेरे पुराने SSH कॉन्‍फ़िगरेशन DSA कुंजियों का उपयोग कर रहे थे जो तब से हटाए गए हैं । चाबियों की एक नई जोड़ी पर स्विच करना, इस बार RSA- आधारित, ने मेरे लिए समस्या हल कर दी।

— Glutanimate
स्रोत

0

निम्न विधि काम कर सकती है यदि आप मशीनए और मशीनबी को स्वतंत्र रूप से एक्सेस कर सकते हैं (जैसे मशीनसी से)।

यदि ssh-copy-id काम नहीं कर रहा है, तो पासवर्ड प्रमाणीकरण को अक्षम किया जा सकता है। निम्नलिखित एक वैकल्पिक हल है ।

मशीनबी की अधिकृत कुंजी (यानी ~ / .ssh / अधिकृत_की) में मशीनए की सार्वजनिक कुंजी होने से आप मशीनए से एसएसएच कर सकेंगे। यह बात scp पर भी लागू होती है।

का उपयोग कर प्रमुख जोड़े उत्पन्न करने के बाद: ssh-keygen

पर machineâ , निष्पादितcat ~/.ssh/id_rsa.pub

नमूना उत्पादन:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

मुद्रित कुंजी (कॉपी ⌘ Command+ C, या CRTL+ C) तो ~ / .ssh / authorized_keys पर फ़ाइल में जोड़ने machineB ।

उदाहरण के लिए, मशीनबी पर निम्नलिखित को निष्पादित करें :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys

— anask
स्रोत

SSH अनुमति से इनकार (publickey)

PubKeyAuthentication

अपना क्लाइंट सेट करें

समस्या निवारण