जब कई होस्ट एक ही आईपी और डीएनएस नाम साझा करते हैं, तो ज्ञात_होस्ट को कैसे संपादित करें?

Question

मैं नियमित रूप से एक कंप्यूटर में ssh करता हूं जो कि एक डुअल-बूट OS X / Linux कंप्यूटर है। दो OS उदाहरण एक ही होस्ट कुंजी साझा नहीं करते हैं, इसलिए उन्हें दो होस्ट एक ही IP और DNS साझा करते हुए देखा जा सकता है। मान लें कि आईपी है 192.168.0.9, और नाम हैं hostnameऔरhostname.domainname

जहां तक ​​मुझे समझ में आया, दोनों होस्ट से जुड़ने में सक्षम होने का उपाय उन दोनों को ~/.ssh/know_hostsफाइल में जोड़ना है । हालांकि, यह तुलना में आसान किया है, क्योंकि फ़ाइल मिश्रित होता है, और मेजबान प्रति शायद कई प्रविष्टियां हैं कहा जाता है ( 192.168.0.9, hostname, hostname.domainname)। परिणामस्वरूप, मेरे पास निम्नलिखित चेतावनी है

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

क्या known_hostsफ़ाइल को संपादित करने का एक आसान तरीका है , जबकि हैश रखते हुए। उदाहरण के लिए, मैं किसी दिए गए होस्टनाम के अनुरूप लाइनें कैसे पा सकता हूं? मैं कुछ ज्ञात मेजबानों के लिए हैश कैसे उत्पन्न कर सकता हूं?

आदर्श समाधान मुझे ssh के साथ इस कंप्यूटर से मूल रूप से कनेक्ट करने की अनुमति देगा, भले ही मैं इसे कॉल करूं 192.168.0.9, hostnameया hostname.domainnameन ही अगर यह लिनक्स लिनक्स या इसके ओएसएक्स होस्टके का उपयोग करता है। हालांकि, मैं अभी भी एक चेतावनी प्राप्त करना चाहता हूं कि क्या कोई वास्तविक मानव-मध्य हमला है, अर्थात यदि इन दोनों की तुलना में एक और कुंजी का उपयोग किया जाता है।

Comments

ऐसा क्या है जो आप करना चाहते हैं? इसे किस लिए संपादित करें?

— रयूक

@Rukuk: इसे संपादित करने में सक्षम होने के लिए OSX और linux होस्ट कुंजी दोनों को IP पते, hostname और hostname.domainname के रूप में मान्य करें।

— फ्रैडरिक ग्रॉंस 14

@Rukuk: मैं वें सवाल संपादित किया है। क्या यह अब अधिक स्पष्ट है?

— Frédéric Grosshans

क्या आप दोनों प्रतिष्ठानों को एक ही कुंजी बनाने पर विचार कर रहे हैं?

— ज़ोराडैच

ऐसे कुछ मामले हैं जब कई संस्थाओं तक पहुंचने के लिए एक आईपी पते का उपयोग करना उचित है (प्रत्येक व्यक्तिगत एसएसएच होस्ट कुंजी के साथ) और फिर भी सख्त नियंत्रण बनाए रखें कि केवल उन होस्ट कुंजी एसएसएच क्लाइंट द्वारा देखे गए हैं। उदाहरण के लिए, कुछ उच्च उपलब्धता सेटअप जहां इकाइयों का एक क्लस्टर एक साझा आईपी पते का उपयोग करके एक्सेस किया जाता है, लेकिन जहां (किसी कारण से) ग्राहकों द्वारा देखी जाने वाली SSH होस्ट कुंजी को बदलता है, जिसके आधार पर यह है कि वर्तमान में सक्रिय है। एक और मामला तब है जब कई SSH होस्ट एक नैटेड फ़ायरवॉल के पीछे हैं और बाहर से एक्सेस किए जाते हैं, वे सभी एक ही IP वाले लगते हैं।

