मुझे सार्वजनिक कुंजी प्रमाणीकरण के साथ ssh के साथ अभी भी पासवर्ड प्रॉम्प्ट क्यों मिल रहा है?

Question

मैं यहाँ मिले URL से काम कर रहा हूँ:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

मेरे ssh क्लाइंट उबंटू 64 बिट 11.10 डेस्कटॉप है और मेरा सर्वर सेंटोस 6.2 64 बिट है। मैंने निर्देशों का पालन किया है। मुझे अभी भी ssh पर एक पासवर्ड प्रॉम्प्ट मिलता है।

मुझे यकीन नहीं है कि आगे क्या करना है।

Comments

कमांड से आउटपुट -v फ्लैग के साथ ssh को दे रहे हैं? इस pastebin.com/xxe57kxg के

— Rob

यह भी सुनिश्चित करें कि आपका .ssh फोल्डर हैchmod 700

— Rob

यह मानकर कि आपने सर्वर तक रूट एक्सेस प्राप्त कर लिया है, /var/log/auth.logआपको बताएगा कि लॉगिन विफल क्यों हो रहा है।

— यूटजार्हड

@UtahJarhead: CentOS सर्वर पर, इसमें होने की संभावना है /var/log/secure।

— डेनिस विलियमसन

दिलचस्प बात यह है कि चोमॉड 0700का जवाब था, लेकिन जब मैंने ssh -vक्लाइंट की तरफ किया, तो यह इस बात से संबंधित त्रुटि का संकेत नहीं था कि कुंजी को स्वीकार क्यों नहीं किया गया है, यह सिर्फ यह कहा कि यह पासवर्ड की कोशिश कर रहा था, भले ही मेरे क्लाइंट ने एक सार्वजनिक कुंजी भेजी हो। सर्वर से बिना किसी त्रुटि जानकारी के वे हमसे समस्याओं के निदान की अपेक्षा कैसे करते हैं?

— void.pointer

Answer 1

सुनिश्चित करें कि ~/.sshनिर्देशिका और इसकी सामग्री पर अनुमतियाँ उचित हैं। जब मैंने पहली बार अपने ssh की ऑर्ट की स्थापना की, तो मेरे पास ~/.sshफ़ोल्डर ठीक से सेट नहीं था, और यह मुझ पर चिल्लाया।

• आपकी होम निर्देशिका ~, आपकी ~/.sshनिर्देशिका और ~/.ssh/authorized_keysदूरस्थ मशीन पर फ़ाइल केवल आपके द्वारा लिखित होनी चाहिए: rwx------और rwxr-xr-xठीक हैं, लेकिन rwxrwx---कोई भी अच्छा नहीं है, भले ही आप अपने समूह में एकमात्र उपयोगकर्ता हैं (यदि आप संख्यात्मक मोड पसंद करते हैं: 700या 755, नहीं 775) ।
  यदि ~/.sshया authorized_keysएक प्रतीकात्मक लिंक है, तो कैनोनिकल पथ (प्रतीकात्मक लिंक के साथ विस्तारित) की जाँच की जाती है ।
