अधिकृत_की के काम के साथ ssh के माध्यम से स्वचालित प्रवेश क्यों नहीं होगा?

12

मैंने एक निजी / सार्वजनिक dsa-keypair बनाया है। मैंने सर्वर पर सार्वजनिक कुंजी डाल दी है

~/.ssh/authorized_keys

सब कुछ मेरे अन्य सर्वर की तरह सेट किया गया है, लेकिन ऐसा लगता है कि सर्वर सिर्फ मेरे प्रयासों की अनदेखी कर रहा है।

security ssh login

— Magnar
स्रोत

जाँचें /etc/ssh/ssh_configऔर /etc/ssh/sshd_configसत्यापित करें कि आप जो कुछ भी चाहते हैं वह अक्षम है।

— क्रिस्टोफर जॉनसन

आप sshd_config को भी चेक करना चाहेंगे।

— वागनर

धन्यवाद। मैंने उत्तर अपडेट किया (जो मूल रूप से केवल ssh_config का उल्लेख करता है)।

— क्रिस्टोफर जॉनसन

उपरोक्त सभी चर्चाएँ एकदम सही हैं यदि आप ssh की ओपनशश शैली का उपयोग कर रहे हैं। यदि आप सिस्टम ssh2 का उपयोग कर रहे हैं, तो इसमें कुंजियों के प्रबंधन के लिए पूरी तरह से निराला तरीका है। इस लेख में व्हाट्स और व्हाट्स पर चर्चा की गई है। burnz.wordpress.com/2007/12/14/...

— क्रिस

1

आमतौर /var/log/auth.logपर डेबियन सिस्टम या /var/log/secure

— रेडहैट

15

हालाँकि आपकी समस्या पहले से ही अन्य उत्तर से हल हो गई है, लेकिन मैंने अपने आप को पर्याप्त मशीनों से बंद कर दिया है ताकि sshd_config बदलावों को मान्य नहीं किया जा सके इसलिए हस्ताक्षर करने से पहले नीचे की प्रक्रिया के साथ आए जो कि sshd config बदलावों के भविष्य के डीबगिंग के लिए उपयोगी हो सकते हैं।

जब तक आप अपेक्षा के अनुसार व्यवहार को सत्यापित नहीं कर लेते हैं, तब तक एक सक्रिय ssh कनेक्शन को डिस्कनेक्ट न करें।

ए। सत्यापित करें कि आप क्या सोचते हैं कि sshd क्या करना चाहिए

ख। कॉन्फ़िगरेशन सत्यापित करें "-t" का उपयोग करके मान्य है

सी। सर्वर के एक वर्बोज़ 'टेस्ट' संस्करण को शुरू करें जिसे आप मॉनिटर कर सकते हैं

घ। एक वर्बोज़ 'टेस्ट' क्लाइंट कनेक्शन शुरू करें जिसे आप मॉनिटर कर सकते हैं

ए। सत्यापित करें कि आप क्या सोचते हैं कि sshd क्या करना चाहिए

सभी कमेंट्री के बिना sshd विन्यास फाइल की समीक्षा करें जैसे नीचे कुछ (sshd_config मानकर) सही फ़ाइल और / etc / ssh में है

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

यह सिर्फ चीजों को साफ करता है इसलिए हम यह सत्यापित करते हैं कि हम क्या सोचते हैं कि हम बदल रहे हैं (जरूरी नहीं कि यह सही है या नहीं।)

ख। कॉन्फ़िगरेशन सत्यापित करें "-t" का उपयोग करके मान्य है

मैं उपयोग कर रहा हूँ sshd के आदमी पृष्ठ से,

-t टेस्ट मोड। केवल कॉन्फ़िगरेशन फ़ाइल की वैधता और कुंजियों की शुद्धता की जांच करें। यह sshd को विश्वसनीय रूप से अपडेट करने के लिए उपयोगी है क्योंकि कॉन्फ़िगरेशन विकल्प बदल सकते हैं।

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

सी। सर्वर के एक वर्बोज़ 'टेस्ट' संस्करण को शुरू करें जिसे आप मॉनिटर कर सकते हैं

$ sudo / usr / sbin / sshd -ddd -p 9999

यह आपके मौजूदा, कामकाजी सत्र को सक्रिय रखता है, लेकिन आपको अपने नए कॉन्फ़िगरेशन परिवर्तनों को सत्यापित करने के लिए sshd का एक और उदाहरण देता है। SSHD अब एक उपयोगकर्ता-परिभाषित पोर्ट (हमारे उदाहरण में 9999) के अग्रभाग में चल रहा है और शोरगुल डिबग की बहुत सारी जानकारी को धक्का दे रहा है जिसे आप / var / log / schemlog (या संभवतः /var/log/auth.log में ट्रैक कर सकते हैं) आपके ओएस पर।)

