सवाल "Known_hosts में सही मेजबान कुंजी जोड़ें" / मेजबाननाम के लिए एकाधिक ssh होस्ट कुंजी?


एक कंप्यूटर में ssh करने की कोशिश मैं नियंत्रण, मुझे परिचित संदेश मिल रहा है:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

मैंने वास्तव में कुंजी बदल दी थी। और मैंने कुछ दर्जन पोस्टिंग पढ़ीं कि इस समस्या को हल करने का तरीका पुरानी कुंजी को हटाकर है known_hosts फ़ाइल।

लेकिन मैं क्या चाहता हूं कि एसएसएच पुरानी कुंजी और नई कुंजी दोनों को स्वीकार करे। त्रुटि संदेश में भाषा ("Add correct host key") बताता है कि पुराने को हटाने के बिना सही होस्ट कुंजी जोड़ने का कोई तरीका होना चाहिए।

मैं पुरानी को हटाने के बिना नई होस्ट कुंजी को जोड़ने का तरीका समझने में सक्षम नहीं हूं।

क्या यह संभव है, या त्रुटि संदेश सिर्फ बेहद भ्रामक है?


121
2017-10-13 14:01


मूल


यह मेजबान कुंजी है जो त्रुटि उत्पन्न कर रही है। एक मेजबान में एक और केवल एक कुंजी होनी चाहिए। इसका क्लाइंट या उपयोगकर्ता कुंजी के साथ कुछ लेना देना नहीं है। क्या आपके पास एक आईपी पता है जो अलग मेजबान या कुछ के बीच तैरता है? - David Schwartz
मेरे मामले में मुझे पता है कि मैं कुछ चीजों के साथ झुकाव के दौरान निकट भविष्य में दो कुंजियों के बीच स्विच करने जा रहा हूं। ऐसा लगता है कि यह आपके द्वारा सुझाए गए कई होस्ट की स्थिति वाले एक आईपी में भी उपयोगी होगा। मुख्य रूप से मैं सिर्फ यह जानना चाहता हूं कि किसी भी विशेष व्यावहारिक अनुप्रयोग के अलावा मेरी अपनी शिक्षा के लिए यह संभव है या नहीं। - Samuel Edwin Ward


जवाब:


  1. अपने सर्वर की आरएसए कुंजी प्राप्त करें:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. और ग्राहक पर, इस कुंजी को जोड़ें ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

126
2017-10-13 14:38



यह काम किया! हालांकि, मैं "हैशकनाउनहोस्ट्स" का उपयोग कर रहा हूं, इसलिए प्रविष्टि जगह से थोड़ी दूर दिखाई दे रही थी। सौभाग्य से ssh_config (5) ने मुझे एसएसएच-कीजेन (1) की ओर इशारा किया जो समझाया कि मैं "एसएसएच-कीजेन-एच" का उपयोग कर सकते हैं, जो बिना छेड़छाड़ वाली प्रविष्टियों को हैश कर सकता है। धन्यवाद! - Samuel Edwin Ward
यह "काम करता है" लेकिन आप कुंजी की पुष्टि नहीं कर रहे हैं, इसलिए आप एमआईटीएम हमलों के लिए कमजोर हैं ... - JasperWallace
@JasperWallace, जब तक पहला कदम सुरक्षित कनेक्शन पर किया जाता है (उदाहरण के लिए लोकलहोस्ट का उपयोग करके) यह बहुत सुरक्षित होना चाहिए, मुझे लगता है - ony
क्या सर्वर से सभी प्रमुख प्रकार इकट्ठा करने का कोई तरीका है? कभी-कभी आप नहीं जानते कि वे आरएसए, डीएसए, ईसीडीएसए, आरएसए 1 ... आदि हैं। - Sopalajo de Arrierez
@ सोपाजोड एरियारेज़ एक ही मैनपेज यह भी कहता है कि आप अल्पविरामों के साथ प्रकार अलग कर सकते हैं, इसलिए करें ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - लेकिन खोजने का एकमात्र कारण है rsa1तथा dsa कुंजी उन सर्वरों की पहचान करना है जिन्हें अपग्रेड / पुन: कॉन्फ़िगर किया जाना आवश्यक है - kbolino


निकालें कि ज्ञात_होस्ट से प्रविष्टि का उपयोग कर:

ssh-keygen -R *ip_address_or_hostname*

यह समस्याग्रस्त आईपी या होस्टनाम से हटा देगा known_hosts फ़ाइल और फिर से कनेक्ट करने का प्रयास करें।

मैन पेज से:

