Git का कहना है "चेतावनी: स्थायी रूप से ज्ञात मेजबानों की सूची में जोड़ा गया"

192

जब भी मैं रिमोट से बातचीत करने के लिए git का उपयोग करता हूं, जैसे खींचने या धक्का देने पर, मुझे निम्न संदेश दिखाया जाता है:

चेतावनी: ज्ञात मेजबानों की सूची में स्थायी रूप से '...' (RSA) जोड़ा गया।

मैं इस कष्टप्रद संदेश को प्रदर्शित करने से कैसे रोक सकता हूं? यह केवल एक झुंझलाहट है - सब कुछ ठीक से काम करता है।

— डोनाल्ड टेलर
स्रोत

1

क्या आपको वास्तव में हर बार मतलब है ? क्या यह आपको फॉर्म का संकेत दे रहा है

The authenticity of host '...' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)?

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

— कास्काबेल

1

हाँ। <i> हर </ i> समय। हालाँकि, मैं "क्या तुम्हें यकीन नहीं है ..." संदेश - शायद मैंने इसे दबा दिया है।

— डोनाल्ड टेलर

मेजबान में सूचीबद्ध है ~/.ssh/known_hosts? (क्या इसे 5000 बार सूचीबद्ध किया गया है?) ~/.ssh/configमौजूद है / कुछ भी शामिल है (विशेष रूप से एक मूल्य के लिए StrictHostKeyChecking)?

— कैस्केबेल

होस्ट को उस फ़ाइल में एक बार सूचीबद्ध किया गया है, और यह केवल प्रविष्टि है।

— डोनाल्ड टेलर

2

मैं अनुमान लगा रहा हूं कि आपकी known_hostsफ़ाइल की सामग्री खराब है। यह मेजबान कुंजी होना चाहिए, एक बहुत लंबी लाइन पर। यदि आपके पास केवल वहाँ होस्ट नाम है (उदाहरण के लिए) तो यह काम नहीं करेगा। मेरा सुझाव है कि आप इस फ़ाइल को हटा दें (यदि वास्तव में इसमें केवल इस एकल होस्ट के लिए जानकारी है) और SSH को अगली बार कनेक्ट होने पर इसे बनाने की अनुमति दें। उसके बाद चुप रहना चाहिए।

— ट्रिपल जू

240

समाधान: एक ~/.ssh/configफ़ाइल बनाएं और लाइन डालें:

UserKnownHostsFile ~/.ssh/known_hosts

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

यह समस्या मुझे काफी समय से परेशान कर रही थी। समस्या तब होती है क्योंकि Windows के लिए संकलित ओपनएसएसएच क्लाइंट ज्ञात_होस्ट फ़ाइल की जांच नहीं करता है~/.ssh/known_hosts

ssh -vvvvvvvvvvvvvvvvvvvvv git@github.com

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.

— जेरेमिया गौडी
स्रोत

9

हाँ, मैं किसी समस्या के उचित समाधान के लिए चेतावनी या त्रुटियों को दबाने पर विचार नहीं करता। ;)

— यिर्मयाह गौडी

1

हाल ही में, मैंने अपनी ubuntu मशीन पर इसी मुद्दे का सामना किया। ~/.ssh/id_rsaसर्वर से कनेक्ट करने के लिए एक अलग (मेरी डिफ़ॉल्ट से ) कुंजी का उपयोग करने के बाद मैंने इस तरह से व्यवहार करना शुरू कर दिया । जैसा कि @JeremiahGowdy ने उल्लेख किया है, मेरे पास है debug3: load_hostkeys: loading entries for host "172.16.3.101" from file "/dev/null"। /dev/nullमेरे द्वारा कुंजी बदलने के बाद SSH ज्ञात_होस्ट के रूप में उपयोग क्यों शुरू करता है ?

— एम-रिक

6

बहुत अच्छा काम करता है! अंत में बेवकूफाना चेतावनी बंद हो गई। विंडोज पर Btw, ~में ~/.ssh/configउपयोगकर्ता के घर फ़ोल्डर है। इसे आसानी से खोलने के लिए, Win-R दबाएं, Enter टाइप cmd करें । कमांड प्रॉम्प्ट आपके होम फोल्डर में पहले से ही खुला होना चाहिए। cd .ssh Enter टाइप करें , और उसके बाद Windows Explorer में फ़ोल्डर खोलने के लिए start . दर्ज करें। तब आप Notepad में config फाइल बना सकते हैं ( बचत करते समय कोई .txt एक्सटेंशन नहीं )। (प्रो उपयोगकर्ता कमांड प्रॉम्प्ट में एक नई फ़ाइल को सीधे गूंज सकते हैं ;))। एक git कमांड को रिमोट से दो बार चलाएं (जैसे git fetch), और आपका काम हो गया।

— ADTC

1

आपके पास ssh के लिए 20 v क्यों है?

— बुबाकजौबा

3

@bubakazouba जितनी अधिक v की है, उतनी ही अधिक क्रिया लॉग हो जाती है, उसके लिए डॉक्स जांचें। तीन पर्याप्त होंगे, बीस एक ओवरकिल हैं: D

