ssh: मेजबान 'hostname' की प्रामाणिकता स्थापित नहीं की जा सकती

153

जब मैं एक मशीन के लिए ssh, कभी-कभी मुझे यह त्रुटि चेतावनी मिलती है और यह "हां" या "नहीं" कहने का संकेत देता है। स्क्रिप्ट से चलने पर यह कुछ परेशानी का कारण बनता है जो स्वचालित रूप से अन्य मशीनों के लिए ssh।

चेतावनी संदेश:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

क्या स्वचालित रूप से "हां" कहने या इसे अनदेखा करने का कोई तरीका है?

ssh ssh-keys rsa-key-fingerprint

— सेंथिल ए कुमार
स्रोत

27

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

— पीटर बैग्नॉल

3

यह उस ssh कुंजी का उपयोग करके सर्वर में बदलाव के कारण हो सकता है, या यह आपके और आपके द्वारा बैठे सर्वर के बीच किसी के द्वारा सब कुछ सुनने / प्राप्त करने के कारण हो सकता है।

— derekdreery

इस त्रुटि का कारण क्या हो सकता है?

— ऐयू

मैं पीटर की बात से असहमत हूं। किसी बड़े संगठन में किसी और को पाने के लिए इस तरह की समस्याओं को ठीक करने की कोशिश की जाती है, जब आप सिर्फ अपना काम करने की कोशिश कर रहे होते हैं।

— श्रीधर सरनोबत

कई बड़े संगठन @SridharSarnobat के सुझाव के बिल्कुल विपरीत हैं। आप है यकीन है कि सही लोगों की समस्याओं के उन प्रकार का समाधान करने के लिए, और उनके आसपास काम करने का प्रयास कर सिर्फ बातें बदतर बना देता है।

— जेम्स मूर

135

अपने ssh क्लाइंट के आधार पर, आप StrictHostKeyChecking विकल्प को कमांड लाइन पर नहीं सेट कर सकते हैं, और / या एक अशक्त ज्ञात_होस्ट फ़ाइल को कुंजी भेज सकते हैं। आप इन विकल्पों को अपनी कॉन्फ़िगरेशन फ़ाइल में, सभी होस्ट के लिए या आईपी पते या होस्ट नामों के दिए गए सेट के लिए भी सेट कर सकते हैं।

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

संपादित करें

@IanDunn नोट के रूप में, ऐसा करने के लिए सुरक्षा जोखिम हैं। यदि आप जिस संसाधन से जुड़ रहे हैं, वह किसी हमलावर द्वारा खराब कर दिया गया है, तो वे संभावित रूप से गंतव्य सर्वर की चुनौती को आप तक पहुंचा सकते हैं, आपको यह सोचकर बेवकूफ बना रहे हैं कि आप दूरस्थ संसाधन से जुड़ रहे हैं जबकि वास्तव में वे उस संसाधन से जुड़ रहे हैं आपकी साख। आपको ध्यान से विचार करना चाहिए कि HostKeyChecking को छोड़ने के लिए अपने कनेक्शन तंत्र को बदलने से पहले यह एक उचित जोखिम है या नहीं।

संदर्भ ।

— कोरी
स्रोत

40

मुझे लगता है कि सुरक्षा के निहितार्थों के बारे में चेतावनी के बिना यह सिफारिश करना गैरजिम्मेदार है। superuser.com/a/421084/121091 एक बेहतर जवाब है IMO।

— इयान दून

5

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

— cori

6

मुझे विश्वास नहीं हो रहा है कि बहुत से लोगों ने इस उत्तर को उकेरा है और यह भी कि इसे प्रश्नकर्ता ने स्वीकार किया है। यह दृष्टिकोण सुरक्षा जांच को दरकिनार करता है और इसे दूरस्थ होस्ट से जोड़ता है। जांचें कि क्या ज्ञात_होस्ट फ़ाइल ~ / .ssh / फ़ोल्डर में लिखने की अनुमति है। यदि नहीं, तो इस उत्तर का उपयोग करें stackoverflow.com/a/35045005/2809294

— ARK