— इलविलाजा

Answer 1

यहां सबसे सीधा समाधान लिनक्स और ओएस एक्स के लिए समान होस्ट कुंजी का उपयोग करना है। अर्थात, /etc/ssh/ssh_host_*_key*फ़ाइलों का एक सेट चुनें और उन्हें दूसरे ओएस पर कॉपी करें। फिर एक ही होस्ट कुंजी को SSH क्लाइंट के सामने प्रस्तुत किया जाएगा, भले ही आपके द्वारा बूट किए गए OS की परवाह किए बिना, और SSH क्लाइंट कोई भी समझदार नहीं होगा।

Comments

मैं एक क्लाइंट संस्करण पसंद करूंगा, लेकिन अगर मुझे एक नहीं मिलता है तो मैं यह कोशिश करूंगा। वैसे, फाइलों का ओएसएक्स (गैर-मानक) स्थानीयकरण है /private/etc/ssh_host*, नहीं /etc/ssh/ssh_host*।

— फ्रेडेरिक ग्रॉंस

एक मशीन से दूसरी मशीन (दो लिनक्स मशीन) पर फाइल कॉपी करना मेरे लिए कारगर नहीं रहा। हालाँकि फ़ाइल सामग्री समान थीश ऐसा नहीं था इसलिए मुझे अभी भी समस्या हो रही थी (शायद संशोधन का समय?)। नीचे दिए गए समाधान बहुत बेहतर है।

— Stav

sshdस्टार्टअप पर एक बार होस्ट कीज़ लोड करता है, इसलिए आपको सबसे अधिक पुनरारंभ करने की आवश्यकता है sshd। मैं उसे उत्तर में जोड़ दूंगा। अन्य समाधान बेहतर होने के कारण, यह आपकी स्थिति पर निर्भर करता है। मैं यह तर्क दूंगा कि इस पद्धति का प्रमुख नियम यह है कि इसके लिए केवल एक बार सेटअप की आवश्यकता होती है और कई SSH ग्राहक परीक्षाओं के साथ काम करने की अधिक संभावना होती है।

— 19

उत्सुकता से, ऐसा लगता है कि मेरा अपेक्षाकृत हाल का ओपनएसएसएच 7.4p1 sshdप्रत्येक नए कनेक्शन पर होस्ट कुंजी लोड करता है। शायद यह इस तरह से एक लंबा समय रहा है और मुझे लगता है कि मेजबान कुंजी को अन्य sshdकॉन्फ़िगरेशन की तरह माना जाता था । तो वैसे भी, यह आपका मुद्दा हो भी सकता है और नहीं भी।

— jjlin

एक ही VRRP पते को साझा करने वाले क्लस्टर में दो होस्ट के लिए ऐसा करना बुरा होगा? असफल होने पर, प्रतिक्रिया देने वाला मेजबान अलग होगा। मैं चेतावनी नहीं देना चाहूंगा।

— कॉलिन टी हार्ट

Answer 2

जैसा कि @Izzy ने उपरोक्त टिप्पणी में सुझाव दिया था, ssh आपको आपत्तिजनक लाइन बताता है, और उस लाइन को हटाकर, (इसे कहीं और सहेज कर), नई कुंजी को स्वीकार करता है, और फिर हटाए गए लाइन को कॉपी करते हुए, आप उसी के लिए दो कुंजियों को हवा देते हैं। मेजबान, और ssh या तो स्वीकार करेंगे।

(आप ssh-keygen -H -F <hostname>अपनी ज्ञात_होस्ट फ़ाइल में उन पंक्तियों को खोजने के लिए भी उपयोग कर सकते हैं जो होस्टनाम से मेल खाती हैं। हटाए गए लाइन को कॉपी करने के बाद इसे चलाना दो प्रविष्टियों को सूचीबद्ध करना चाहिए।)

