SSH: होस्ट <होस्ट> की प्रामाणिकता स्थापित नहीं की जा सकती

Question

इस संदेश का क्या मतलब है? क्या यह एक संभावित समस्या है? क्या चैनल सुरक्षित नहीं है?

या यह केवल एक डिफ़ॉल्ट संदेश है जो हमेशा एक नए सर्वर से कनेक्ट करते समय प्रदर्शित होता है?

मैं पिछले दिनों SSH का उपयोग करते समय इस संदेश को देखने के लिए उपयोग किया जाता हूं: मैंने हमेशा अपने पासवर्ड को सामान्य तरीके से लॉगिन किया, और मुझे इसके बारे में ठीक लगा क्योंकि मैं निजी / सार्वजनिक कुंजी का उपयोग नहीं कर रहा था (जो कि अधिक सुरक्षित है एक छोटा पासवर्ड)। लेकिन इस बार मैंने बिटबकैट के संबंध के लिए ssh के साथ एक सार्वजनिक कुंजी स्थापित की है लेकिन मुझे अभी भी संदेश मिला है। मुझे पता है कि निजी कुंजी के डिक्रिप्शन के लिए अंत में पासफ़्रेज़ प्रॉम्प्ट एक अलग, पूरक सुरक्षा उपाय है।

मुझे उम्मीद है कि कोई व्यक्ति इस "प्रामाणिकता को स्थापित नहीं किया जा सकता" संदेश के लिए एक अच्छा स्पष्टीकरण दे सकता है।

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

Comments

यह वास्तव में उन लोगों में से एक है "इसका मतलब है कि यह क्या कहता है" संदेश। इसका मतलब यह sshबताने का कोई तरीका नहीं है कि आप वास्तव में बात कर रहे हैं bitbucket.org। यदि आपने इसे जानने के लिए किसी तरह से कॉन्फ़िगर किया है, तो यह काम नहीं कर रहा है। यदि आपने नहीं किया, तो यह आपको बता रहा है कि आपने नहीं किया।

— डेविड श्वार्ट्ज

Answer 1

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

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

किसी भी तरह से, आपके पास किसी को सुरक्षित एन्क्रिप्टेड चैनल है । फिंगरप्रिंट के संगत निजी कुंजी के बिना कोई भी 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40आपके द्वारा भेजे गए को डिकोड नहीं कर सकता है।

अपने आप को प्रमाणित करने के लिए आपके द्वारा उपयोग की जाने वाली कुंजी असंबंधित है ... आप एक धोखाधड़ी करने वाले सर्वर को प्रमाणीकरण जानकारी नहीं भेजना चाहेंगे, जो इसे चुरा सकता है, और इसलिए आपको इस बात पर निर्भर नहीं करना चाहिए कि आप पासफ़्रेज़ का उपयोग करने जा रहे हैं या नहीं लॉगिन करने के लिए निजी कुंजी। आप अभी तक इस प्रक्रिया में अभी तक नहीं मिले हैं।

Comments

इसलिए, अगर कोई दुर्भावनापूर्ण तृतीय पक्ष है, और मैं संदेश को खारिज करता हूं, तो मैं जो भी करने जा रहा हूं, वह उसे मेरी सार्वजनिक कुंजी भेज रहा है, और वह अभी भी मेरे डेटा को डिक्रिप्ट नहीं कर पाएगा? इसलिए अब मेरे डेटा से छेड़छाड़ करने के एकमात्र तरीके हैं यदि (1) मेरी निजी कुंजी के साथ छेड़छाड़ की जाती है या (2) बिटबकेट के सर्वरों से छेड़छाड़ की जाती है या (3) मेरे बिटबकेट खाते से छेड़छाड़ की जाती है। जब तक वे लॉगिन प्रयासों को सीमित कर देते हैं (जो मुझे आश्चर्य होगा कि अगर वे ऐसा नहीं करते हैं) तो क्या वास्तव में इस बिंदु पर पागल होने के कई कारण नहीं हैं, एह?

— स्टीवन लू

@ उत्तर: आप उसे अपनी सार्वजनिक कुंजी नहीं भेज रहे हैं, वह पहले से ही है। आप जो कर रहे हैं वह एक चुनौती को प्रमाणित करने के लिए आपकी निजी कुंजी का उपयोग कर रहा है ... यदि वह वास्तविक bitbucket.org से जुड़ा है , तो आप होने का दावा करते हुए, वास्तविक चुनौती प्राप्त करते हैं, और उस चुनौती का उपयोग करते समय जब आप को चुनौती देते हैं, तो वह आपको मूर्ख बना सकता है। उसे एक वैध प्रतिक्रिया भेजना जो वह तब वास्तविक bitbucket.org पर आपके खाते तक पहुंच प्राप्त करने के लिए उपयोग करता है। उसके पास अभी भी आपकी निजी कुंजी नहीं है, इसलिए वह भविष्य के समय, या किसी अन्य संसाधन पर लॉग इन नहीं कर सकता है जो कुंजी को अनलॉक करता है, लेकिन उसके पास एक लॉगिन सत्र है।