जब तक आप जानते हैं कि आप क्या कर रहे हैं, यह सबसे अच्छा समाधान है। मेरे पास एक आंतरिक वेब साइट है जो हम स्वचालित रूप से उस से कनेक्ट करते हैं जिसमें MANY है, (प्रभावी रूप से यादृच्छिक) IP पते को अपडेट करते हुए। मैंने इसे ~ / .ssh / config में जोड़ा और यह सिर्फ काम करता है। माइंड यू , मुझे पता है कि यह साइट है जो मुझे लगता है कि यह है और यदि यह नहीं है, तो बुरे लोगों को कोई फायदा नहीं है, क्योंकि मुझे पता है कि क्या डेटा स्थानांतरित किया जा रहा है।

— user1683793

75

पुराना सवाल जो एक बेहतर जवाब का हकदार है।

आप अक्षम किए बिना इंटरएक्टिव प्रॉम्प्ट को रोक सकते हैं StrictHostKeyChecking(जो असुरक्षित है)।

अपनी स्क्रिप्ट में निम्नलिखित तर्क शामिल करें:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

यह जाँचता है कि सर्वर की सार्वजनिक कुंजी है या नहीं known_hosts। यदि नहीं, तो यह सर्वर से सार्वजनिक कुंजी का अनुरोध करता है और इसे इसमें जोड़ता है known_hosts।

इस तरह से आप केवल एक बार ही मैन-इन-द-मिडिल हमले के संपर्क में आते हैं, जो निम्न हो सकता है:

यह सुनिश्चित करना कि स्क्रिप्ट पहली बार किसी सुरक्षित चैनल पर कनेक्ट हो
मैन्युअल रूप से उंगलियों के निशान की जांच करने के लिए लॉग या ज्ञात_होस्ट का निरीक्षण करना (केवल एक बार किया जाना है)

— ग्रेज़गोरज़ लुसीवो
स्रोत

4

या अपने इन्फ्रास्ट्रक्चर कॉन्फ़िगरेशन सेटअप के हिस्से के रूप में सभी मशीनों के लिए ज्ञात_होस्ट फ़ाइल का प्रबंधन करें।

— थिलो

1

ध्यान दें कि ssh-keyscan ProxyCommand के साथ काम नहीं करता है: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2

— रिचलेव

1

यह अपेक्षा के अनुरूप काम नहीं करेगा। `ssh-keygen -F $IP` "`ssh-keygen -F $IP`"(उद्धरण में) होना चाहिए , दूसरे मामले में इसे स्ट्रिंग के रूप में व्याख्यायित नहीं किया जाएगा

— avtomaton

या ssh-kegen वापसी मूल्य का उपयोग कर एक oneliner के रूप में:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts

— Gohu

38

अक्षम करने (या अक्षम करने को नियंत्रित करने के लिए) की शुरुआत में निम्न पंक्तियाँ जोड़ें /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

विकल्प:

होस्ट सबनेट *सभी आईपी में अप्रतिबंधित पहुंच की अनुमति दे सकता है।
/etc/ssh/ssh_configवैश्विक कॉन्फ़िगरेशन के लिए या ~/.ssh/configउपयोगकर्ता-विशिष्ट कॉन्फ़िगरेशन के लिए संपादित करें ।

Http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html देखें

Superuser.com पर ऐसे ही सवाल - देखें https://superuser.com/a/628801/55163

— जिम फ्रेड
स्रोत

19

सुनिश्चित करें कि ~/.ssh/known_hostsलेखन योग्य है। उसने मेरे लिए इसे हल कर दिया।

— रिचर्ड
स्रोत

4

क्या सभी को ज्ञात_होस्ट को लिखने की अनुमति देना सुरक्षित है?

— उर्फ़रम

2

@ शकराम निश्चित रूप से नहीं। आमतौर पर आप यह चाहते हैं कि यह केवल उस .sshफ़ोल्डर का मालिक हो, जो इसके लिए उपयुक्त हो ।

— 2rs2ts