अगर किसी को पता है कि उसी काम को करने के लिए PuTTY कैसे प्राप्त किया जाए, तो मुझे इसके बारे में सुनने में बहुत दिलचस्पी होगी।

Comments

असल में, यदि आपके पास एक linux क्लाइंट है, तो आपको भी अपमानजनक लाइन को हटाने की आवश्यकता नहीं है, आपको केवल इसे हैश ('#') के साथ सामने रखना होगा। फिर, एक बार जब आप नई कुंजी स्वीकार कर लेते हैं, तो आप केवल ज्ञात_होस्ट फ़ाइल को संपादित कर सकते हैं और पुरानी कुंजी के साथ लाइन को अनइंस्टॉल कर सकते हैं। लेकिन हां, यह पुट्टी में भी उपयोगी होगा।

— इलविलेज जेए

यदि एक ही नाम वाले दो होस्ट हैं, लेकिन अलग-अलग आईपी एड्रेस और अलग-अलग होस्ट की, यह वर्कअराउंड भी काम करता है: टिप्पणी करें (या अस्थायी रूप से हटाएं) फिर उस होस्ट के लिए दोनों पंक्तियां (आईपी पते पर आधारित और होस्ट पर आधारित एक) नाम), अभी तक ज्ञात होस्ट से कनेक्ट नहीं है, और फिर लाइनों को फिर से जोड़ें, जिन्हें टिप्पणी या हटा दिया गया था।

— काई पेट्ज़के

Answer 3

मैंने पाया कि आप जो हासिल करना चाहते हैं, उससे आपको मदद मिल सकती है।

स्रोत: /programming/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

अपनी .ssh निर्देशिका में एक विन्यास फाइल इस प्रकार बनाएँ:

Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl

नीचे स्पष्टीकरण (आदमी ssh_config से)

CheckHostIP

यदि यह ध्वज "हां" पर सेट है, ssh (1) इसके अलावा ज्ञात_होस्ट्स फ़ाइल में होस्ट आईपी पते की जांच करेगा। यह पता लगाने के लिए ssh की अनुमति देता है कि क्या DNS स्पूफिंग के कारण होस्ट कुंजी बदल गई है। यदि विकल्प "नहीं" पर सेट है, तो चेक निष्पादित नहीं किया जाएगा। डिफ़ॉल्ट "हाँ" है।

HostKeyAlias

होस्ट कुंजी डेटाबेस फ़ाइलों में होस्ट कुंजी को देखने या सहेजते समय वास्तविक होस्ट नाम के बजाय किसी अन्य नाम का उपयोग किया जाना चाहिए। यह विकल्प SSH कनेक्शन को टनल करने या एक ही होस्ट पर चलने वाले कई सर्वरों के लिए उपयोगी है।

उपयोगकर्ता नाम और पोर्ट लाइन आपको कमांड लाइन पर उन विकल्पों को देने से बचाती है, इसलिए, आप बस इसका उपयोग कर सकते हैं:

% ssh server1
% ssh server2

Comments

मैंने इस लेख को देखा, लेकिन यह मेरे मामले से मेल नहीं खाता: दो सर्वर लेख में पोर्ट नंबर द्वारा प्रतिष्ठित हैं, मेरे मामले में नहीं। इसके अलावा, मैं सुरक्षा में नमकीन हैश द्वारा लाया की अतिरिक्त परतें रखना चाहते हैं known_hostsऔर CheckHostIP।

— फ्रेडेरिक ग्रॉंस

@ FrédéricGrosshans, मैंने चेक किया। आपको बंदरगाहों को अलग करने की आवश्यकता नहीं है, और HostKeyAlias ​​के साथ HashKnownHosts विकल्प ठीक काम करता है।

— ज़ॉडेचे जूल 5'12

इसके लिए नीचे की ओर, जब तक कि मैं गलत नहीं हूं, यह प्रति ग्राहक आधार पर कॉन्फ़िगर किया गया है। स्वीकृत उत्तर के अनुसार केवल स्वीकृत सर्वर पर ही कॉन्फ़िगर किया गया है।