घ। एक वर्बोज़ 'टेस्ट' क्लाइंट कनेक्शन शुरू करें जिसे आप मॉनिटर कर सकते हैं

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

$ ssh -vvv -p 9999 सर्वर-नाम

अब आपको सर्वर की लॉग फ़ाइलों, या क्लाइंट की कनेक्शन स्क्रीन में आपकी समस्या को अलग करने के लिए पर्याप्त जानकारी होनी चाहिए।

समाधान आम तौर पर फाइल की अनुमति के लिए नीचे आता है (जैसा कि मैगनर और सेटाकाशी द्वारा दिखाया गया है)

शुभकामनाएँ

— Samt
स्रोत

मुझे लगता है कि आपको यह सुनिश्चित करने के लिए क्लाइंट एंड पर ssh_config फ़ाइल की भी जांच करनी चाहिए कि आप क्या उम्मीद कर रहे हैं। नीचे grep टिप्पणियों के लिए नीचे की तरह कुछ का उपयोग करें:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— samt

ठीक है, क्लाइंट ssh कॉन्फ़िगरेशन को कभी भी तय किया जा सकता है, यह सर्वर है जिसे आप गलत तरीके से कॉन्फ़िगर करने पर लॉक हो जाते हैं।

— सोविएरो

33

यदि स्वामी गुण गलत हैं, तो सर्वर आपकी अधिकृत_की फ़ाइल को अनदेखा कर देगा। इसे बदलकर इसे ठीक करता है:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
स्रोत

6

ssh -vvv -l यूजरनेम server.domain आपको बताएगा कि क्या आपकी वैध कुंजी भेजना है

— डेव चेनी

कभी-कभी मैंने घर की निर्देशिका पर खराब अनुमतियों के बारे में शिकायत करने के लिए sshd देखा है - इसलिए मैं सूची में "चमाड ओ-आरएक्सएक्स ~" (या कम से कम "चामोद ओउ ~") को जोड़ दूंगा जैसा कि सेत्थाक्षी ने किया था। यह आमतौर पर स्पष्ट हो जाता है जब लॉगफ़ाइल की निगरानी की जाती है - मैंने जो त्रुटि संदेश देखा है, वह हमेशा सही दिशा में इंगित होता है।

— ओलाफ

यह उत्तर सबसे अधिक संभावना है, लेकिन डेव चेनी की टिप्पणी यह देखने का एकमात्र तरीका है कि वास्तव में क्या चल रहा है। सर्वर लॉग की भी जांच करें।

— dwc

यह मेरी समस्या थी। मैंने इस पर अपना सिर घंटों तक पीटा। बहुत बहुत धन्यवाद!

— सैम सोफेस

1

इस चाल किया था, लेकिन मेरे पिछले अनुमतियाँ थे 0775और 0644क्रमशः। अनुमतियों को कम करने में मदद क्यों की? क्या यह सुरक्षा एहतियात है जो कहीं कॉन्फ़िगर किया गया है?

— डीन

11

$ chmod 700 ~

$ chmod 700 ~ / .sh

$ chmod 600 ~ / .sh / अधिकृत_की

/ Etc / ssh / sshd_config में इन विशेषताओं की जाँच करें

$ सूदो ग्रीप पब्कुअथेंटिकेशन / आदि / एसएचएस / sshd_config

$ sudo grep प्रोटोकॉल / etc / ssh / sshd_config

— setatakahashi
स्रोत

2

~ के बारे में उत्कृष्ट बिंदु, आपको यह सुनिश्चित करना चाहिए कि आपके अलावा कोई भी आपके घर निर्देशिका में नहीं लिख सकता है, अन्यथा वे आपकी ~ / .shsh निर्देशिका का नाम बदल सकते हैं

— डेव चेनी

वह अंतिम $ chmod 600 ~/.ssh/authorized_keys$ chmod 600 ~/.sHh/authorized_keys

— चामोद

3

विशेषता मान क्या चाहिए हो ?

— माइकल

0

एक और महत्वपूर्ण नुकसान ..

यदि आपकी होम डायरेक्टरी एन्क्रिप्टेड है sshd की पहुंच ~ / .ssh / अधिकृत_की तक नहीं होगी।

इस जवाब को देखें

— संभवतः
स्रोत