अनुमतियाँ 0400इष्टतम हैं (कृपया मुझे किसी को भी सुधारें) हालांकि मेरे मामले में मुद्दा बस इतना था कि .sshमेरे उपयोगकर्ता के लिए फ़ोल्डर का स्वामित्व बदल गया था - मेरी अपनी 0400 अनुमतियों को अमान्य कर रहा था। sudoमेरे पास स्वामित्व बदलने से मेरी समस्या हल हो गई।

— चारनी काये

यह एक मेरे लिए मुद्दा तय किया।

— शिवाजी

14

इसके बारे में जाने का सबसे अच्छा तरीका 'स्ट्रिक्टहॉस्टकेकचिंग' के अलावा 'बैचमैड' का उपयोग करना है। इस तरह, आपकी स्क्रिप्ट एक नया होस्टनाम स्वीकार करेगी और इसे ज्ञात_होस्ट फ़ाइल में लिख देगी, लेकिन इसके लिए हाँ / कोई हस्तक्षेप की आवश्यकता नहीं होगी।

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

— Cory Ringdahl
स्रोत

10

आम तौर पर '~ / .ssh / config' पर स्थित अपनी विन्यास फाइल को संपादित करें, और फ़ाइल के भीगने पर, नीचे की पंक्तियों को जोड़ें

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

उपयोगकर्ता सेट का your_login_userकहना है कि यह सेटिंग आपके_लगिनी_सुपर
स्ट्रिक्टहॉस्टकेय के अंतर्गत आती है, कोई भी सेट करने के लिए शीघ्रता से बचना होगा
IdentityFile RSA कुंजी के लिए पथ है

यह मेरे और मेरी लिपियों के लिए काम करता है, आपको शुभकामनाएँ।

— कार्लोस एम.जी.टी.
स्रोत

धन्यवाद यह वास्तव में दिन बचाया। लेकिन इसके लिए अंतिम पंक्ति क्या है IdentityFile? यह इसके बिना भी काम करने लगता है ..

— सुपरसन

7

यह चेतावनी सुरक्षा सुविधाओं के कारण जारी की गई है, इस सुविधा को अक्षम न करें।

यह सिर्फ एक बार प्रदर्शित होता है।

यदि यह अभी भी दूसरे कनेक्शन के बाद दिखाई देता है, तो समस्या संभवतः known_hostsफ़ाइल को लिखने में है। इस मामले में आपको निम्न संदेश भी मिलेगा:

Failed to add the host to the list of known hosts

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

sudo chown -v $USER ~/.ssh/known_hosts

— Sfisioza
स्रोत

5

कोरी के जवाब के संदर्भ में, मैंने इसे संशोधित किया और कमांड के नीचे इस्तेमाल किया, जो काम कर रहा है। के बिनाexit , शेष कमांड वास्तव में रिमोट मशीन में प्रवेश कर रहा था, जो मुझे स्क्रिप्ट में नहीं चाहिए था

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

— चिंतामणि मंजरे
स्रोत

5

ऐसा करने -> chmod +w ~/.ssh/known_hosts। यह फ़ाइल में लिखने की अनुमति जोड़ता है ~/.ssh/known_hosts। उसके बाद known_hostsजब आप अगली बार कनेक्ट करेंगे तो दूरस्थ होस्ट फ़ाइल में जुड़ जाएगा।

— ARK
स्रोत

4

आदर्श रूप से, आपको एक स्व-प्रबंधित प्रमाणपत्र प्राधिकरण बनाना चाहिए। एक प्रमुख जोड़ी बनाने के साथ शुरू करें: ssh-keygen -f cert_signer

फिर प्रत्येक सर्वर की सार्वजनिक होस्ट कुंजी पर हस्ताक्षर करें: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

यह एक हस्ताक्षरित सार्वजनिक होस्ट कुंजी बनाता है: /etc/ssh/ssh_host_rsa_key-cert.pub

में /etc/ssh/sshd_config, बात HostCertificateइस फ़ाइल की: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Sshd सेवा को पुनरारंभ करें: service sshd restart

फिर SSH क्लाइंट पर, निम्नलिखित जोड़ें ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

उपरोक्त में शामिल हैं:

@cert-authority
डोमेन *.example.com
सार्वजनिक कुंजी की पूरी सामग्री cert_signer.pub

cert_signerसार्वजनिक कुंजी किसी भी सर्वर जिसका सार्वजनिक होस्ट कुंजी द्वारा हस्ताक्षरित भरोसा करेंगे cert_signerनिजी कुंजी।

यद्यपि इसके लिए क्लाइंट की ओर से एक बार के कॉन्फ़िगरेशन की आवश्यकता होती है, आप कई सर्वरों पर भरोसा कर सकते हैं, जिनमें अभी तक प्रावधान नहीं किया गया है (जब तक आप प्रत्येक सर्वर पर हस्ताक्षर करते हैं, वह है)।

अधिक जानकारी के लिए, इस विकी पृष्ठ को देखें ।

— रॉबर्ट चेन
स्रोत

2

आम तौर पर यह समस्या तब होती है जब आप कुंजियों को बहुत बार संशोधित करते हैं। सर्वर के आधार पर आपको सर्वर में उत्पन्न और पेस्ट की गई नई कुंजी को अपडेट करने में कुछ समय लग सकता है। इसलिए सर्वर में कुंजी और पेस्ट करने के बाद, 3 से 4 घंटे तक प्रतीक्षा करें और फिर प्रयास करें। समस्या का समाधान होना चाहिए। यह मेरे साथ हो चुका है।

— mk ..
स्रोत

2

इन्हें अपने / etc / ssh / ssh_config में जोड़ें

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

— केविन गुयेन
स्रोत

यहाँ और अधिक विस्तृत करें shellhacks.com/disable-ssh-host-key-checking

— sobelito

0

इसे होस्ट सर्वर में चलाएं यह प्रीमियर समस्या है

chmod -R 700 ~/.ssh

— रॉबर्ट ए
स्रोत

क्या आप लोगों को अधिकृत_की और सार्वजनिक कुंजी पर अनुमतियाँ बदलने के लिए 644 से 700 तक बदलने के लिए कह रहे हैं? और 600 से 700 तक निजी कुंजी?

— नुरेटिन

0

मेरे पास एक ही त्रुटि थी और इस तथ्य पर ध्यान आकर्षित करना चाहता था कि - जैसा कि यह सिर्फ मेरे साथ हुआ है - आपके पास बस गलत विशेषाधिकार हो सकते हैं।
आपने अपनी .sshनिर्देशिका को नियमित या rootउपयोगकर्ता के रूप में सेट किया है और इस प्रकार आपको सही उपयोगकर्ता होने की आवश्यकता है। जब यह त्रुटि दिखाई दी, मैं था, rootलेकिन मैं .sshनियमित उपयोगकर्ता के रूप में कॉन्फ़िगर किया गया था । बाहर निकलना rootतय है।

— Lavair
स्रोत

-3

मैं उस समस्या को हल करता हूं जो लिखित त्रुटि देता है:
त्रुटि:
मेजबान 'XXX.XXX.XXX' की प्रामाणिकता स्थापित नहीं की जा सकती।
RSA कुंजी फिंगरप्रिंट 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89 है।

समाधान:
1. किसी भी ओपनएसएसएच उपकरण को स्थापित करें।
2. रन कमांड ssh
3. यह इस तरह के होस्ट को जोड़ने के लिए करेगा। हाँ स्वीकार करें।
4. यह मेजबान ज्ञात होस्ट सूची में जोड़ देगा।
5. अब आप इस होस्ट से जुड़ सकते हैं।

यह समाधान अब काम कर रहा है ......

— राकेश कुमार गर्ग
स्रोत

इस सवाल का जवाब नहीं है। मूल (बहुत पुराना) प्रश्न स्क्रिप्ट के माध्यम से ऐसे संकेतों की स्वचालित रूप से पुष्टि करने की क्षमता के बारे में था।

— मास्टर

अगर यह उसके लिए काम करता तो शायद यह दूसरों के लिए काम करता। कुछ करने की आवश्यकता नहीं है जो वास्तव में उपयोगी है

— Mbotet

"ssh" चलाने से काम नहीं चल रहा है। यह विकल्पों के उपयोग के लिए दिखा रहा है: ssh [..] [..] [..] [उपयोगकर्ता @] hostname [कमांड]

— पी सतीश पात्रो