— FreeSoftwareServers

Answer 4

अपनी समस्या को हल करने का सबसे आसान तरीका प्रत्येक मेजबान को अपना / अलग आईपी पता देना है। आपके (निजी) नेट और आईपीवी 4 में उपलब्ध 253 पतों के साथ, यह कोई बड़ी बात नहीं होनी चाहिए। उन्हें निर्धारित आईपी (एक डीएचसीपी सर्वर नेटवर्क कार्ड मैक पते के आधार पर मशीन की पहचान करेगा, और दोनों को एक ही पता मिलेगा) दें। यदि आप सुरक्षा उपाय (जो मैं उस छोटे "आराम", या तो के लिए नहीं छोड़ता) को रखना चाहते हैं, तो मुझे कोई अन्य समाधान नहीं दिखता है।

Comments

दरअसल, आईपी एड्रेस 192.168.0.xxनिजी नहीं है। यह एक 'वास्तविक' IPv4 पता है, जो मेरे विश्वविद्यालय द्वारा दिया गया है जिसे मैं बदलने के लिए स्वतंत्र नहीं हूँ।

— Frédéric Grosshans

यदि आप विकिपीडिया से जाँच करते हैं , तो आपको 192.168.0.0 - 192.168.255.255 (आपका प्रश्न 192.168.0.9, जो इस सीमा में आता है) निर्दिष्ट करता है, जो "प्राइवेट IPv4 एड्रेस स्पेस" से संबंधित है। तो "निजी" द्वारा मैंने आपको इसका "उल्लेख" नहीं किया, लेकिन IETF के चश्मे से । आपके प्रश्न में आपने संकेत नहीं दिया कि आप IP को नहीं बदल सकते, क्षमा करें - लेकिन दिए गए इनपुट के साथ, मेरा उत्तर उपयुक्त था।

— इज़्ज़ी

बुरी तरह से फंसे सवाल के लिए क्षमा करें। मैं नीचे नहीं हुआ।

— Frédéric Grosshans

