SSH होस्ट सत्यापन त्रुटियों को संभालने के लिए सबसे आसान वर्कफ़्लो?

Question

यह एक साधारण मुद्दा है जिसका हम सभी सामना करते हैं और शायद ज्यादा सोचे-समझे बिना खुद ही हल कर लेते हैं।

जैसे-जैसे सर्वर बदलते हैं, फिर से प्रावधान किए जाते हैं, या आईपी पते पुनः प्राप्त किए जाते हैं, हम नीचे SSH होस्ट सत्यापन संदेश प्राप्त करते हैं। मैं इन ssh पहचान त्रुटियों को हल करने के लिए वर्कफ़्लो को व्यवस्थित करने में दिलचस्पी रखता हूँ।

निम्नलिखित संदेश को देखते हुए, मैं आम तौर पर vi /root/.ssh/known_hosts +434और ddऑफ लाइन को हटा देता हूं ।

मैंने अन्य संगठनों में डेवलपर्स / उपयोगकर्ताओं को इस संदेश को देखने में हताशा से अपनी पूरी known_hosts फ़ाइल को हटाने के लिए देखा है । जब तक मैं उस तक नहीं जाता, मुझे पता है कि इसे संभालने का एक और सुंदर तरीका है।

युक्तियाँ?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

Comments

हमें भी वही तकलीफ़ है। मुझे नासा के मेष ti.arc.nasa.gov/opensource/projects/mesh के साथ अनुभव नहीं है, लेकिन यह समीक्षा करने के लिए मेरी प्रौद्योगिकियों की सूची में है।

— एंड्रयू गिलमार्टिन

किसी सर्वर को पुनः इंस्टॉल / पुनः लोड करते समय पुरानी कुंजी को कॉपी क्यों नहीं किया जाता है?

— रैंडम 832

@ Random832 यह उस स्थिति में नहीं होता है जब आपके पास बहुत सारे सर्वर होते हैं ... या यदि आपके पास एक लैब / परीक्षण वातावरण है जहां आप अक्सर आईपी पते को रीसाइक्लिंग कर रहे हैं। या एक और मामला; एक अनियोजित सर्वर प्रतिस्थापन जहां मूल सर्वर अनुपलब्ध है ...

— 13:13

मेरे पास बड़ा सवाल यह है: आप इस स्थिति में कैसे आएंगे? यदि आप होस्टनाम का पुनः उपयोग कर रहे हैं, तो आप अपने होस्ट नामकरण मानक ( tools.ietf.org/html/rfc1178 ) पर पुनर्विचार करना चाह सकते हैं । यदि आप IP पतों का फिर से उपयोग कर रहे हैं, तो आपके पास उस आईपी पते पर पिछले सर्वर को डिमोशन करने के समान प्रक्रिया के भाग के रूप में ssh कुंजियों का डिकमिशनिंग होना चाहिए। आप एक "webscale" वातावरण जहां आईपी पुन: उपयोग के लिए एक स्वचालित आधार और अर्द्ध व्यर्थ होस्ट नामों पर होता है में काम कर रहे हैं कर रहे हैं अनिवार्य है, तो आप एक अच्छी तरह से स्वचालित पर्याप्त सर्वर जीवन चक्र प्रक्रिया है कि SSH कुंजियों फिक्सिंग procee होगा होना चाहिए

— पॉल गियर

Answer 1

आप ssh-keygenहोस्ट द्वारा विशिष्ट प्रविष्टियों को हटाने के लिए कमांड का उपयोग कर सकते हैं :

ssh-keygen -R las-db1

यदि आपके पास वह कमांड नहीं है, तो आप हमेशा sed का उपयोग कर सकते हैं:

sed -i '/las-db1/d' /root/.ssh/known_hosts

Comments

विवादित कुंजियों के साथ समस्या को हल करने के लिए ssh-keygen -R का उपयोग करना भी उबंटू में ssh क्लाइंट को यह समस्या आने पर त्रुटि संदेश में सुझाता है।

— केनी रैस्चर्ट

मुझे ssh-keygenकमांड के उस स्विच के बारे में पता नहीं था । अच्छा!

— ewwhite

याद रखें कि जाँच करें और सुनिश्चित करें कि कोई व्यक्ति वास्तव में "डूइंग सोमिंग नाइटी" नहीं है!

— माइकल हैम्पटन

सुनिश्चित करें कि आप एक सम्मेलन में ऐसा नहीं करते हैं!

— पॉल गियर

@ जब आप /etc/ssh/known_hostsउपयुक्त होस्ट कुंजियों (प्रबंधित w / कठपुतली, आदि) के साथ अपने नेटवर्क पर फ़ाइल को पॉप्युलेट करते हैं, या आप अपनी व्यक्तिगत ~ / .sh / ज्ञात_होस्ट फ़ाइल को पॉप्युलेट करते हैं (इन दोनों में से कोई भी करने के लिए आप ssh-keyscanकिसी ज्ञात अच्छे या सुरक्षित पर चला सकते हैं) कनेक्शन)। बैरिंग (और यह मानते हुए कि आप सुरक्षा के बारे में बिल्कुल भी ध्यान नहीं देते हैं) सेट UserKnownHostsFile=/dev/nullऔर StrictHostKeyChecking=noआपके ~/.ssh/config file(या ssh के विकल्पों को पास करें -o)

— voretaq7

Answer 2