• आपकी ~/.ssh/authorized_keysफ़ाइल (दूरस्थ मशीन पर) पठनीय (कम से कम 400) होनी चाहिए, लेकिन यदि आपको इसके लिए कोई और कुंजी जोड़ी जाएगी, तो आपको इसे लिखने योग्य (600) भी होना चाहिए।
• आपकी निजी कुंजी फ़ाइल (स्थानीय मशीन पर) केवल आपके द्वारा पठनीय और लिखने योग्य होनी चाहिए: rw-------यानी 600।
• इसके अलावा, अगर SELinux को लागू करने के लिए सेट किया गया है, तो आपको चलाने की आवश्यकता हो सकती है restorecon -R -v ~/.ssh(उदाहरण के लिए Ubuntu बग 965663 और डेबियन बग रिपोर्ट # 658675 देखें ; यह CentOS 6 में पैच किया गया है )।

¹ _{कुछ डिस्ट्रीब्यूशन (डेबियन और डेरिवेटिव) को छोड़कर जिन्होंने ग्रुप राइटिंग की अनुमति देने के लिए कोड को पैच किया है यदि आप अपने ग्रुप के एकमात्र यूजर हैं।}

Comments

रेस्ट्रोकेन को इंगित करने के लिए बहुत-बहुत धन्यवाद। मैं थोड़ी देर के लिए इस मुद्दे पर अपने सिर को खरोंच रहा हूं।

— रिचर्ड बैरेल

अजीब तरह से, मैं एक खाते के साथ समस्याओं का सामना कर रहा था जो एक मित्र ने अपने वीपीएस पर स्थापित किया था, जो कि पबकी काम कर रहा था। मैंने सोचा था कि सभी अनुमतियों को सही थे, लेकिन यह याद रखना महत्वपूर्ण है कि /home/USERहोना चाहिए 700या755

— रोब

स्वामी और समूह सेटिंग्स की जांच करने के लिए भी याद रखें, मैंने RS_NC का उपयोग एक अधिकृत_की फ़ाइल पर कॉपी करने के लिए किया और यह ध्यान नहीं दिया कि स्वामी / समूह को रूट के बजाय 1000 पर सेट किया गया था!

— नाक

इसके अलावा, अपने ssh कमांड को जोड़ने के लिए कि कुंजी के साथ क्या होता है। ssh -v user@host।

— tedder42

chmod -R 700 ~/.sshइस उत्तर की कमी को पूरा करने के लिए मेरे लिए काम किया (

— आरएचईएल

Answer 2

यदि आपके पास सर्वर तक रूट पहुंच है, तो इस तरह की समस्याओं को हल करने का आसान तरीका डिबग मोड में sshd को चलाना है, /usr/sbin/sshd -d -p 2222सर्वर पर कुछ जारी करके (sshd निष्पादन योग्य आवश्यक पथ, which sshdमदद कर सकता है) और फिर क्लाइंट से कनेक्ट करने का पूरा तरीका है ssh -p 2222 user@host। यह SSH डेमन को अग्रभूमि में रहने और हर कनेक्शन के बारे में डिबग जानकारी प्रदर्शित करने के लिए मजबूर करेगा। कुछ के लिए देखो

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

यदि वैकल्पिक पोर्ट का उपयोग करना संभव नहीं है, तो आप अस्थायी रूप से SSH डेमॉन को रोक सकते हैं और इसे डिबग मोड में एक के साथ बदल सकते हैं। SSH डेमॉन को रोकना मौजूदा कनेक्शनों को नहीं मारता है, इसलिए रिमोट टर्मिनल के माध्यम से ऐसा करना संभव है, लेकिन कुछ जोखिम भरा है - यदि किसी समय डिबग रिप्लेसमेंट नहीं चल रहा है तो कनेक्शन किसी भी तरह टूट जाता है, तो आप मशीन से लॉक हो जाते हैं जब तक आप इसे पुनरारंभ नहीं कर सकते। आवश्यक आदेश:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(आपके लिनक्स वितरण के आधार पर, पहली / अंतिम पंक्ति systemctl stop sshd.service/ systemctl start sshd.serviceइसके बजाय हो सकती है ।)

Comments

मैंने बस यह कोशिश की ... और जब मैं दौड़ रहा हूं तो यह ठीक काम करता है sshd -d, लेकिन वास्तव में एक बार चलने के बाद मैं असफल हो जाता हूं service sshd start। मुझे यकीन है कि यह सरल है, लेकिन मैं लिनक्स गुरु नहीं हूं। कोई विचार?

— एन रोहलर

संदर्भ के लिए, यह पोस्ट SELinux समाधान की व्याख्या करता है जिसने मेरी समस्या को संबोधित किया।

— एन रोहलर

मुझे काम करने के लिए सार्वजनिक कुंजी प्रमाणीकरण प्राप्त करने में भी परेशानी हो रही थी और मुझे पूरा यकीन था कि निर्देशिका की अनुमति समस्या नहीं थी। डिबग मोड में एसएसएच चलाने के बाद, मुझे जल्दी से पता चला कि मैं गलत था और अनुमतियाँ समस्याएं थीं।

— ub3rst4r

बड़ी सलाह, मेरा उपयोगकर्ता फ़ोल्डर गलत अनुमतियों के साथ था।

— gdfbarbosa

धन्यवाद। सभी कारणों से, मेरे उपयोगकर्ता को लॉग इन करने की अनुमति नहीं थी क्योंकि उपयोगकर्ता निर्माण पर ansible (/ bin / zsh) द्वारा निर्दिष्ट शेल मौजूद नहीं था। मैंने कभी अनुमान नहीं लगाया होगा।

— चिशकु

Answer 3

क्या आपका घर डीआईआर एन्क्रिप्टेड है? यदि ऐसा है, तो आपके पहले ssh सत्र के लिए आपको एक पासवर्ड प्रदान करना होगा। उसी सर्वर के लिए दूसरा ssh सत्र ऑर्टिकल कुंजी के साथ काम कर रहा है। यदि यह मामला है, तो आप अपने authorized_keysअनएन्क्रिप्टेड डायर को स्थानांतरित कर सकते हैं और पथ बदल सकते हैं ~/.ssh/config।

मैंने /etc/ssh/usernameजो किया, वह सही अनुमतियों के साथ, उपयोगकर्ता नाम का एक फ़ोल्डर बनाने वाला था , और authorized_keysफ़ाइल को वहाँ रखा । फिर इसमें दिए गए AuthorizedKeysFile निर्देश को बदल दिया /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

यह कई उपयोगकर्ताओं को अनुमतियों से समझौता किए बिना इस ssh का उपयोग करने की अनुमति देता है।

Comments

ubuntu doc ​​इसमें: help.ubuntu.com/community/SSH/OpenSSH/Keys#Troublesourcing

— Fab V.

यह उत्तर एक सलामी है और मेरी मदद की - किसी को भी आश्चर्य हो रहा है कि क्या यह मुद्दा है - आप देख सकते हैं "pam_ecryptfs: Passphrase फाइल लिपटे हुए" में अपनेभीगे पर .log; किसी भी तरह कि होमडायर को याद करने के लिए मुझे संकेत देने के लिए पर्याप्त नहीं था। इसके अलावा, आप पहले लॉगऑन को पासवर्ड के लिए पूछ सकते हैं, बाद के सत्र नहीं करते हैं (क्योंकि यह अन्य सत्र खुले रहने के दौरान डिक्रिप्टेड है)।

— शांतिवादी

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

— एच ३।

Answer 4

रिमोट मशीन की चाबियों की नकल करने और उन्हें आपके अंदर डालने के बाद authorized_keysआपको कुछ ऐसा करना होगा:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Comments

वास्तव में नहीं, तुम नहीं। ssh स्वचालित रूप से एक प्रमुख एजेंट का उपयोग किए बिना ~ / .ssh / id_rsa (या id_dsa) का उपयोग करता है।

— पैट्रिक

यह तब भी मददगार हो सकता है जब कोई ~ / .sh / config (जैसे host * .mydomain.org पर ...) एक अलग नाम की कुंजी निर्दिष्ट करना था ... IdentityFile ~ / .shsh / some_limited_use.pub - ssh-add ~ /। .ssh / some_limited_use.pub)।

— 89c3b1b8-b1ae-11e6-b842-48d705

इसने कुंजी जोड़ने के बाद पासवर्ड प्रॉम्प्ट के साथ मेरी समस्या हल कर दी है। जैसा कि 89c3b1b8-b1ae-11e6-b842-48d705 ने बताया, इन आदेशों को मैन्युअल रूप से चलाने का कारण एक कुंजी फ़ाइल का गैर-मानक नाम था।

— Михаил Лисаков

जैसा कि टिप्पणियों में ऊपर बताया गया है, यदि आप डिफ़ॉल्ट कुंजी के अलावा किसी भी कुंजी का उपयोग कर रहे हैं, तो इसे ssh एजेंट में डिफ़ॉल्ट रूप से नहीं जोड़ा जाता है। इसलिए जिस कुंजी का आप उपयोग करना चाहते हैं, उसकी जाँच एजेंट के किचेन में ज़रूर करें:ssh-add -L

— जेम्स

Answer 5

बस इन निम्नलिखित आदेशों का प्रयास करें

1. ssh-keygen

   प्रेस कुंजी दर्ज करें जब तक आप संकेत मिलता है

2. ssh-copy-id -i root@ip_address

   (यह एक बार होस्ट सिस्टम का पासवर्ड पूछेगा)

3. ssh root@ip_address

   अब आपको बिना किसी पासवर्ड के लॉगिन करने में सक्षम होना चाहिए

Comments

किस सर्वर पर?

— अमलगोविनस

@ Amalgovinus जाहिर तौर पर आप इसे क्लाइंट पर चलाते हैं, न कि मशीन जिसे आप कनेक्ट कर रहे हैं - आप सर्वर पर अपनी निजी कुंजी की कॉपी नहीं चाहते हैं! :)