कोई संभावना नहीं है, और मुझे पता करने के लिए tnx - डाउनवोट को कम हतोत्साहित करता है। लेकिन एक और विचार: मुझे यकीन नहीं है कि ज्ञात_होस्ट फ़ाइल कहाँ से होस्टनाम लेती है, डीएनएस को उलट देती है या क्लाइंट द्वारा पेश की जाती है। आप अपने "होस्ट" में से एक का नाम बदलने की कोशिश कर सकते हैं, इसलिए यह एक अलग होस्टनाम प्रस्तुत करता है। या दोनों होस्ट कीज़ को जोड़ने के लिए: ssh आपको आपकी ज्ञात_होस्ट्स फ़ाइल में "ऑफ़ेंडिंग लाइन" बताता है (जब # 1 निहित है और आप # 2 से कनेक्ट करते हैं)। तो आप फिर उस लाइन को किसी अन्य फ़ाइल में कॉपी कर सकते हैं, इसे ज्ञात_होस्ट्स से हटा सकते हैं, # 2 को कनेक्ट कर सकते हैं और इसकी लाइन जोड़ सकते हैं, और हटाए गए लाइन को वापस जोड़ सकते हैं। यकीन नहीं है कि यह काम करता है, लेकिन आप कोशिश कर सकते हैं।

— इज़्ज़ी

Answer 5

मैं एक ही आईपी को साझा करने वाले विभिन्न वीपीएस बॉक्स से कनेक्ट करते समय उस समस्या में नहीं आता हूं क्योंकि प्रत्येक में एक अलग एसएसएच पोर्ट (20022,30022, आदि) है, इसलिए वे विभिन्न कुंजी के साथ ज्ञात होस्ट के रूप में पंजीकृत हैं।

क्या यह आपके लिए वर्कअराउंड हो सकता है?

Comments

हाय @ हाय, सुपर यूजर का स्वागत है! गौर करें कि यह सवाल लगभग 4 साल पुराना है। इसका उत्तर देने में कुछ भी गलत नहीं है, लेकिन ध्यान रखें कि यह संभव है कि आपको प्रतिक्रिया न मिले।

— ह्यूबोट

मेरे पास कोई भी OS X मशीन नहीं है, लेकिन आपका जवाब किसी और के लिए उपयोगी हो सकता है। यह स्टैक एक्सचेंज का संपूर्ण बिंदु है

— Frédéric Grosshans

@ हेवबॉट ... वास्तव में, मैं इसे अब देखता हूं। पता नहीं क्यों, यह हाल के सवालों की सूची में दिखाई दिया ...

— Pyheme

Answer 6

एक अन्य लेख , जो आपकी समस्या से निपटने के कई तरीकों का वर्णन करता है:

दूसरी विधि दो ओपनएसएसएच मापदंडों का उपयोग करती है: StrictHostKeyCheckinऔर UserKnownHostsFile। यह विधि SSH को खाली ज्ञात_होस्ट फ़ाइल का उपयोग करने के लिए कॉन्फ़िगर करके, और दूरस्थ होस्ट पहचान कुंजी की पुष्टि करने के लिए आपसे पूछने के लिए नहीं कहती है।

Comments

यह पेपर की-चेकिंग को बंद करने के बारे में है। मैं कुंजी जाँच रखना चाहता हूँ, और मैं इसे हर बार अस्वीकार नहीं करना चाहता हूँ hostnameलिनुत या OSX में रिबूट किया गया है

— Frédéric Grosshans

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

— तमारा विजसमैन

Answer 7

चूंकि आप सख्त होस्ट कुंजी की जाँच करना चाहते हैं, इसलिए मैं उन्हें विभिन्न known_hostsफ़ाइलों का उपयोग करना चाहूंगा । ऐसा करने के लिए, अपनी ~/.ssh/configफ़ाइल (या /etc/ssh/ssh_configयदि आपको कई स्थानीय उपयोगकर्ता खातों पर काम करने के लिए इसकी आवश्यकता है) फ़ाइल को इस तरह सेट करें:

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

, $REALHOSTNAMEवास्तविक होस्टनाम या आईपी पते के साथ, निश्चित रूप से। (इससे कोई फर्क नहीं पड़ता कि आप किसे चुनते हैं, जब तक आप "होस्टनाम" के बाद कुछ चुनते हैं, जो आईपी पते पर हल होगा, लेकिन मैं सामान्य रूप से, केवल सामान्य सिद्धांतों पर आईपी पते के लिए होस्ट नाम का उपयोग करूंगा।)

तब ssh myserver.linuxऔर ssh myserver.osxइस प्रकार अलग-अलग होस्ट कुंजी हो सकती हैं, लेकिन आप अभी भी चेकिंग प्राप्त करते हैं। यदि यह लिनक्स ऊपर है और आप ओएस एक्स (या इसके विपरीत) टाइप करते हैं, तो आपको चेतावनी मिलेगी (जो मुझे लगता है कि वांछित प्रभाव है)।

यदि मुझे यह समस्या थी, तो मुझे यकीन है कि मुख्य known_hostsफ़ाइल में कुछ पूरी तरह से गलत था जो या तो एक से मेल नहीं खाता है, ताकि यदि आप $REALHOSTNAMEइसके बजाय टाइप करते हैं तो आपको myserver.osxचेतावनी मिलती है। :-) मैं ऐसा कुछ डाल कर करूँगा

<ip-address-of-github.com> $REALHOSTNAME

मेरे में /etc/hosts, फिर एक कर रहा है ssh $REALHOSTNAMEऔर नई कुंजी को स्वीकार करना, फिर उस प्रविष्टि को बाहर निकालना।