-R hostname
  किसी ज्ञात_होस्ट फ़ाइल से होस्टनाम से संबंधित सभी कुंजियों को हटा देता है। यह विकल्प हैश होस्ट को हटाने के लिए उपयोगी है (-एच विकल्प देखें   ऊपर)।


74
2018-02-09 06:49



"पुराने को हटाने के बिना नई होस्ट कुंजी कैसे जोड़ें।" - Samuel Edwin Ward
यह सबसे अच्छा समाधान है! - Thomas Decaux
इसमें 1 9 वोट कैसे हैं? यह पूछे गए सवाल का जवाब देने के करीब नहीं आता है .. - Molomby
जब मैं "गिट एसएसएच अपडेट होस्ट कुंजी स्वचालित रूप से" के लिए Google हूं तो आपका प्रश्न दूसरे स्थान पर आता है। यह जवाब वह है जिसे मैं ढूंढ रहा था। जो भी मैं चाहता हूं उसके साथ एक नया प्रश्न खोलना इसे डुप्लिकेट के रूप में बंद कर सकता है। - Jason Goemaat
होस्टनाम भी काम करता है - damluar


एक बहुत ही सरल तरीका है:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

फिर मूल कुंजी को साफ़ करने के लिए ज्ञात_होस्ट संपादित करें, फिर होस्ट का उपयोग करके एसएसएच:

ssh name@computer

यह स्वचालित रूप से नई कुंजी जोड़ देगा; फिर दो फाइलों की तुलना करें। मेल्ड जैसे प्रोग्राम दो फाइलों की तुलना करने का एक अच्छा तरीका है। फिर ज्ञात_होस्ट्स को दोनों कुंजी रखने के लिए फ़ाइलों को मर्ज करें

दो कुंजी रखने के लिए मेरा 'कारण' यह है कि गंतव्य सिस्टम मल्टीबूट है, भले ही मैं कहता हूं कि इंस्टॉलेशन में चाबियाँ सिंक्रनाइज़ करने का एक तरीका है, यह एकाधिक चाबियों को अनुमति देने के लिए अधिक सरल लगता है।

संपादित करें 2015/06

मुझे इसे जोड़ना, फिर से संशोधित करना चाहिए, कि मुझे एक आसान तरीका दिखाई देता है [जब तक कि प्रवेश पहचान योग्य हो, आमतौर पर मेजबाननाम / आईपी पते से त्रुटि संदेश से अपने विशिष्ट स्थान को संदर्भित करता है];

  1. 'पुरानी' प्रविष्टि की शुरुआत में # जोड़ने के लिए ज्ञात_होस्ट संपादित करें ज्ञात_होस्ट अस्थायी रूप से
  2. [मेजबान को एसएसएच] कनेक्ट करें, नई कुंजी 'स्वचालित' जोड़ने के लिए संकेत से सहमत हों
  3. फिर # को हटाने के लिए ज्ञात_होस्ट को दोबारा संपादित करें

यहां तक ​​कि HostKeyAlias ​​विकल्प भी है

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

उसके बाद, एसएसएच क्लाइंट उपनाम के तहत नई कुंजी जोड़ता है, तो आप या तो उपनाम के लिए 'वास्तविक' होस्टनाम / आईपी पते को प्रतिस्थापित करने के लिए ज्ञात_होस्ट संपादित कर सकते हैं या उस होस्ट के उस अवतार से कनेक्ट कर सकते हैं जो उपनाम विकल्प के साथ हमेशा होता है


16
2018-04-30 22:29



यह 'मिलाया'? meldmerge.org - Samuel Edwin Ward
यह meld है :) apt-get / yum install name बस मिलाया जाता है - Mark
मैंने आपके सुझाव का एक संस्करण किया जो अच्छी तरह से काम करता था - सीपी, एमवी, फिर एसएसएच, फिर बिल्ली ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; एमवी टीएमपी ~ /। एसएसएच / ज्ञात_होस्ट्स - Peter N Lewis


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

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

ज्ञात_होस्ट फ़ाइल होस्ट नाम से फिंगरप्रिंट सहेजती है, भले ही यह एक ही आईपी पता है, प्रत्येक अद्वितीय होस्ट नाम को एक अलग प्रविष्टि मिलती है।

जब भी मैं एक नई प्रणाली का उपयोग करता था तब मैं मेजबान फाइलों में नाम जोड़ने में बीमार हो गया था इसलिए आईपी पते पर अग्रणी शून्य का उपयोग करके मैं भी एक आलसी तरीके से आया:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

(Uncononicalized) आईपी पते की प्रत्येक भिन्नता ज्ञात_होस्ट में अपनी प्रविष्टि प्राप्त करती है।


7
2017-11-04 02:28