— नेवलिस

कृपया ध्यान दें कि आम तौर पर, रिमोट रूट लॉगिन की अनुमति देना अनुशंसित सुरक्षा अभ्यास नहीं है।

— अरीफ

Answer 6

मुझे चुनौतियों का सामना करना पड़ा जब रिमोट पर होम डायरेक्टरी में सही विशेषाधिकार नहीं हैं। मेरे मामले में उपयोगकर्ता ने टीम के साथ कुछ स्थानीय पहुँच के लिए होम डायर को 777 में बदल दिया । मशीन किसी भी समय ssh कीज़ से कनेक्ट नहीं हो सकी। मैंने अनुमति को 744 में बदल दिया और इसने फिर से काम करना शुरू कर दिया।

Comments

हमें भी यह समस्या थी - 755 को घर की

— डायरियों को

मेरे पास 777 की अनुमति थी और इसे नजरअंदाज किया गया, धन्यवाद !!!

— ka_lin 13

मुझे भी। धन्यवाद। थोड़ी देर के लिए मेरे सिर को खरोंच रहा था, wtf हो रहा था।

— मार्सिन

हाँ जवाब यहाँ आगे विस्तार के लिए देख unix.stackexchange.com/questions/205842/...

— टिम

यह अच्छी तरह से उन लोगों के लिए जवाब हो सकता है जिन्होंने कुंजी पीढ़ी को सही ढंग से किया है, फिर भी पासवर्ड के लिए संकेत दिया जा रहा है।