— बेन वोइगट

जब मैंने कहा था कि मेरे जवाब में मेरा मतलब है "आप किसी नकली सर्वर पर प्रमाणीकरण जानकारी नहीं भेजना चाहेंगे"।

— बेन वोइगट

"यदि आप पागल हैं, तो वैकल्पिक चैनल का उपयोग करके कुंजी की चेकसम / फ़िंगरप्रिंट सत्यापित करें।" पागल के लिए (और रिकार्ड के लिए), GitHub के फिंगरप्रिंट पर है help.github.com/articles/generating-ssh-keys और bitbucket के में बताया गया है confluence.atlassian.com/display/BITBUCKET/...

— सुन्दर

@BenVoigt हाँ, मैं समझता हूँ कि, वास्तव में विरोधाभास उन पृष्ठों के लिए एक अलग असंबंधित नेटवर्क के माध्यम से मिलेगा, या शायद जीथुब मुख्यालय के लिए उड़ान भरने और व्यक्ति में फिंगरप्रिंट प्राप्त करेंगे :)

— sundar

Answer 2

हम कहते हैं कि आप कुछ व्यावसायिक रहस्यों का आदान-प्रदान करने के लिए किसी से मिलते हैं। आपका सलाहकार आपको बताता है कि आप उस व्यक्ति से पहले कभी नहीं मिले हैं, और यह एक नपुंसक हो सकता है। इसके अलावा, उसके साथ अगली बैठकों के लिए, आपका सलाहकार अब आपको चेतावनी नहीं देने वाला है। यही संदेश का मतलब है। व्यक्ति रिमोट सर्वर है, और आपका सलाहकार ssh क्लाइंट है।

मुझे नहीं लगता कि उसके साथ रहस्य साझा करने से पहले व्यक्ति की पहचान को फिर से जांचना दोगुना है। उदाहरण के लिए, आप उसकी तस्वीर के साथ एक वेब पेज खोल सकते हैं और आपके सामने वाले चेहरे से उसकी तुलना कर सकते हैं। या उसके पहचान पत्र की जांच करें।

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

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

यदि चेहरे मेल खाते हैं, तो आप फ़ाइल में कुंजी जोड़ सकते हैं जैसे ~/.ssh/known_hosts(कई लिनक्स वितरण में मानक स्थान):

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

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

Comments

यह उत्तर बहुत उपयोगी है

— ०१०११०१०१०१

यह स्वीकृत उत्तर होना चाहिए: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts धन्यवाद इवान!

— रॉड

@Rod: आप एक कमांड के आधार पर स्वीकार किए गए उत्तर को चुनेंगे जो दोनों पूरी तरह से अनावश्यक है (आप known_hostsमूल चेतावनी के अनुसार "हां" लिखकर संशोधित कर सकते हैं , जैसा कि पहले ही प्रश्न में दिखाया गया है) और खतरनाक (आपके द्वारा जोड़ी गई कुंजी) फ़ाइल जरूरी नहीं कि वही देखी जाए, जो आपने दो बार प्राप्त की है!)।

— बेन वोइगट

@BenVoigt यह समाधान जो प्रदान करता है कि टाइपिंग "हां" नहीं है, यह समाधान पूरी तरह से स्क्रिप्ट योग्य है। मुझे लगता है कि ज्यादातर लोग यह पता लगा सकते हैं कि "(हां / नहीं)" का जवाब कैसे दिया जाए? प्रेरित करना। मैं इस प्रश्नोत्तर के दौरान यह पता लगाने की कोशिश कर रहा था कि मानव हस्तक्षेप (सर्वर सेट-अप स्क्रिप्ट के लिए) के बिना इस समस्या को कैसे हल किया जाए। मेरी उत्तेजना में मुझे लगता है कि मैंने ध्यान नहीं दिया कि ओपी का सवाल मेरी तुलना में थोड़ा अलग है, लेकिन IMO यह अभी भी धागे में सबसे उपयोगी / गैर-स्पष्ट उत्तर है।

— रॉड

