SSH DSA कुंजियाँ अब पासवर्ड-कम प्रमाणीकरण के लिए काम नहीं करती हैं

Question

Fedora 23 में अपग्रेड करने के बाद, पासवर्ड रहित (सार्वजनिक-कुंजी-आधारित) प्रमाणीकरण अब SSH में काम नहीं करता है: जब SSH कुछ होस्ट की कोशिश करता है, तो यह दूरस्थ होस्ट पर मेरे पासवर्ड के लिए संकेत देता है। मैं अपनी SSH निजी कुंजी का उपयोग करने के लिए इसे प्राप्त नहीं कर सकता। फेडोरा 22 के साथ सब कुछ ठीक रहा।

मेरी सार्वजनिक कुंजी एक DSA कुंजी ( ~/.ssh/id_dsa.pub) है। मैं ओपनएसएसएच 7.1 ( openssh-7.1p1-5.fc23.x86_64) का उपयोग कर रहा हूं ।

मुझे फिर से सही तरीके से काम करने के लिए पासवर्ड-कम प्रमाणीकरण कैसे मिलेगा?

Comments

का शिकार superuser.com/questions/962918/... और (क्रॉस) unix.stackexchange.com/questions/247612/...

— dave_thompson_085

धन्यवाद, @ dave_thompson_085 यह सुपरसर्वर . com/q/962918/ 93541 का धोखा नहीं है । यह प्रश्न पूछ रहा है कि कैसे उपयोग किया जाए ssh -Q। यह पूछ रहा है कि SSH की विफलता को कैसे शूट करें। मुझे इस समाधान को पहचानने में सुपरयूज़र . com / q / 962918 / 93541 और अन्य जगहों पर कुछ सामग्री मिली , लेकिन वहाँ का उत्तर बताता है कि कैसे उपयोग करें ssh -Qऔर इस प्रश्न का उत्तर न दें (उदाहरण के लिए, यह यह नहीं समझाता है कि कैसे ठीक करें यह समस्या), इसलिए मेरे विचार में यह कोई गलत काम नहीं है। यूनिक्स और लिनक्स पर एक बहुत समान है; काश मैं उस एक को पहले देखा होता। फिर से लिंक के लिए धन्यवाद!

— डीडब्लू

ठीक है, तुम सही हो। मैंने उन दोनों को "ओपनएसएसएच 7.0 नो डीएसए" के रूप में बुकमार्क किया था, जो कि पूर्व के मामले में काफी करीब नहीं है। माफ़ कीजिये।

— dave_thompson_085 1

Answer 1

यह OpenSSH 7.0 में अपग्रेड करने का परिणाम है। के रूप में ओपनएसएसएच 7.0 के लिए जारी किए गए नोट्स कहते हैं , "ssh-dss होस्ट और उपयोगकर्ता कुंजियों के लिए समर्थन डिफ़ॉल्ट रूप से रन-टाइम पर अक्षम होता है"।

समाधान ~/.ssh/configप्रत्येक ग्राहक मशीन पर प्रत्येक पंक्ति (जहां आप SSH क्लाइंट चलाते हैं) पर निम्नलिखित पंक्ति को जोड़ना है:)

PubkeyAcceptedKeyTypes=+ssh-dss

यदि सर्वर OpenSSH 7.0 या नए का उपयोग कर रहा है, तो आप भी करेंगे करने के लिए इस लाइन जोड़ने की जरूरत है /etc/ssh/sshd_configप्रत्येक सर्वर मशीन पर।

वैकल्पिक रूप से, आप एक पूरी तरह से नई SSH कुंजी उत्पन्न कर सकते हैं और इसे अपने अधिकृत_की फ़ाइल में जोड़ सकते हैं जो कभी भी आप लॉग इन करना चाहते हैं। मैं आपको सलाह देता हूं कि आप अनुकूलता से बचने के लिए RSA का उपयोग करें । मैं ईसीडीएसए की सिफारिश नहीं करता हूं, जैसा कि स्पष्ट रूप से सूक्ति-कीरिंग-डेमन स्वचालित रूप से ईसीडीएसए की एसएसएच कुंजी नहीं उठाता है।

---

संपादकीय टिप्पणी: ओपनएसएसएच लोगों ने डीएसए कुंजियों को अक्षम क्यों किया? मुझे नहीं पता। जहाँ तक मैं पता लगाने में सक्षम हूँ, वहाँ डीएसए कुंजी (ssh-dss) की सुरक्षा के साथ कुछ भी गलत नहीं है। OpenSSH वेब पेज दावा है कि ssh-dss कमजोर है, लेकिन जहां तक मुझे पता है हूँ, 1024-बिट ssh-dss नहीं की तुलना में 1024-बिट RSA कमजोर है, और 1024-बिट RSA कुंजी विकलांग नहीं हैं।