— फर्जी

Answer 7

RedHat / CentOS 6 पर SELinux में प्यूबिक ऑथेंटिकेशन के साथ एक समस्या है , शायद जब कुछ फाइलें बनाई जाती हैं, तो सेलिनक्स अपने ACL को सही तरीके से सेट नहीं कर रहा होता है।

रूट उपयोगकर्ता के लिए सेलाइनक्स ACL को मैन्युअल रूप से ठीक करने के लिए:

restorecon -R -v /root/.ssh

Comments

विंडोज़ पर ssh root@mymachineओपनश क्लाइंट का उपयोग करना मैं mymachineबिना किसी समस्या के एक CentOS6 में सक्षम था , लेकिन मेरे पास एक कम-निजीकरण उपयोगकर्ता है जिसे मैं उपयोग करना पसंद करूंगा, लेकिन फिर ssh regularUser@mymachineभी मुझे पासवर्ड के लिए संकेत देता है। विचार?

— ग्रोस्तव

Answer 8

हम उसी समस्या में भाग गए और हमने उत्तर में चरणों का पालन किया। लेकिन फिर भी यह हमारे काम नहीं आया। हमारी समस्या यह थी कि लॉगिन एक क्लाइंट से काम करता था लेकिन दूसरे से नहीं (.ssh डायरेक्टरी एनएफएस माउंटेड था और दोनों क्लाइंट एक ही कुंजी का उपयोग कर रहे थे)।

इसलिए हमें एक कदम आगे जाना पड़ा। Ssh कमांड को वर्बोज़ मोड में चलाने से आपको बहुत सारी जानकारी मिलती है।

ssh -vv user@host

हमें पता चला कि डिफ़ॉल्ट कुंजी (id_rsa) स्वीकार नहीं की गई थी और इसके बजाय ssh क्लाइंट ने क्लाइंट होस्टनाम से मेल खाते एक कुंजी की पेशकश की:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

जाहिर है कि यह किसी अन्य क्लाइंट से काम नहीं करेगा।

तो हमारे मामले में समाधान डिफ़ॉल्ट rsa कुंजी को उस पर स्विच करना था जिसमें उपयोगकर्ता @ myclient शामिल था। जब कोई कुंजी डिफ़ॉल्ट होती है, तो क्लाइंट नाम के लिए कोई जाँच नहीं होती है।

फिर हम स्विच के बाद एक और समस्या में भाग गए। जाहिरा तौर पर चाबियाँ स्थानीय ssh एजेंट में कैश की जाती हैं और हमें डीबग लॉग पर निम्नलिखित त्रुटि मिली:

'Agent admitted failure to sign using the key'

यह ssh एजेंट की चाबियाँ पुनः लोड करके हल किया गया था:

ssh-add

Answer 9

यह सर्वर अंत में SSH मिस कॉन्फ़िगरेशन होगा। सर्वर साइड sshd_config फ़ाइल को संपादित करना होगा। में स्थित है /etc/ssh/sshd_config। उस फ़ाइल में, चर बदलें

• ChallengeResponseAuthentication, PasswordAuthentication, UsePAM के लिए 'हां' से 'नहीं'

• PubkeyAuthentication के लिए 'नहीं' से 'हां'

Http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/ के आधार पर

Comments

जैसा कि टिप्पणियों में सवाल / var / लॉग / सुरक्षित या /var/log/auth.log की जाँच करें। मेरे मामले में मैं देखता हूं कि "XXX से उपयोगकर्ता xxx अनुमति नहीं है क्योंकि AllowUsers में सूचीबद्ध नहीं है" "input_userauth_request: अमान्य उपयोगकर्ता xxx [उपदेश]" (और "rexec लाइन 35: अस्वीकृत विकल्प ServerKeyitsits" / var / log / संदेशों में यद्यपि मुझे पता नहीं है कि क्या है अर्थात्)। हल करने के लिए vi /etc/ssh/sshd_config, उपयोगकर्ता xxx को AllowUser सूची में जोड़ें, service sshd restart*** खराब sshd_config के साथ sshd सेवा को फिर से शुरू करना आपको एक बॉक्स से बाहर कर सकता है !? ***। वह काम किया।

— गौहिते

Answer 10