— पेट्र मानेक

90

निम्न पंक्ति को अपने ssh config फाइल ($ HOME / .ssh / config) में जोड़ें:

LogLevel=quiet

यदि कमांड लाइन से ssh चल रहा है तो कमांड स्ट्रिंग में निम्न विकल्प जोड़ें:

-o LogLevel=quiet

उदाहरण के लिए, निम्नलिखित मशीन पर स्थापित gcc संस्करण को प्रिंट करता है ।example.org (और कोई चेतावनी नहीं):

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -o LogLevel=quiet \
    -i identity_file \
    machine.example.org \
    gcc -dumpversion

— काइल क्लोएपर
स्रोत

1

"लॉग इन" फ़ाइल में "लॉवेल = शांत" को जोड़ने से काम हुआ। धन्यवाद।

— डोनाल्ड टेलर

3

सुरक्षा बनाए रखने के लिए, "होस्टल" अनुभाग के अंदर "लॉगलेव = चुप" रखना अच्छा होगा।

— जो

39

LogLevel=quietएक बुरा विचार है, वह चाहता है कि सभी त्रुटियों को प्रदर्शित किया जाए, वह सिर्फ इस विशिष्ट अप्रिय त्रुटि से बचना चाहता है। संभवतः क्योंकि उसने ssh को फ़ाइल के /dev/nullरूप में उपयोग करने के लिए छल किया known_hostsथा, शायद इसलिए कि वह known_hostsफिंगरप्रिंट चेकिंग को बंद करना चाहता था , लेकिन नहीं कर सकता था, क्योंकि ssh ओवरलोडर्स ने उसे अनुमति नहीं दी थी।

— एलाजार लीबोविच

@bukzor loglevel=errorअभी भी "कनेक्शन <सर्वर> बंद" प्रदर्शित करता है जब कनेक्शन समाप्त हो जाता है, जो स्क्रिप्टिंग के लिए वास्तव में कष्टप्रद भी है।

— Guss

मैंने इसे डाउनवोट किया क्योंकि यह वास्तव में समस्या का समाधान नहीं करता है। यह सिर्फ इसे छुपाता है।

— अलबौदी

60

इन त्रुटियों को देखने से बचने के लिए फ़ाइल में सेट LogLevelकरें ERROR(नहीं QUIET) ~/.ssh/config:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

— user1193229
स्रोत

2

इसने मेरे मामले में सबसे अच्छा काम किया - या आप कमांड लाइन पर "-oLogLevel = ERROR" निर्दिष्ट कर सकते हैं

— ब्रैड

5

यह संदेश SSH का है, जो आपको चेतावनी दे रहा है कि आप एक ऐसे होस्ट से जुड़ रहे हैं, जिसे आपने पहले कभी कनेक्ट नहीं किया है। मैं इसे बंद करने की सिफारिश नहीं करूंगा, क्योंकि इसका मतलब होगा कि आप एक मेजबान कुंजी को बदलने के बारे में चेतावनी याद कर सकते हैं, जो आपके SSH सत्र पर MITM हमले का संकेत दे सकता है।

— जेसन कैरीरो
स्रोत

1

लेकिन मैं इसे प्रत्येक दिन 10-15 बार जोड़ता हूं, और फिर भी मुझे यह चेतावनी मिलती है।

— डोनाल्ड टेलर

@JackB। देखो ~/.ssh/known_hostsऔर देखो कि क्या आपका मेजबान वहाँ है।

— बोरेलिड

क्या किसी कारण से चाबी बदल रही है? फ़ाइल में फिंगरप्रिंट की जाँच करें। फिंगरप्रिंट जो ssh द्वारा आउटपुट है। इसके अलावा, आपके .ssh डायरेक्टरी का मोड 0700 पर सेट है?

— जेसन कैरीरो

2

@ जैसनकार्रेइरो, मैं एक बड़ा लड़का हूं, मुझे पता है कि कोई भी मेरे रैक के अंदर MITM के हमले को नहीं खींचेगा, सुरक्षा एक व्यापार है, और मैं चाहता हूं कि नए कंप्यूटर बॉक्स से बाहर काम कर सकें, जिसमें सीए या प्रबंधन करने की कोई आवश्यकता नहीं है। ssh-keyscan।

— एल्जार लीबोविच

4

आपके लिए चेतावनी संदेशों को दबाने के sshलिए निम्नलिखित लाइनें जोड़ सकते हैं ~/.ssh/config:

Host *
LogLevel error

यह चेतावनी को अक्षम कर देगा, लेकिन त्रुटि संदेशों को नहीं। यदि आप एक अधिक व्यवस्थित नियंत्रण चाहते हैं, तो अन्य सेटिंग्स की तरह ~/.ssh/configआप LogLevelप्रति-होस्ट आधार पर कॉन्फ़िगर कर सकते हैं ।

— स्टीफन श्मिट
स्रोत

2

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

यह अक्सर फिर से बनाई गई आभासी मशीनों से जुड़ने के लिए होता है, जो एक ही आईपी पते के साथ कुंजी को बदलता है

उपाय