एक कठपुतली उपयोगकर्ता के रूप में, इसे हल करने के लिए मेरी विधि वास्तव में मेरे कठपुतली सर्वर ने मेरी SSH होस्ट कुंजियाँ एकत्र की हैं और उन्हें SSH कनेक्शन बनाने वाली मेरी सभी प्रणालियों में प्रकाशित किया है।

इस तरह मुझे उन्हें हटाने के बारे में चिंता करने की ज़रूरत नहीं है। पैंतीस प्रतिशत समय कठपुतली ने चलाया और मेरे लिए चाबियां अपडेट कीं क्योंकि मेरे पास हर तीस मिनट में मेरे एजेंट हैं। मेरे लिए अपवाद बहुत दुर्लभ हैं, और अगर मुझे प्रतीक्षा करने के लिए तैयार नहीं है, तो मुझे सिस्टम के बारे में पता नहीं है।

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

Comments

+1 कॉन्फ़िगरेशन प्रबंधन टूल को शामिल करने के लिए अच्छा कदम।

— evhite

Answer 3

मैं एक सुझाव जोड़ना चाहूंगा जो बहुत विशिष्ट मामलों में आपकी मदद कर सकता है जहां सुरक्षा कम चिंता का विषय है।

मेरे पास मशीनों के साथ एक प्रयोगशाला वातावरण है जो अक्सर पुनर्स्थापित हो जाते हैं। हर बार ऐसा होता है, नई होस्ट कुंजी उत्पन्न होती हैं (मैं शायद होस्ट कुंजी को कहीं सहेज सकता हूं और इसे पोस्ट-इंस्टॉल स्क्रिप्ट में सेट कर सकता हूं)।

चूँकि इस प्रयोगशाला के वातावरण में सुरक्षा मेरे लिए कोई समस्या नहीं है, और चाबियाँ इतनी बार बदलती हैं, मेरे पास मेरे .sh / config फाइल में निम्नलिखित हैं।

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

यह सुनिश्चित करता है कि मेरी लैब मशीनों से जुड़ने से वह त्रुटि फिर कभी नहीं होगी और मेरा ssh क्लाइंट केवल होस्ट की जाँच किए बिना कनेक्ट होगा।

यह कुछ ऐसा है जो आपको केवल तभी करना चाहिए जब सुरक्षा का आपके लिए कोई चिंता का विषय न हो, क्योंकि यह आपको एक मानव-मध्य हमले के लिए कमजोर स्थिति में डालता है।

Comments

जोखिम भरा लगता है। मैं मेजबान सत्यापन को रखना चाहता हूं क्योंकि इनमें से कुछ सार्वजनिक-सामना करने वाले सिस्टम हैं।

— ewwhite

यही कारण है कि उन्होंने उल्लेख किया कि यह विधि केवल "जहां सुरक्षा कम / कोई चिंता नहीं है" के लिए है। निजी नेटवर्क / लैब वातावरण इस विन्यास के लिए एकदम सही हैं। मल्टी-मशीन ऑटो-स्केलिंग उत्पादन / सार्वजनिक सामना प्रणाली, इतना नहीं।

— डैनोसॉरस

Answer 4

खुलने के समय 5.6 जारी नोट के अनुसार , आपको मेजबानों की कुंजियों का उपयोग करने की आवश्यकता नहीं है:

होस्ट किए गए प्रमाणीकरण अब प्रमाणपत्र होस्ट कुंजी का उपयोग कर सकते हैं। CA कुंजी को sshd (8) में वर्णित @ सर्टिफिकेट-अथॉरिटी मार्कर का उपयोग करके एक ज्ञात_होस्ट फ़ाइल में निर्दिष्ट किया जाना चाहिए।

चेतावनी : मैंने अब तक उत्पादन में इस सुविधा का उपयोग करते हुए किसी के बारे में नहीं सुना है। अपने स्वयं के जोखिम पर उपयोग करें (लेकिन मेरा मानना ​​है कि ओपनशेड डेवलपर्स बहुत अधिक परीक्षण और कोड ऑडिटिंग के बिना इस तरह के हत्यारे की सुविधा को जारी नहीं करने के लिए पागल हैं)।

Answer 5

SSHFP DNS रिसोर्सकार्ड आपके ssh क्लाइंट का कितना फायदा उठाता है, इस पर निर्भर करता है। होस्ट नाम के साथ अपने सभी ssh सार्वजनिक कुंजी फ़िंगरप्रिंट को वहां संग्रहीत करें।

SSL पर पहले से DNSSEC या DNS लागू करें।
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org होस्ट और उपयोगकर्ता कुंजी प्रबंधन के साथ-साथ PKI प्रमाणपत्र भी संभालता है। यह SSHFP DNS रिकॉर्ड को स्वचालित रूप से अपलोड करता है जब नई कुंजी बनाई जाती है।

सिस्टम सिक्योरिटी सर्विसेज डेमन (SSSD) को कैश में होस्ट किया जा सकता है और होस्ट SSH कुंजियों को पुनः प्राप्त किया जा सकता है ताकि एप्लिकेशन और सेवाओं को केवल होस्ट कीज़ के लिए एक स्थान पर देखना पड़े। क्योंकि SSSD FreeIPA का उपयोग अपने एक पहचान सूचना प्रदाता के रूप में कर सकता है, FreeIPA चाबियों का एक सार्वभौमिक और केंद्रीकृत भंडार प्रदान करता है। व्यवस्थापकों को होस्ट SSH कुंजी को वितरित करने, अद्यतन करने या सत्यापित करने के बारे में चिंता करने की आवश्यकता नहीं है।

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html