सुनिश्चित करें कि AuthorizedKeysFileसही स्थान पर इंगित करें , %uउपयोगकर्ता नाम के लिए प्लेसहोल्डर के रूप में उपयोग करें :

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

यह हो सकता है कि आपको बस लाइन को अनकंफर्ट करने की आवश्यकता हो:

AuthorizedKeysFile। Ssh / अधिकृत_कीप

मन जो परिवर्तन के लिए ssh सेवा पुनः लोड करना चाहिए:

service sshd reload

Answer 11

दो टिप्पणियाँ: यह मूल फ़ाइल को अधिलेखित कर देगा। मैं केवल सार्वजनिक कुंजी की प्रतिलिपि बनाऊंगा और कुछ ऐसा करूंगा:

cat your_public_key.pub >> .ssh/authorized_keys

यह उस कुंजी को जोड़ देगा जिसे आप पहले से मौजूद कुंजियों की सूची में उपयोग करना चाहते हैं। इसके अलावा, कुछ सिस्टम फ़ाइल का उपयोग authorized_keys2, तो यह एक अच्छा विचार है एक हार्ड लिंक के बीच की ओर इशारा करते बनाने के लिए authorized_keysऔर authorized_keys2सिर्फ मामले में,।

Comments

हाँ, मैंने देखा कि ओवरराइट के बारे में भी, लेकिन मेरे पास कोई भी नहीं था, इसलिए यह कोई फर्क नहीं पड़ा। मैंने अधिकृत_की_2 के लिए एक सिमलिंक बनाया, लेकिन इससे कोई मदद नहीं मिली।

— Thom

इसके अलावा, फ़ाइल / निर्देशिका अनुमतियों की जाँच करें। वे आपके द्वारा प्रदान की गई वेबसाइट पर वर्णित हैं।

— वोजटेक रेजेपला

आपकी ~ /। ssh dir 700 होनी चाहिए। आपकी निजी कुंजी फ़ाइल 600 होनी चाहिए, आपकी सार्वजनिक कुंजी फ़ाइल 644 होनी चाहिए। आपकी दूरस्थ फ़ाइल (दूरस्थ पर) 644 होनी चाहिए

— Rob

@Rob कि समस्या थी। यदि आप उत्तर के रूप में पोस्ट करते हैं, तो मैं इसे स्वीकार करूंगा।

— Thom

Answer 12

मेरा समाधान यह था कि खाता बंद था। संदेश / var / log / Secure में पाया गया: उपयोगकर्ता को अनुमति नहीं है क्योंकि खाता लॉक है समाधान: उपयोगकर्ता को एक नया पासवर्ड दें।

Comments

मैंने इसे /etc/shadowइस उपयोगकर्ता के लिए पासवर्ड फ़ील्ड बदलकर इसे ठीक कर दिया !है *। उसके बाद पासवर्ड प्रमाणीकरण अभी भी असंभव है, लेकिन उपयोगकर्ता अब लॉक नहीं है।

— user3132194

Answer 13

मैं एक समान समस्या में भाग गया और डिबग मोड का उपयोग करके चरणों का पालन किया।

/usr/sbin/sshd -d

यह निम्नलिखित परिणाम दिखा

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

यह वास्तव में भ्रामक था

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

यह दिखाया गया कि रूट डायरेक्टरी में हर एक के लिए अनुमति थी। हमने इसे बदल दिया ताकि दूसरों के पास अनुमति न हो।

[root@sys-135 ~]# chmod 750 /root

मुख्य प्रमाणीकरण ने काम करना शुरू कर दिया।

Comments

मेरे पास एक ही मुद्दा है। कल, मैंने rsync -av ./root/ root@THE_HOST:/rootअपने स्थानीय कामकाजी निर्देशिका से कुछ फाइलें अपलोड करने के लिए जारी किया, फिर, यह समस्या तब होती है (वास्तव में, पहली बार में मैंने इसे नोटिस नहीं किया था। अगली सुबह अन्य मेजबानों में क्रॉन की नौकरियां विफल होने के बाद, मैंने इसका कारण खोदना शुरू किया) । rsync -av ./root/ root@THE_HOST:/rootआदेश के मालिक और की अनुमति को बदल दिया /rootदूरस्थ होस्ट की निर्देशिका। अनुमति, समस्या का समाधान किया।

— लियूयान

Failed publickey for root from 135.250.24.32 port 54553 ssh2मुझे एक ही संदेश और मुद्दा मिलता है जब मैं एक होस्ट में प्यूबिक जोड़ना भूल गया authorized_keys। मेरे मामले में इस टिप्पणी को जोड़ने के रूप में, मैं आमतौर पर डिबग और सभी अनुमतियों के साथ-साथ फ़ाइलों की जाँच करने के बाद अपनी गलती का एहसास करता हूं #: o <