यदि आपके पास केवल एक प्रविष्टि है, तो आप हटा सकते हैं ~/.ssh/known_hosts फ़ाइल , और पहले कनेक्शन के बाद, कि कुंजी होगी, और उसके बाद कोई चेतावनी संदेश नहीं।

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

$ ssh-keygen -R <hostname>

यह मेरे लिए ठीक काम करता है

— लैरी कै
स्रोत

0

यदि आप GitHub से एक रिपॉजिटरी का उपयोग कर रहे हैं , तो इस समस्या को पूरी तरह से दूर करने के बजाय, URL के HTTPS संस्करण का उपयोग करने पर विचार करें:

इसके बजाय HTTP बटन पर क्लिक करें और उस URL को क्लोन करें

यदि आप Windows GitHub एप्लिकेशन के भीतर से अपने रिपॉजिटरी को क्लोन करते हैं, तो यह रिमोट URL के लिए इसका उपयोग करता है। शायद वे कुछ जानते हैं जो हम नहीं जानते हैं।

— Ricket
स्रोत

नोट: यदि आप निजी कुंजी प्रमाणीकरण का उपयोग करते हैं, तो आप HTTP (एस) का उपयोग नहीं कर सकते।

— क्वर्टीजगुई

0

मेरे पास एक ही प्रश्न है, और मैंने पाया कि .sshमेरी कोई फ़ाइल नहीं है ~। इसलिए मैं केवल पथ के .sshतहत निर्देशिका बनाता हूं ~, और समस्या हल हो गई है।

— क्रिस रूफ
स्रोत

0

जब मैंने विंडोज मशीन का उपयोग शुरू किया तो मैं उसी मुद्दे पर आ गया। मेरे मामले में ऐसा इसलिए था क्योंकि मेरा SSH सेटअप नहीं हुआ था। Github का SSH सेटअप पर एक बहुत सटीक दस्तावेज है। एक बार ध्यान देने के बाद, समस्या हल हो गई।

https://help.github.com/articles/checking-for-existing-ssh-keys/ https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it- को-ssh-एजेंट /

— Zeena
स्रोत

0

Ssh कुंजी जोड़ें

ssh-keygen -t rsa -b 4096 -C "abc@abc.com"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/bitbucket_rsa

टोकरा विन्यास फाइल

crate ~/.ssh/config

नीचे पंक्ति जोड़ें।

UserKnownHostsFile ~/.ssh/known_hosts

फिर पब कीज जोड़ें और अपनी रिपॉजिटरी को क्लोन करें ... हो गया .....

— Thanuja
स्रोत

0

मुझे लिनक्स / सेंट ओएस वीएम में एक ही त्रुटि का सामना करना पड़ा था और यह इसलिए था क्योंकि आईपी पुनरारंभ होने के बाद बदल रहा था। इस समस्या को हल करने के लिए, मैंने नेटवर्क में एक स्थिर आईपी को परिभाषित किया और उस प्रविष्टि को / etc / मेजबान फ़ाइल में जोड़ा। स्टेटिक आईपी के लिए थोड़ा अधिक रेंज वैल्यू का उल्लेख करें। उदाहरण के लिए यदि आपका वर्तमान IP (ipconfig / ifconfig) 192.168.0.102 है, तो अगली बार पुनः आरंभ करने के बाद यह 192.168.0.103 हो सकता है। तो अपने स्थिर IP को IPV4 सेटिंग्स में 192.168.0.181 के रूप में परिभाषित करें, जो चाल करना चाहिए।

— विग्नेश मेनन
स्रोत

कीवर्ड्स को हाइलाइट करने की कोशिश करें और उस प्रारूप के साथ स्पष्ट

— रहें जो

0

मेरे मामले में, यह इसलिए था क्योंकि सर्वर सेट करने वाले व्यवस्थापक ने इन विकल्पों को सेट किया था ~/.ssh/config

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

जो ~/.ssh/known_hostsफ़ाइल का उपयोग नहीं करके ज्यादातर मामलों के लिए ठीक काम किया है । लेकिन एंटरप्राइज गिटलैब रेपो के लिए, हर बार इसने "चेतावनी: स्थायी रूप से जोड़ा ... ज्ञात मेजबानों की सूची में।"

मेरा समाधान यह था कि मैं उस UserKnownHostsFile /dev/nullलाइन पर टिप्पणी करूं, जिसके निर्माण की अनुमति थी ~/.ssh/known_hosts। इसके बाद इसने कोई और चेतावनी नहीं दी।

आपके पास अपनी पुरानी / अमान्य प्रविष्टियाँ भी हो सकती हैं known_hosts।

# find entry in ~/.ssh/known_hosts
ssh-keygen -F <hostname>

# delete entry in ~/.ssh/known_hosts
ssh-keygen -R <hostname>

— wisbucky
स्रोत

-1

मैं निरंतर नीचे की ओर बढ़ने के कारण अपना समाधान कर रहा हूं।
यह वास्तव में एसएसएच ग्राहक के स्रोत कोड को हैक किए बिना सबसे अच्छा समाधान था।
अगर किसी को दिलचस्पी है, तो संपादित इतिहास की जांच करें।

— जॉन
स्रोत