Comments

कुछ समय के लिए सुरक्षा पर मुख्य प्रकार के चयन पर चर्चा की जाती है । DSA कुंजी की सुरक्षा शुरुआत से ही संदिग्ध है और यदि आपके पास अच्छा यादृच्छिक जनरेटर नहीं है (जो आप सुनिश्चित नहीं कर सकते हैं) तो कम सुरक्षित है। और चूंकि अब उपयोग करने के लिए अन्य संभावित प्रमुख प्रकार हैं, इसलिए संदिग्ध लोगों को बनाए रखने का कोई कारण नहीं है।

— जकूज़ी

@ जकुज, हां, कुंजी प्रकार के चयन की चर्चा यहां और यहां सूचना सुरक्षा पर की गई है । मैंने अपनी संपादकीय टिप्पणी लिखने से पहले वह सब पढ़ा, और मैं हैरान रह गया कि डीएसए की चाबियाँ अक्षम क्यों थीं: वे उसी लंबाई के आरएसए कीज़ से कमज़ोर नहीं हैं, जो अक्षम नहीं थे। उन थ्रेड्स में से कुछ भी नहीं है जो डीएसए को "संदिग्ध" बताता है, और जैसा कि थॉमस पोर्निन कहते हैं, "किसी भी अन्य पर एक प्रकार को पसंद करने के लिए कोई सुरक्षा-संबंधी कारण नहीं है, बड़ी पर्याप्त चाबियाँ मानते हुए"। (cont।)

— डीडब्ल्यू

अधिक विस्तृत चर्चा के लिए यहां देखें ।

— डीडब्ल्यू

Answer 2

मेरे दो सेंट

मुझे .ssh/configलगता है कि यह एक अच्छा विचार नहीं है, यह अनुमति देने के लिए संपादन फ़ाइल के रूप में

1. हाल के टूल का उपयोग करके, एक नई कुंजी बनाएं।

   फिर नई सार्वजनिक कुंजी कॉपी करें (क्लिपबोर्ड में)

2. पुरानी कुंजी का उपयोग करके पिछली बार लॉग इन करें :

   ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
   

   फिर उन्नयन @hostके authorized_keysअपने नए जोड़कर फ़ाइल, pubkey और लॉगआउट

   cat >>.ssh/authorized_keys
   

   paste, फिर Ctrl+D

3. डिफ़ॉल्ट सिंटैक्स का उपयोग करके नई कुंजी के साथ लॉग इन करें:

   ssh user@host
   

   1. फिर उन्नयन @hostके authorized_keys, फ़ाइल से हटाने के आप पुराने pubkey (मैं का उपयोग करें sed -e 1d -i .ssh/authorized_keysजब मेरे पुराने pubkey लाइन पर है 1इस फ़ाइल का)।

   2. यदि आप कर सकते हैं तो मैं आपको ssh सर्वर को अपग्रेड करने का सुझाव देता हूं।

   3. लोग आउट

4. टेस्ट करें यदि पुरानी कुंजी अब काम नहीं करती है।

   ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
   ...
   Permission denied...
   

   यह काम नहीं करना है ;-)

5. सब कुछ ठीक होने पर आप फिर से जांच कर सकते हैं:

   ssh user@host uptime
   

Comments

मेरे लिए यह स्पष्ट नहीं है कि आपको क्यों लगता है कि संपादन ~/.ssh/configइतना अच्छा विचार नहीं है।

— DW

क्योंकि यह पदावनत है और ssh लेखक उपयोग न करने की सिफारिश करता है। देखें openssh.com/legacy.html

— एफ HAURI

ओह मैं समझता हूँ। ऐसा लगता है कि आपकी चिंता ~/.ssh/configप्रति संपादन के विचार से नहीं है, बल्कि डीएसए को अनुमति देने के विचार से है। समझाने के लिए धन्यवाद। यह समझ आता है। (मुझे लगता है कि मैंने पहले ही अपने उत्तर और अपनी टिप्पणियों में संबोधित कर लिया है कि मुझे ऐसा क्यों लगता है कि मुझे हैरान करने की सिफारिश की गई है, लेकिन मैं यहां बहस करने की कोशिश नहीं करूंगा।)

— DW

संपादन .configआपको sshलंबे समय तक निष्पादित करने में सक्षम बनाता है और यहां तक ​​कि धूमिल भी है कि आप कमजोर एल्गोरिथ्म का उपयोग करते हैं । -o Pubkey...कमांड लाइन पर उपयोग करने से, आप यह क्षमा नहीं करेंगे कि अपग्रेड करने के लिए कुछ है ।

— एफ। हौरी