— tuk0z

Answer 14

/ Etc / selinux / config फ़ाइल से SELINUX को अक्षम कर दिया गया है ताकि पासवर्डलेस ssh कार्य को सफलतापूर्वक लागू किया जा सके।

पहले मैं इसे एक तरह से करने में सक्षम हूं। अब दोनों रास्ते से मैं पासवर्ड रहित ssh करने में सक्षम हूं।

Answer 15

एक चीज जो मैंने गलत की थी वह सर्वर सिस्टम पर मेरे होम डायरेक्टरी पर स्वामित्व था। सर्वर सिस्टम डिफ़ॉल्ट पर सेट था: डिफ़ॉल्ट तो I:

chown -R root:root /root

और इसने काम किया। एक और सस्ता काम है स्ट्रिक्टमोड्स को डिसेबल करना: स्टिरक्टमोड्स नं। sshd_config में। यह कम से कम आपको बताएगा कि कुंजी एक्सचेंज और कनेक्शन प्रोटोकॉल अच्छे हैं या नहीं। तब आप खराब अनुमतियों का शिकार करने जा सकते हैं।

Comments

मैं भी। संदेशों को / var / log / safe में देखें। मैंने एक संदेश देखा: "प्रमाणीकरण ने इनकार कर दिया: निर्देशिका के लिए खराब स्वामित्व या मोड" ($ HOME)। सुनिश्चित करें कि $ HOME टू ग्रुप या अन्य के लिए पहुँच नहीं है। मैंने कभी नहीं अगर मैं सर्वर से अनधिकृत रूट पहुँच नहीं था इस पाया है चाहता हूँ ....

— SoloPilot

Answer 16

मेरे लिए, समाधान Wojtek Rzepala के विपरीत था : मैंने देखा कि मैं अभी भी उपयोग नहीं कर रहा था authorized_keys2, जिसे हटा दिया गया है । मेरे ssh सेटअप ने कुछ समय पर काम करना बंद कर दिया, संभवतः जब सर्वर अपडेट किया गया था। समस्या के .ssh/authorized_keys2रूप में नाम बदलना .ssh/authorized_keys।

डी 'ओह!

Comments

यह भी / etc / ssh / sshd_config में एक कॉन्फ़िगरेशन विकल्प है, हालांकि मुझे लगता है कि मैं इसका नाम बदल दूंगा जैसे आपने किया था।

— रिक स्मिथ

Answer 17

अतीत में मुझे कुछ ट्यूटोरियल मिले जो वर्णन करते हैं कि ssh पासवर्ड-कम सेटअप कैसे प्राप्त किया जाए, लेकिन कुछ दुख की बात है।
चलो फिर से शुरू करते हैं, और हर कदम की जाँच करते हैं:

1. CLIENT से - कुंजी उत्पन्न करें: ssh-keygen -t rsa
   सार्वजनिक और निजी कुंजी ( id_rsa.pubऔर id_rsa) स्वचालित रूप से ~/.ssh/निर्देशिका में संग्रहीत की जाएगी ।
   यदि आप खाली पासफ़्रेज़ का उपयोग करते हैं तो सेटअप आसान होगा। यदि आप ऐसा करने के लिए तैयार नहीं हैं, तो फिर भी इस गाइड का पालन करें, लेकिन नीचे दिए गए बुलेट बिंदु की भी जांच करें।
   
   
2. ग्राहक से - सर्वर के लिए सार्वजनिक कुंजी की प्रतिलिपि बनाएँ : ssh-copy-id user@server
   क्लाइंट सार्वजनिक कुंजी को सर्वर के स्थान पर कॉपी किया जाएगा ~/.ssh/authorized_keys।
   
   
3. ग्राहक से - सर्वर से कनेक्ट करें:ssh user@server
   
   

अब, यदि यह वर्णित 3 चरणों के बाद भी काम नहीं कर रहा है, तो निम्नलिखित प्रयास करें:

• क्लाइंट और सर्वर मशीन ~/sshमें फ़ोल्डर की अनुमति की जाँच करें ।
• यह सुनिश्चित करने के लिए सर्वर/etc/ssh/sshd_config में जाँच करें , और विकल्प अक्षम नहीं हैं, उन्हें डिफ़ॉल्ट रूप से सक्षम किया जा सकता है ।RSAAuthenticationPubkeyAuthenticationUsePAMyes
• यदि आप पासफ़्रेज़ दर्ज की है तो अपने ग्राहक कुंजी जनरेट करते समय, तो आप कोशिश कर सकते हैं ssh-agentऔर ssh-addअपने सत्र में पासवर्ड से कम कनेक्शन प्राप्त करने के लिए।
• समस्या का पता लगाने के /var/log/auth.logलिए सर्वर पर मौजूद सामग्री की जाँच करें कि कुंजी प्रमाणीकरण क्यों छोड़ा गया है।

Comments

चरणों को सूचीबद्ध करने के लिए धन्यवाद! मुझे "ssh-copy-id यूजर @ सर्वर" मिला और एहसास हुआ कि मैंने मूल रूप से गलत सार्वजनिक कुंजी पर कॉपी किया था।

— मटावतार

Answer 18

मुझे पुटीटी के साथ उबंटू 16.04 मशीन से जुड़ने में ठीक यही समस्या थी। यह हैरान करने वाला था क्योंकि PuTTY का pscp प्रोग्राम एक ही कुंजी के साथ ठीक काम कर रहा था (और उसी कुंजी ने PuTTY में दूसरे होस्ट से जुड़ने के लिए काम किया)।

@UtahJarhead की बहुमूल्य टिप्पणी के लिए धन्यवाद, मैंने अपनी /var/log/auth.log फ़ाइल की जाँच की और निम्नलिखित पाया:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

यह पता चला है कि OpenSSH के नए संस्करण डिफ़ॉल्ट रूप से DSA कुंजियों को स्वीकार नहीं करते हैं। एक बार जब मैंने एक डीएसए से आरएसए कुंजी पर स्विच किया, तो यह ठीक काम किया।

एक और दृष्टिकोण: यह प्रश्न चर्चा करता है कि डीएसए कुंजियों को स्वीकार करने के लिए SSH सर्वर को कैसे कॉन्फ़िगर किया जाए: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Answer 19

इन चरणों को आपकी मदद करनी चाहिए। मैं कई 64 बिट Ubuntu 10.04 मशीनों के बीच नियमित रूप से इसका उपयोग करता हूं।

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

आप इसे कुछ संकेतों के साथ स्क्रिप्ट में रख सकते हैं और इसे लागू कर सकते हैं

script_name username remote_machine

Comments

पहले से मौजूद है ssh-copy-idजो अंतिम दो चरणों को स्वचालित रूप से करता है।

— जोफेल

@ जोफेल ध्यान रखें कि कई प्रणालियों में ssh-copy-id मौजूद नहीं है। @ श्रीहरि के जाने के बाद mkdirआपको chmod 700 .sshभी जोड़ना चाहिए और btw की ज़रूरत नहीं है कि आप के साथ इतनी वाचालता हो ~/.ssh, बस इतना .sshही काफी है क्योंकि आज्ञाओं को वैसे भी घर की निर्देशिका में निष्पादित किया जाता है

— Janos

Answer 20

मुझे ssh के साथ भी ऐसी ही समस्या थी। मेरे मामले में समस्या यह थी कि मैंने हडूप क्लाउडडा (आरपीएम पर सेंटोस 6 से) स्थापित किया था और इसने होम डायरेक्टरी के साथ उपयोगकर्ता एचडीएफएस बनाया

/var/lib/hadoop-hdfs(मानक नहीं /home/hdfs)।

मैं में बदल / etc / पासवर्ड /var/lib/hadoop-hdfsके लिए /home/hdfs, नई जगह पर घर निर्देशिका चले गए और अब मैं सार्वजनिक कुंजी प्रमाणीकरण के साथ जुड़ सकते हैं।

Answer 21

मेरे पास बस यही समस्या थी, और मेरे लिए समाधान निर्धारित UsePAMकरना था no। देखें, यहां तक ​​कि PasswordAuthenticationसेट के साथ no, आप अभी भी प्राप्त करेंगे keyboard-interactive, और मेरे मामले में मेरे स्थानीय ssh कार्यक्रम को किसी कारण से डिफ़ॉल्ट रखा गया।

एक ही स्थिति के साथ किसी की भी मदद करने के लिए अतिरिक्त पृष्ठभूमि: मैं एक होस्ट चला रहा हूं जो ड्रॉपबियर से एक रनिंग ओपनएसएसएच से चल रहा है। दूरस्थ मशीन पर सेट PasswordAuthenticationऔर UsePAMदोनों के साथ no, अगर मैं दर्ज करूँ तो मुझे निम्नलिखित संदेश मिलेगा ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

पहचान फ़ाइल प्रदान करना -i, सब कुछ उम्मीद के मुताबिक काम करता है।

यहां थोड़ी और जानकारी हो सकती है।

Answer 22

अनुमतियों की जांच करने के बाद, और यहां सूचीबद्ध कई अन्य समाधानों की कोशिश करने के बाद, मैंने अंततः सर्वर पर ssh निर्देशिका को हटा दिया, सेटअप को फिर से मेरी सार्वजनिक कुंजी।

सर्वर आदेश:

# rm -rf ~/.ssh

