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


यह एक साधारण मुद्दा है कि हम सभी को बहुत अधिक विचार किए बिना मैन्युअल रूप से सामना करना पड़ता है और संभवतः हल करता है।

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

निम्नलिखित संदेश को देखते हुए, मैं आम तौर पर 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.

39
2017-08-12 20:54


मूल


हमें भी वही तकलीफ़ है। मुझे नासा के मेष के साथ अनुभव नहीं है ti.arc.nasa.gov/opensource/projects/mesh लेकिन यह समीक्षा करने के लिए प्रौद्योगिकियों की मेरी सूची पर है। - Andrew Gilmartin
किसी सर्वर को पुनर्स्थापित / पुन: स्थापित करते समय पुरानी कुंजी की प्रतिलिपि क्यों न करें? - Random832
@ Random832 यह ऐसी स्थिति में स्केल नहीं करता है जहां आपके पास बहुत से सर्वर हैं ... या यदि आपके पास एक प्रयोगशाला / परीक्षण वातावरण है जहां आप अक्सर आईपी पते रीसाइक्लिंग कर रहे हैं। या एक और मामला; एक अनियोजित सर्वर प्रतिस्थापन जहां मूल सर्वर अनुपलब्ध है ... - ewwhite
मेरे पास बड़ा सवाल यह है कि आप इस स्थिति में कैसे पहुंचते हैं? यदि आप होस्टनाम का पुनः उपयोग कर रहे हैं, तो हो सकता है कि आप अपने होस्ट नामकरण मानक पर पुनर्विचार करना चाहें (tools.ietf.org/html/rfc1178)। यदि आप आईपी पते का पुनः उपयोग कर रहे हैं, तो आपको उसी प्रक्रिया के हिस्से के रूप में एसएसएच कुंजी का डिमोकिशन करना चाहिए क्योंकि पिछले आईपी पते पर पिछले सर्वर को डिमोकिशन करना था। यदि आप "वेबस्केल" वातावरण में काम कर रहे हैं जहां आईपी पुन: उपयोग स्वचालित आधार पर होता है और अर्ध-अर्थहीन होस्टनाम अनिवार्य हैं, तो आपके पास एक अच्छी तरह से स्वचालित पर्याप्त सर्वर लाइफसाइक्ल प्रक्रिया होनी चाहिए जो एसएसएच कुंजी को ठीक करेगी - Paul Gear


जवाब:


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

ssh-keygen -R las-db1

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

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

46
2017-08-12 20:57



विवाद कुंजी के साथ समस्या को हल करने के लिए ssh-keygen -R का उपयोग करना यह समस्या तब होती है जब उबंटू में एसएसएच क्लाइंट त्रुटि संदेश में सुझाव देता है। - Kenny Rasschaert
मुझे उस स्विच के बारे में पता नहीं था ssh-keygen आदेश। अच्छा! - ewwhite
जांचना याद रखें और सुनिश्चित करें कि कोई वास्तव में "कुछ नस्टी कर रहा है!" - Michael Hampton♦
सुनिश्चित करें कि आप इसे एक सम्मेलन में नहीं करते हैं! - Paul Gear
@ewwhite आप populate /etc/ssh/known_hosts उचित होस्ट कुंजियों (प्रबंधित डब्ल्यू / कठपुतली, इत्यादि) के साथ अपने नेटवर्क पर फ़ाइल करें, या आप अपनी व्यक्तिगत ~ / .ssh / known_hosts फ़ाइल को पॉप्युलेट करते हैं (इनमें से कोई भी ऐसा करने के लिए आप चला सकते हैं ssh-keyscan एक ज्ञात अच्छे / सुरक्षित कनेक्शन पर)। इसे छोड़कर (और यह मानते हुए कि आप सुरक्षा के बारे में बिल्कुल परवाह नहीं करते हैं) सेट करें UserKnownHostsFile=/dev/null तथा StrictHostKeyChecking=no आपके में ~/.ssh/config file (या एसएसएच के साथ विकल्पों को पास करें -o) - voretaq7


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

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

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,
  }

}

25
2017-08-12 21:02



+1 विन्यास प्रबंधन उपकरण को शामिल करने के लिए अच्छा कदम। - ewwhite


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

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

चूंकि सुरक्षा इस प्रयोगशाला के माहौल में मेरे लिए कोई मुद्दा नहीं है, और चाबियाँ अक्सर बदलती हैं, मेरे पास मेरी .ssh / config फ़ाइल में निम्न है:

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

यह सुनिश्चित करता है कि मेरी प्रयोगशाला मशीनों से कनेक्ट होने से कभी भी उस त्रुटि का कारण नहीं होगा और मेरा एसएसएच क्लाइंट मेजबान कुंजी की जांच किए बिना कनेक्ट होगा।

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


4
2017-08-12 21:09



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


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

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

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


4
2017-08-22 12:31





एसएसएचएफपी DNS संसाधन रिकॉर्डर इस बात पर निर्भर करता है कि आपका एसएसएच क्लाइंट इसका कितना लाभ उठाता है। मेजबान नाम के साथ अपने सभी एसएसएच सार्वजनिक कुंजी फिंगरप्रिंट स्टोर करें।

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

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

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

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


2
2017-08-12 21:38