ओपनएसएसएच लोग मेरे लिए बुद्धिमान हो गए, यह छेड़छाड़ अब हाल के संस्करणों में काम नहीं करती है। - Mike
आप उपयोग कर सकते हैं CheckHostIP no में ~/.ssh/config अभी भी छेड़छाड़ का उपयोग करने में सक्षम होने के लिए। आप वहां अपने उपनामों को भी परिभाषित कर सकते हैं ताकि आपको परेशान न हो /etc/hosts और परिभाषित करें CheckHostIP no केवल इस 3 होस्टनाम के लिए। - GnP


यदि आपके क्लाइंट और सर्वर दोनों के पास ओपनएसएसएच 6.8 या नया है, तो आप इसका उपयोग कर सकते हैं UpdateHostKeys yes आपके विकल्प ssh_config या ~/.ssh/config। उदाहरण के लिए:

Host *
    UpdateHostKeys yes

यह एसएसएच को सभी होस्ट कुंजियों को स्टोर करता है जो सर्वर को करना पड़ता है known_hosts, और जब कोई सर्वर एक होस्ट कुंजी को बदलता या हटा देता है, तो कुंजी भी आपके में बदल जाती है या हटा दी जाती है known_hosts


2
2017-09-22 04:28



यह अब तक का सबसे उपयोगी उत्तर है! यद्यपि यह स्पष्ट रूप से मूल प्रश्न को हल करने का कोई तरीका नहीं प्रदान करता है यदि कोई होस्ट कुंजी पहले से बदल दी गई है, तो अन्य सभी उत्तरों असुरक्षित हैं क्योंकि वे नई होस्ट कुंजी को सत्यापित नहीं करते हैं। यह विकल्प आपको नई होस्ट कुंजी पर सुरक्षित रोलओवर करने की अनुमति देता है। - Jaap Eldering


मुझे नहीं लगता कि आप दो चाबियों के साथ क्यों काम करना चाहते हैं, लेकिन आप निश्चित रूप से एक से अधिक वैध कुंजी जोड़ सकते हैं ~/.ssh/known_hosts फ़ाइल, लेकिन आपको इसे मैन्युअल रूप से करना होगा।

एक और समाधान का उपयोग करने के लिए हो सकता है StrictHostKeyChecking=no इस विशिष्ट मेजबान के लिए विकल्प:

ssh -o StrictHostKeyChecking=no user@host

जो आप अपने उपनाम में डाल सकते हैं ~/.profile या कुछ समान है।

alias hc=ssh -o StrictHostKeyChecking=no user@host

1
2017-10-13 14:49



StrictHostKey चेकिंग इस मामले में मदद नहीं प्रतीत होता है; स्पष्ट रूप से यह केवल व्यवहार को निर्दिष्ट करता है जब होस्ट ज्ञात_होस्ट फ़ाइल में नहीं होता है। यहां उल्लेख किया गया है: gossamer-threads.com/lists/openssh/dev/45349#45349 - Samuel Edwin Ward
यह यहाँ काम करता है। आपको चेतावनी मिलेगी, लेकिन लॉगिन जारी है। - Sven♦
अजीब है कि। क्या आप पासवर्ड प्रमाणीकरण का उपयोग कर रहे हैं? क्या आप ओपनएसएसएच का उपयोग कर रहे हैं? - Samuel Edwin Ward


अगर तुम केवल तब एक स्थानीय नेटवर्क पर एसएसएच ...

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

जैसे

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

फिर नया बफर (फ़ाइल) को सहेजने के लिए स्पेस, बैकस्पेस cntl + x और 'y' दबाएं। इसका बुरा अभ्यास लेकिन ठीक है, आप नियमित रूप से अपने स्थानीय नेटवर्क के बाहर ssh'ing नहीं कर रहे हैं (उदाहरण के लिए एक यूनी या काम सर्वर)

एक सुरक्षित स्थानीय नेटवर्क पर यह सुरक्षित है क्योंकि आप केवल मध्य हमले में एक आदमी नहीं प्राप्त कर सकते हैं।

आप समझने वाले कोड का उपयोग करना हमेशा बेहतर होता है!


0
2018-06-15 21:44



पूरे पोंछते हुए known_hosts फाइल प्रत्येक बार एसएसएच द्वारा प्रदान की जाने वाली अधिकांश सुरक्षा को अस्वीकार करने जा रही है। - kasperd
दरअसल, मैं तर्क दूंगा कि एक सुरक्षित आंतरिक नेटवर्क पर, कोड को समझने और कोड की प्रतिलिपि बनाने की तुलना में सुरक्षा को बाधित करना सुरक्षित है। बाहरी नेटवर्क पर स्थिति अलग होगी। - Aaron