क्या यात्रा के दौरान होटलों से SSH द्वारा सर्वर से जुड़ना वास्तव में सुरक्षित है?

Question

क्या यात्रा के दौरान होटलों से SSH का उपयोग कर सर्वर से जुड़ना वास्तव में सुरक्षित है?

सर्वर :
- सेंटोस 7
- केवल आरएसए कुंजी द्वारा अधिकृत - पासवर्ड की स्थिति से इनकार किया जाता है
- गैर-मानक पोर्ट

कार्य केंद्र :
- Ubuntu 14
- उपयोगकर्ता पासवर्ड
- पासवर्ड आरएसए कुंजी (मानक विधि) का उपयोग करने के लिए

शायद एक यूएसबी स्टिक पर निजी आरएसए कुंजी के आधे हिस्से को रखना एक अच्छा विचार होगा , और स्वचालित रूप से (स्क्रिप्ट द्वारा) कनेक्ट करने से पहले यह आधा ~ / .ssh / private_key में जोड़ें?

इंटरनेट होटलों में WIFI या किराए के अपार्टमेंट में केबल के माध्यम से होगा।

UPD
पहली बार में अस्पष्ट होने के लिए क्षमा करें। मेरा मतलब यहां दो पहलुओं में सुरक्षा है:

1. एक अविश्वसनीय नेटवर्क के माध्यम से सिर्फ SSH कनेक्शन की सुरक्षा।
2. SSH कनेक्शन के लिए आवश्यक कुंजी के साथ एक कंप्यूटर की सुरक्षा - अगर यह चोरी हो जाती है, तो सर्वर की सुरक्षा कैसे करें ...

Comments

क्या आधा RSA- कुंजी? Ssh होस्ट कुंजी का सार्वजनिक हिस्सा? आपके उपयोगकर्ता ssh कुंजी के निजी भाग का आधा?

— औरोल

मेरे निजी आरएसए की कुंजी का आधा हिस्सा :) और स्वचालित रूप से सर्वर से कनेक्ट करने से पहले स्क्रिप्ट को इस आधे से ~ / .ssh / private_key में जोड़ने के लिए।

— सेर्गेई सेरोव

आप अधिकांश लोगों की तुलना में पहले से अधिक सुरक्षित हैं क्योंकि आप लिनक्स चला रहे हैं। चूंकि आप हाल के संस्करण चला रहे हैं, आपके पास ओपनएसएसएच के नए संस्करण होने चाहिए जो मजबूत क्रिप्टो का समर्थन करते हैं। Tecmint.com/5-best-practices-to-secure-and-protect-ssh-server का अनुसरण करने के बाद आप अपने आप को मजबूत क्रिप्टो करने के लिए सीमित कर सकते हैं जैसे कि stribika.github.io/2015/01/01/secure-secure- shell.html

— चूजों

@chicks "अधिकांश लोगों की तुलना में अधिक सुरक्षित है क्योंकि आप लिनक्स चला रहे हैं" कहने के लिए एक मूर्खतापूर्ण बात है। SSH SSH है, चाहे वह लिनक्स, यूनिक्स (मैक) या विंडोज पर चल रहा हो। और हम हाल के इतिहास में लिनक्स में बहुत गंभीर सुरक्षा खामियों की ओर इशारा कर सकते हैं (हार्दिक, कोई भी?)। बस कह रहे हैं, चलो मूर्ख ओएस लौ युद्धों को किनारे पर छोड़ दें जहां वे हैं क्योंकि यह वास्तविक सवालों और मुद्दों से विचलित करता है। धन्यवाद! ;-)

— क्रेग

@ मुझे लगता है कि मैं क्या बताने की कोशिश कर रहा था। सभी OS में सुरक्षा समस्याओं के बहुत सारे, और Microsoft ने कई साल पहले अपनी "भरोसेमंद कंप्यूटिंग * शुरू करने के बाद से काफी प्रगति की है। मुझे लगता है कि" आप अधिक सुरक्षित हैं क्योंकि लिनक्स "बात वास्तविक मुद्दे से बातचीत को बदल देती है ( सम्मानपूर्वक); ;-)

— क्रेग

Answer 1

तो, एक स्पष्ट रूप से अविश्वसनीय कनेक्शन पर एक ssh कनेक्शन बनाने के बारे में।

मान लें कि आपके पास पहले से ही एक ~ / .sh / ज्ञात_होस्ट्स है, जो पिछले कनेक्शन से है, हां, आपको इस बात की परवाह किए बिना कनेक्ट करना चाहिए कि नेटवर्क सुरक्षित है या नहीं। यदि आपके पास ssh होस्ट कुंजी को सत्यापित करने के कुछ अन्य साधन हैं तो वही जाता है।

यदि आपने पहले कभी सर्वर से कनेक्ट नहीं किया है, और न ही ssh होस्ट कुंजी को सत्यापित करने का कोई अन्य तरीका है, तो आप कनेक्ट करने के लिए उपयोग किए जाने वाले नेटवर्क के बारे में अधिक सावधान हो सकते हैं।

Comments

धन्यवाद!! तो एसएसएच द्वारा सर्वर से कनेक्ट करना सुरक्षित है, यहां तक ​​कि किसी भी सार्वजनिक वाई-फाई के माध्यम से भी?

— सेर्गेई सेरोव

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

— हेगन वॉन एटिजन

यह ध्यान देने योग्य है कि यदि क्लाइंट को होस्ट कुंजी का पता नहीं है, तो पासवर्ड प्रमाणीकरण का उपयोग करने पर पूर्ण MITM- हमला संभव होगा। लेकिन अगर कुंजी आधारित प्रमाणीकरण का उपयोग किया जाता है, तो हमलावर केवल सर्वर को प्रतिरूपण करने में सक्षम होगा। हमलावर वास्तविक सर्वर को प्रमाणित करने में भी सक्षम नहीं होगा। एक हमलावर के लिए उस मामले में सर्वर का एक ठोस प्रतिरूपण प्रदान करना मुश्किल होता है, इसलिए आप यह नोटिस करने में सक्षम हो सकते हैं कि बहुत देर होने से पहले कुछ गड़बड़ है। संक्षेप में: सार्वजनिक कुंजी प्रमाणीकरण पासवर्ड प्रमाणीकरण की तुलना में अधिक सुरक्षित है ।

— कैस्परल्ड

@kasperd: ठीक है, अगर कनेक्टिंग क्लाइंट में एजेंट फॉरवर्डिंग सक्षम है तो भी सार्वजनिक कुंजी प्रमाणीकरण पूर्ण MITM अनुभव प्रदान कर सकता है। लेकिन हाँ, सार्वजनिक कुंजी प्रमाणीकरण निश्चित रूप से नियमित पासवर्ड के लिए बेहतर है, किसी भी दिन।

— औरोल

@kasperd: ठीक है, मैं आसानी से किसी ऐसे व्यक्ति की खोज कर सकता हूं जो केवल एजेंट को अग्रेषित कर रहा है, लेकिन इसे पूरी तरह से नहीं समझ रहा है, उनके ~ / .ssh / config में "Host * \ n \ tForwardAgent हां" जैसी कोई चीज डाल रहा है। लोग सभी तरह के पागल काम करते हैं :-)

— औरोल

Answer 2

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

कृपया ध्यान दें कि इसे "पासफ़्रेज़" के साथ "एन्क्रिप्टेड" निजी कुंजी संग्रहीत करके (निजी कुंजी समस्या) आसानी से हल किया जा सकता है: उन्हें शुरू में एन्क्रिप्ट किया जा सकता है, जबकि ssh-keygen उपयोगिता के साथ उत्पन्न करते हुए , अंत में पासफ़्रेज़ प्रदान करके। पीढ़ी की प्रक्रिया या, यदि आपके पास पहले से ही विकल्प के साथ ssh-keygen उपयोगिता का उपयोग करते हुए, उन्हें अनियंत्रित किया गया -pहै। एक बार कुंजी एन्क्रिप्ट होने के बाद, हर लॉगिन पर आपको संबंधित पासफ़्रेज़ दर्ज करने के लिए कहा जाता है और .... यदि सही है, तो सब कुछ सामान्य रूप से आगे बढ़ेगा।

इसके अलावा, यदि आप ssh क्लाइंट को लॉन्च करते समय हर बार पासफ़्रेज़ में प्रवेश नहीं करना चाहते हैं, तो आप ssh-Agent का उपयोग कर सकते हैं : यह अनएन्क्रिप्टेड निजी कुंजियों का, स्मृति में, ट्रैक रख सकता है। आप बस एन्क्रिप्टेड कुंजी को पकड़े हुए फ़ाइल की ओर इशारा करते हुए ssh-add चला सकते हैं और, पासफ़्रेज़ के लिए पूछने के बाद, कुंजी को ssh-agent द्वारा प्रबंधित सेट में जोड़ा जाता है। बाद में, हर बार SSH क्लाइंट को पासफ़्रेज़-रक्षित कुंजी की आवश्यकता होती है, ssh-agent पारदर्शी रूप से ssh क्लाइंट को संबंधित अनएन्क्रिप्टेड निजी-कुंजी प्रदान करता है। तो, आपके लिए, इसे अंतःक्रियात्मक रूप से दर्ज करने की आवश्यकता नहीं है।

कृपया ध्यान दें कि ssh-agent बहुत सारी कुंजियों का प्रबंधन कर सकता है, और जाहिर है कि आप ssh-addलॉगिन / स्टार्टअप समय पर उपयोगिता को लॉन्च करने के लिए (कुंजियों के ssh- एजेंट सेट को पॉप्युलेट करने के लिए) अपने नोटबुक / डेस्कटॉप को "ट्यून" कर सकते हैं ।

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

उपरोक्त सभी, स्पष्ट रूप से, लागू नहीं होता है यदि आप अपने स्वयं के नोटबुक पर भरोसा नहीं करते हैं ।

---

पुनश्च: जैसा कि आपकी संभावना के लिए अलग-अलग माध्यमों पर अनएन्क्रिप्टेड निजी कुंजी के दो हिस्सों को संग्रहीत करने की संभावना है: मैं दृढ़ता से आपको सलाह देता हूं कि आप ऐसा न करें, क्योंकि एक अनएन्क्रिप्टेड रूप में संवेदनशील सामग्री के दो टुकड़ों को बनाए रखना, दो रखने की तुलना में बहुत बुरा है, बहुत बुरा है। पूरी सामग्री की पूरी प्रतियां, एन्क्रिप्टेड!

Answer 3

आपके प्रश्न का पहला भाग पिछली प्रतिक्रिया से पहले ही उत्तर दे चुका है। आपके दूसरे भाग के अनुसार, मैं pam_google_authenticator का उपयोग करके आपके ssh लॉगिन में एक दूसरा कारक जोड़ने की सलाह दूंगा। यह काफी आसान सेटअप है और किसी भी डिस्ट्रो पर कॉन्फ़िगर होता है। इस मामले में, जहाँ आप अपने चारों ओर निजी कुंजी ले जा रहे हैं, चोरी हो गई है, वे Google-प्रमाणक से आपके सर्वर को TOTP onetime पासवर्ड w / आउट नहीं कर सकते हैं।

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7