स्थानीय कमांड:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Answer 23

सर्वर पर:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

यह था directory permission issue। यह सर्वर पर 777 था, इसलिए I changed it back to 700। सर्वर पर कॉपी करने के बाद भी यह fixedमेरा मुद्दा है ।ssh password less login failure$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

Comments

यह भी देखें daveperrett.com/articles/2010/09/14/ssh-authentication-refused

— Olumide

Answer 24

फिर भी एक अन्य विकल्प @ जगदीश के उत्तर का एक प्रकार है : stracessh डेमॉन के लिए।

इसका महत्वपूर्ण लाभ है, कि हमें sshd को रोकने की आवश्यकता नहीं है, अगर कुछ बुरी तरह से हो जाता है तो एक पूर्ण तालाबंदी का क्या परिणाम हो सकता है।

सबसे पहले, हम मुख्य sshd प्रक्रिया के pid पाते हैं। यहाँ हम इसे निष्पादित करके देख सकते हैं a pstree -pa|less।

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

यह जानने के बाद, कि पिड 633 है, हम straceइसके बच्चों का पालन कर सकते हैं :

strace -p 633 -s 4096 -f -o sux

इसका परिणाम यह होगा कि सब कुछ जो इस sshd, और इसके बच्चे की प्रक्रियाओं ने किया है, suxस्थानीय निर्देशिका में नामित फ़ाइल में स्ट्रेस-एड होगा ।

फिर समस्या को पुन: पेश करें।

इसमें कर्नेल कॉल लॉग की एक विशाल सूची होगी, जो कि हमारे लिए ज्यादातर असाध्य / अप्रासंगिक है, लेकिन हर जगह नहीं। मेरे मामले में, यह महत्वपूर्ण बात थी:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

इसका मतलब था, कि sshd ने उस संदेश को लॉग इन करने की कोशिश की, जिसे उपयोगकर्ता cica ने अनुमति नहीं दी क्योंकि खाता बंद है - यह केवल नहीं कर सकता, क्योंकि लॉगिंग उसके लिए पर्याप्त क्रिया नहीं है। लेकिन हम पहले से ही जानते हैं, पब को अस्वीकार कर दिया गया था क्योंकि खाता बंद था।

यह अभी तक एक समाधान नहीं है - अब हमें Google की जरूरत है, जो sshd के मामले में "लॉक खाता" है। यह सबसे अधिक संभावना है कि कुछ तुच्छ /etc/passwd, /etc/shadowजादूगर हो जाएगा, लेकिन महत्वपूर्ण बात यह है - समस्या एक रहस्यमय नहीं है, लेकिन एक आसानी से बहस योग्य / googlable है।

Answer 25

मेरे मामले में मेरे पास सभी अनुमतियाँ सही थीं और यहां तक ​​कि sv -vv फ्लैग के साथ ssh को चलाने पर मुझे पता नहीं चल सका कि समस्या क्या थी।

इसलिए मैंने रिमोट होस्ट पर नया सर्टिफिकेट तैयार किया

ssh-keygen -t rsa -C "[e-mail]"

और स्थानीय मशीन पर जनरेट की गई कुंजियों की प्रतिलिपि बनाई गई और दूरस्थ होस्ट पर ~ / .sh / अधिकृत_की में नई सार्वजनिक कुंजी जोड़ी गई

cat id_rsa.pub >> authorized_keys

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

Answer 26

मेरा परिदृश्य यह था कि मेरे पास एक एनएएस सर्वर है जिस पर मैंने backupbotअपना प्राथमिक खाता बनाने के बाद एक उपयोगकर्ता बनाया था, जो शुरू में backupbotउपयोगकर्ता बनाने के लिए लॉग इन करने में सक्षम था । के साथ fiddling sudo vim /etc/ssh/sshd_config, और backupbotउपयोगकर्ता बनाने के बाद vim, कम से कम Ubuntu 16.04 पर बना सकते हैं, और आपके ~/.vimrcकॉन्फ़िगरेशन के आधार पर, आपके स्वैप सत्र के संपादन से बचे हुए एक स्वैप फ़ाइल/etc/ssh/sshd_config ।

यह देखने के लिए जांचें कि क्या /etc/ssh/.sshd_config.swpमौजूद है : और यदि यह इसे हटा देता है और sshdडेमॉन को पुनरारंभ करता है :

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

इसने जादुई रूप से मेरी समस्या को हल कर दिया। मैंने पहले अपनी सभी अनुमतियों और यहां तक ​​कि सार्वजनिक और निजी कुंजियों के RSA फ़िंगरप्रिंट की जाँच की थी। यह अजीब और शायद एक बग है sshd, विशेष रूप से इस संस्करण के साथ:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 मार्च 2016