@ रोड: नहीं, यह उपयोगी नहीं है। अपनी सुरक्षा को कम करना बुरा है। अपनी सुरक्षा को कम करने के तेज़ तरीके खोजना उपयोगी के ठीक विपरीत है।

— बेन वोइगट

Answer 3

मुझे बस known_hostsटेक्स्ट फाइल बनानी थी~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

ऐसा करने के बाद, इसने मेजबान को जोड़ा और मैंने फिर कभी संदेश नहीं देखा।

Comments

मुझे नहीं लगता कि वास्तव में कुछ भी बदलता है। चेतावनी तब दिखाई जाती है जब सर्वर स्वयं बदल गया हो। उदाहरण के लिए यदि आप एक नई वर्चुअल मशीन का प्रावधान करते हैं जिसे आप पहली बार कनेक्ट कर रहे हैं। आपके पास कोई known_hostsफ़ाइल है या नहीं (सही अनुमतियों के साथ) यह आपको नए सर्वर की प्रामाणिकता के बारे में पूछने से नहीं रोकती है ... जब तक कि आप किसी तरह पहले से ही इस सर्वर के लिए पब कुंजी हस्ताक्षर प्राप्त कर लें और इसे अपने में डाल दें known_hosts। जो चेक को छोड़ने का एक सामान्य तरीका है (हालाँकि चेक को "हाँ" कहना अक्सर प्राप्त करने के लिए अधिक तेज़ होता है)

— स्टीवन लू

धन्यवाद। मुझे पता था कि_हॉट्स है, लेकिन चेतावनी प्राप्त करता रहा। मुझे बस चेतावनियों को रोकने के लिए know_hosts पर अनुमतियां बदलनी थीं।

— 13

कृपया ऐसा न करें। एक गंभीर सुरक्षा खतरा हो सकता है। आपकी होस्ट फ़ाइल केवल आपके द्वारा लिखित होनी चाहिए। दूसरा कमांड मूल रूप से आपके कंप्यूटर में सर्वर आइडेंटिटी को खराब करने की अनुमति देता है।

— स्टोलज़

"चेतावनी तब दिखाई जाती है जब सर्वर स्वयं बदल गया हो।" या जब सर्वर से पहले कभी नहीं गया है।

— रॉड

Answer 4

एक और आसान तरीका है कि बस /root/.ssh के तहत "कॉन्फिगर" फाइल को टच करें और पैरामीटर जोड़ें प्रामाणिकता की पुष्टि के लिए

Comments

यह अनुशंसित नहीं है। यह आसान है लेकिन स्थिति से निपटने का सही तरीका नहीं है।

— विकास

Answer 5

यह संदेश सिर्फ SSH आपको बता रहा है कि उसने इस विशेष होस्ट कुंजी को पहले कभी नहीं देखा है, इसलिए यह वास्तव में यह सत्यापित करने में सक्षम नहीं है कि आप जिस होस्ट से आप सोचते हैं, उससे जुड़ रहे हैं। जब आप "हां" कहते हैं, तो यह ssh कुंजी को आपकी ज्ञात_होस्ट फ़ाइल में डाल देता है, और फिर बाद के कनेक्शनों में यह ज्ञात से होस्ट की एक से ज्ञात_होल्स फ़ाइल की तुलना करेगा।

स्टैक ओवरफ्लो पर संबंधित लेख दिखा रहा था कि इस चेतावनी को कैसे निष्क्रिय किया जाए, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established ।

Comments

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

— रोरी अलसोप

Answer 6

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

Comments

मुझे आश्चर्य है कि अगर ssh एजेंट फॉरवर्डिंग का उपयोग करते हुए चेतावनी को भी दबा सकते हैं यदि होस्ट A को B के बारे में पता है लेकिन X नहीं करता है, लेकिन एजेंट अग्रेषण A और X के बीच होता है। अधिकांश वातावरण (जो प्रदान करते हैं ssh) और टर्मिनल ऐप एजेंट को अग्रेषित करने में सहायता करते हैं, इससे मदद मिलती है ssh कीज़ की संख्या में कटौती करने के लिए आपको केवल अपने एंड-डिवाइसेस को मैनेज करना होगा।

— स्टीवन लू

Answer 7

मेरे मामले में पासवर्ड कम लॉगिन मेरे होम निर्देशिका अनुमतियों के कारण काम नहीं कर रहा था क्योंकि मैंने डिफ़ॉल्ट सेटिंग्स बदल दी थीं। अंत में, यहाँ है जो मेरे लिए काम किया है। मेरे घर निर्देशिका अनुमतियाँ हैं

/ घर / उपयोगकर्ता नाम

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys