सवाल यदि मैं लिनक्स सर्वर पर रूट पासवर्ड बदलता हूं, तो क्या कोई रूट रूट उपयोगकर्ता के लिए एसएसएच अधिकृत_की बनाने पर रूट को एक्सेस कर सकता है?


मुझे यह भी यकीन नहीं है कि मैंने सही पूछा है। जब भी कोई रूट पासवर्ड बदलता है, तो वे बदलते हुए उल्लेख करते हैं /etc/passwd, या बस का उपयोग कर passwd आदेश, लेकिन मैंने कभी इसे अधिकृत_की फाइल में बदलने के बारे में कभी नहीं सुना है। मुझे यह कहां मिल सकता है, और मैं सुरक्षित रूप से किसी प्रविष्टि को कैसे हटा सकता हूं या बिना किसी नुकसान के रूट के लिए इसे कैसे बदल सकता हूं? धन्यवाद!


5


मूल


ध्यान दें कि आम तौर पर अनुशंसा की जाती है कि किसी को भी एसएसएच पर रूट के रूप में लॉग इन न करने दें, और यदि आप उस अभ्यास का पालन करते हैं, तो अधिकृत_की फ़ाइल को स्पर्श करने की आवश्यकता नहीं है। - David Z


जवाब:


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

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


16





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

लीवर के खातों को आसानी से अक्षम किया जा सकता है और आप गारंटी दे सकते हैं कि वे वापस नहीं आ सकते हैं (बेशक, उन्होंने कुछ बैक दरवाजे छोड़े हैं, जो कुछ भी है जिसके बारे में आप कुछ भी नहीं कर सकते हैं)।

हम उपयोगकर्ताओं, समूहों और एसएसएच कुंजी को स्टोर करने के लिए एक ldap निर्देशिका का उपयोग करते हैं, फिर समूह द्वारा "सूडो" पहुंच प्रतिबंधित करें।


5





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

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
..etc...
something-innocuous:0:42:foo:/:/bin/sh
..etc..

उस अतिरिक्त उपयोगकर्ता के पास एक अलग पासवर्ड होगा और जैसे ही उन्होंने लॉग इन किया है, प्रभावी ढंग से रूट हो।

रन visudo यदि आपके पास है sudo स्थापित, और वहां असामान्य कुछ भी जांचें।

आपको जांचना चाहिए /etc/pam.conf और सब कुछ /etc/pam.d (संभवतः कहीं और भी?) यह सुनिश्चित करने के लिए कि कुछ भी पासवर्ड रहित लॉगिन करने के लिए पीएएम को कॉन्फ़िगर नहीं कर रहा है root एक विशेष आईपी या इसी तरह से।

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

अंत में, यदि आपको अभी भी यह असंभव नहीं लगता है: किसी भी माउंट पॉइंट्स को खोजें जिनके माउंट विकल्पों में शामिल नहीं है nosuid setuid / setgid बाइनरी के लिए (कुछ का उपयोग कर find -perm /6000) या बाइनरी जो रूट हो सकती है, जो संशोधित हो सकती है। हाल ही में कौन से संशोधित / जोड़े गए हैं? उनमे से कोई भी। Timestamps बदलने के लिए तुच्छ हैं।

रूटकिट ने उपर्युक्त का कोई संयोजन किया हो सकता है, और शायद इसे पहचानने की क्षमता में बाधा डालने के लिए कर्नेल (शायद स्मृति में भी, रीबूट के बिना) को पैच किया हो सकता है (पीएस / नेटस्टैट इत्यादि से चीजों को हटाया जा सकता है)

सौभाग्य। :-)


3





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

एसएसएच पासवर्ड के बिना अनावश्यक है, लेकिन ये दोनों एक "या" की तरह हैं, इसलिए यदि आप या तो हैक कर सकते हैं, तो आप हैक कर रहे हैं।


2



रिमोट लॉग इन के लिए यह सही है। पासवर्ड बदलने के बारे में बिंदु अभी भी प्रासंगिक है, क्योंकि वे सिस्टम पासवर्ड हैं, प्रारंभिक रिमोट लॉगिन के बाद कहीं और इस्तेमाल किए जाते हैं। - Dan Carley


आप सेटिंग द्वारा एसएसएच के माध्यम से रूट लॉग इन अक्षम कर सकते हैं PermitRootLogin no आपकी sshd_config फ़ाइल में। यदि आपके पास सर्वर का आदान-प्रदान कर रहा है या रूट को रूट के रूप में दूरस्थ रूप से निष्पादित कर रहा है (उदा। कुछ सिस्टम बैकअप) तो शायद आप ऐसा नहीं करना चाहते हैं। यदि ऐसा है तो काइल क्रोनिन का जवाब जाने का रास्ता है।


1





रूट के लिए एसएसएच की अधिकृत कुंजी का उपयोग करने के बारे में बहुत मुश्किल सोचना उचित है।

मान लें कि मैं सिस्टम ZZ पर रूट हो सकता हूं और मैं रूट की अधिकृत_की में अपनी सार्वजनिक कुंजी जोड़ता हूं। अब, मेरी निजी कुंजी बहुत अधिक मूल्यवान है क्योंकि अब यह न केवल किसी को मेरे सभी खातों में तोड़ने देती है, बल्कि, यह ज़ेड ज़ेड पर भी रूट की अनुमति देती है। इसके अलावा, ज़ाहिर है, जेडजेड पर रूट करने की कोई भी प्रणाली स्वयं पर जड़ हो सकती है।

ध्यान दें कि अगर मैंने अपनी निजी कुंजी को उस सिस्टम पर रखा है जो दूसरों को रूट कर सकता है, तो वे उपयोगकर्ता ZZ पर रूट भी प्राप्त कर सकते हैं क्योंकि वे मेरी निजी कुंजी को आसानी से प्राप्त कर सकते हैं।

आदि

आदि

आदि

यह सुरक्षा का एक बहुत ही खतरनाक आराम है। लोगों को अपनी निजी कुंजी कहां से थोड़ा सा मुक्त होना पड़ता है क्योंकि यह एसएसएच को इतना आसान बनाता है।

मैं सूडो के साथ कोई रूट एसएसएच के साथ सहमत नहीं हूं, लेकिन, यदि आप ऐसा करते हैं, तो हो सकता है कि आप उन विशेष उपयोगकर्ताओं को जोड़ना चाहें जिनके पास एनआईएस / एलडीएपी / एनएफएस / आदि नेटवर्क निर्भरता नहीं है ताकि आप नेटवर्क फ़्यूबर होने पर अभी भी लॉग इन कर सकें। आम तौर पर रूट लॉग इन कर सकता है जब अन्य रूट नहीं कर सकते क्योंकि रूट इन बाहरी आवश्यकताओं में से कम है।


0