क्या क्लाउड सर्वर पर पासवर्ड रहित `sudo` सेट करना ठीक है?

Question

मुझे कुंजियों के माध्यम से सर्वर तक पहुंचने के विचार से प्यार है, ताकि मुझे हर बार अपने पासवर्ड sshको एक बॉक्स में टाइप न करना पड़े , मैं अपने उपयोगकर्ता ( rootपासवर्ड) को भी लॉक नहीं करता ( passwd -l usernameइसलिए) कुंजी के बिना लॉग इन करना असंभव है।

लेकिन यह सब टूट जाता है अगर मुझे sudoकमांड के लिए पासवर्ड दर्ज करने की आवश्यकता होती है । इसलिए मैं पासवर्डलेस लॉगिन के अनुरूप चीजों को बनाने के लिए पासवर्ड रहितsudo सेट करने का लालच देता हूँ ।

हालाँकि, मुझे यह महसूस होता रहता है कि यह कुछ अप्रत्याशित तरीके से मेरे पीछे हो सकता है, यह किसी तरह असुरक्षित लगता है। क्या ऐसे सेट अप के साथ कोई चेतावनी है? क्या आप किसी सर्वर पर उपयोगकर्ता खाते के लिए ऐसा करने की अनुशंसा / अनुशंसा नहीं करेंगे?

स्पष्टीकरण

1. मैं sudoयहां एक इंटरैक्टिव उपयोगकर्ता सत्र के उपयोग के बारे में बात कर रहा हूं , सेवाओं या प्रशासनिक लिपियों के लिए नहीं
2. मैं क्लाउड सर्वर का उपयोग करने के बारे में बात कर रहा हूं (इसलिए मेरे पास मशीन के लिए कोई भौतिक स्थानीय पहुंच नहीं है और केवल दूरस्थ रूप से लॉग इन कर सकते हैं)
3. मुझे पता है कि sudoएक समयबाह्य है जिसके दौरान मुझे अपना पासवर्ड पुनः दर्ज करने की आवश्यकता नहीं है। लेकिन मेरा कॉन्सर्ट वास्तव में एक पासवर्ड में शारीरिक रूप से टाइप करने के लिए अतिरिक्त समय बर्बाद करने के बारे में नहीं है। हालांकि मेरा विचार पासवर्ड से निपटने का नहीं था, क्योंकि मेरा मानना ​​है कि:
   • अगर मुझे इसे बिल्कुल याद रखना है, तो इसके सुरक्षित या पुन: उपयोग की संभावना बहुत कम है
   • यदि मैं अपने दूरस्थ खाते के लिए एक लंबा और अनूठा पासवर्ड उत्पन्न करता हूं, तो मुझे इसे कहीं (स्थानीय पासवर्ड प्रबंधक कार्यक्रम या क्लाउड सेवा) स्टोर करना होगा और हर बार इसका उपयोग करना होगा sudo। मुझे उम्मीद थी कि मैं इससे बच सकता हूं।

इसलिए इस सवाल के साथ मैं दूसरों पर एक संभव कॉन्फ़िगरेशन के जोखिम, कैवेट और ट्रेडऑफ़ को बेहतर ढंग से समझना चाहता था।

1 का पालन करें

सभी उत्तरों का कहना है कि पासवर्ड-रहित sudoअसुरक्षित है क्योंकि यह विशेषाधिकार को "आसान" बनाने की अनुमति देता है यदि मेरे व्यक्तिगत उपयोगकर्ता खाते से समझौता हो जाता है। मैं समझता हूँ कि। लेकिन दूसरी तरफ, अगर मैं पासवर्ड का उपयोग करता हूं, तो हम पासवर्ड के साथ सभी क्लासिक जोखिमों (बहुत कम या सामान्य स्ट्रिंग, विभिन्न सेवाओं के दौरान दोहराए गए आदि) को उकसाते हैं। लेकिन मुझे लगता है कि अगर मैं पासवर्ड प्रमाणीकरण को अक्षम कर देता हूं /etc/ssh/sshd_configताकि आपके पास अभी भी लॉग इन करने के लिए एक कुंजी होनी चाहिए, तो मैं एक सरल पासवर्ड का उपयोग कर सकता हूं sudoजिसके लिए टाइप करना आसान है? क्या यह एक मान्य रणनीति है?

अनुगमन २

अगर मेरे पास rootssh के माध्यम से लॉग इन करने की कुंजी भी है , अगर किसी को मेरे कंप्यूटर तक पहुंच मिलती है और वह मेरी चाबियाँ चुराता है (वे अभी भी OS 'केरिंग पासवर्ड द्वारा सुरक्षित हैं!), तो वे rootखाते तक सीधी पहुँच प्राप्त कर सकते हैं । , sudoरास्ते को दरकिनार कर दिया । rootतब खाते तक पहुंचने के लिए क्या नीति होनी चाहिए ?

Comments

इसकी बिल्कुल भी सिफारिश नहीं करेंगे, क्योंकि अक्सर उपयोगकर्ता के रूप में एक शेल प्राप्त करने के तरीके होते हैं (चूंकि सभी सेवाएं सुरक्षा उल्लंघन के अधीन हैं, लेकिन वे आमतौर पर सिस्टम के पूर्ण उपयोग से बचने के लिए उपयोगकर्ता के रूप में चलते हैं), लेकिन लॉगिन करने के लिए पासवर्ड के रूप में रूट अनधिकृत लोगों को रूट एक्सेस प्राप्त करने से रोकता है। यदि कोई नहीं है, तो सोचें कि जो कोई भी किसी भी तरह से आपके उपयोगकर्ता खाते तक पहुंच पाता है, उसके पास सर्वर तक पूरी पहुंच है। पासवर्ड सेट करना अधिक नहीं हो सकता है, लेकिन यह मदद करता है।

— पन्नोव

कृपया मेरे अनुवर्ती प्रश्न देखें

— दिमित्री पश्केविच

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

— स्नेकडॉक

@SnakeDoc धन्यवाद, यह एक तरह का उत्तर है जिसकी मुझे उम्मीद थी। एक विस्तृत जवाब लिखने के लिए देखभाल? मुझे जानकर खुशी हुई!

— दिमित्री पश्केविच

@EEAA यह वास्तव में लिनक्स में काफी आसान है। केवल वही खाते जिन्हें सुडो में पासवर्ड रहित होने की अनुमति दी जानी चाहिए, वे सिस्टम खाते होंगे जिन्हें कोई लॉग इन नहीं कर सकता है और इसलिए उस खाते को उन्नत नहीं कर सकता है और आपके विरुद्ध उन अनुमतियों का उपयोग कर सकता है। खाते के लिए एक बोगस शेल सेट करें /etc/passwdजैसे कि नोलिन, कोई पासवर्ड सेट न करें, और उसके बाद विडियो में पासवर्ड रहित सेट करें। यदि आप ऐसा करते हैं, तो आपको यह भी निश्चित करना चाहिए कि विस्कोस सेटिंग केवल उस सिस्टम खाते के लिए है जिसकी आवश्यकता है, यानी इसे केवल उसी कमांड पर लॉक करें, जिसे इसे कभी भी चलाना चाहिए।

— स्नेकडॉक

Answer 1

मुझे कुंजियों के माध्यम से सर्वर तक पहुँचने के विचार से प्यार है, ताकि मुझे हर बार अपने पासवर्ड को एक बॉक्स में टाइप करने की जरूरत न पड़े, मैं अपने उपयोगकर्ता (रूट नहीं) पासवर्ड (पासव्लड-यूज़रनेम) को भी लॉक कर देता हूँ, इसलिए यह असंभव है एक कुंजी के बिना लॉग इन करें ... क्या आप किसी सर्वर पर उपयोगकर्ता खाते के लिए ऐसा करने की अनुशंसा / अनुशंसा नहीं करेंगे?

आप पासवर्ड-आधारित लॉगिन को गलत तरीके से अक्षम करने के बारे में जा रहे हैं। उपयोगकर्ता के खाते को लॉक करने के बजाय, PasswordAuthentication noअपने में सेट करें /etc/ssh/sshd_config।

उस सेट के साथ, ssh के लिए पासवर्ड प्रमाणीकरण अक्षम है, लेकिन आप अभी भी sudo के लिए पासवर्ड का उपयोग कर सकते हैं।

केवल समय मैं निर्धारित करने की अनुशंसा NOPASSWDsudo में सेवा खाते है, जहां प्रक्रियाओं प्रोग्राम के रूप में sudo के माध्यम से कमांड चलाने के लिए सक्षम होने की जरूरत है के लिए है। उन परिस्थितियों में, सुनिश्चित करें कि आप स्पष्ट रूप से केवल उन विशिष्ट आदेशों को श्वेत सूची में शामिल कर सकते हैं जिन्हें खाते को चलाने की आवश्यकता है। इंटरेक्टिव खातों के लिए, आपको हमेशा सक्षम पासवर्ड छोड़ना चाहिए।

आपके अनुवर्ती प्रश्नों के उत्तर:

लेकिन मुझे लगता है कि अगर मैं पासवर्ड प्रमाणीकरण को / etc / ssh / sshd_config में अक्षम करता हूं, ताकि आपके पास अभी भी लॉग इन करने के लिए एक कुंजी होनी चाहिए, तो मैं सिडो के लिए एक सरल पासवर्ड का उपयोग कर सकता हूं जो टाइप करने में आसान है? क्या यह एक मान्य रणनीति है?

हाँ, यह सही है। मैं अभी भी अपेक्षाकृत मजबूत स्थानीय खाता पासवर्ड का उपयोग करने की सलाह देता हूं, लेकिन हास्यास्पद रूप से मजबूत नहीं। ~ 8 वर्ण, बेतरतीब ढंग से उत्पन्न पर्याप्त है।

अगर मेरे पास ssh के माध्यम से रूट के रूप में लॉग इन करने के लिए एक कुंजी है, अगर किसी को मेरे कंप्यूटर तक पहुंच मिलती है और मेरी चाबियाँ चोरी हो जाती हैं (वे अभी भी ओएस के कीरिंग पासवर्ड द्वारा संरक्षित हैं!), लेकिन वे सीधे पहुंच भी सकते हैं। रूट खाता, sudo पथ को दरकिनार।

Ssh के माध्यम से रूट एक्सेस को अक्षम किया जाना चाहिए। अवधि। PermitRootLogin noअपने में सेट sshd_config।

फिर रूट खाते तक पहुंचने के लिए क्या नीति होनी चाहिए?

आपके पास हमेशा अपने सर्वर के कंसोल के लिए आउट-ऑफ-बैंड एक्सेस प्राप्त करने का एक साधन होना चाहिए। कई VPS विक्रेता इसे प्रदान करते हैं, जैसे कि समर्पित हार्डवेयर के विक्रेता करते हैं। यदि आपका प्रदाता वास्तविक कंसोल एक्सेस (उदाहरण के लिए, EC2) को अनुदान नहीं देता है, तो आप आमतौर पर इस उत्तर में एक प्रक्रिया का उपयोग करके एक्सेस को पुनर्स्थापित कर सकते हैं जैसे कि मैं इस उत्तर को रेखांकित करता हूं ।

Comments

+1 पासवर्ड छोड़ना चाहिए ...

— क्रिस एस

+1 sudo पासवर्ड वास्तव में secutiry (जहां तक ​​मैं देख सकता हूं) के लिए नहीं है, लेकिन एक बेवकूफ चेक के रूप में। वहाँ नहीं होने से अनकहा कहर हो सकता है।

— बोरिस द स्पाइडर

यदि आप अपनी चाबी ढीली करते हैं, तो आप कर रहे हैं, जब तक कि आपके पास एक पिछले दरवाजे नहीं है, लेकिन फिर एक हमलावर करता है। खोई हुई चाबी को ठीक करने का एकमात्र तरीका, ठीक से शारीरिक रूप से वास्तविक टर्मिनल पर बैठना होगा। यदि आपको सुरक्षा ssh कुंजी प्रदान करने की आवश्यकता है, तो आपको नुकसानों के बारे में पता होना चाहिए, और बस ... बस अपनी चाबियाँ ढीली न करें।

— स्नेकडॉक

आपके अंतिम पैराग्राफ के बारे में एक टिप्पणी, और किसी भी VPS के लिए सामान्य रूप से पहुंच खो देने के बारे में ... कुछ VPS प्रोवाइडर वास्तव में आपकी मदद करेंगे यदि आप लॉक आउट कर चुके हैं। मैंने अपने वीएम को सिंगल यूजर मोड में बूट कर दिया था और जब मैंने खुद को लॉक किया तो मेरे लिए कुछ चीजें कीं (ऐसा होता है ... खराब फ़ायरवॉल नियम योग्य)। आपके होस्ट के आधार पर, वे आपसे सेवा के लिए शुल्क ले सकते हैं; , सब के बाद, आप के लिए विशेष ध्यान समर्पित कर रहे हैं। इसके अलावा, कुछ एक छोटी सी कीमत के लिए या कभी-कभी मुफ्त में बैकअप / स्नैपशॉट करेंगे, जो इस लायक हो सकता है यदि आप एक बड़े, संभवतः विघटनकारी परिवर्तन के बारे में हैं।

— स्नेकॉक

@DmitryPashkevich - PasswordAuthenticationसभी उपयोगकर्ताओं को प्रभावित करने के संबंध में , आप Matchकुछ उपयोगकर्ताओं या समूहों के लिए इसे वापस चालू करने के लिए हमेशा sshd_config में अनुभागों का उपयोग कर सकते हैं ।

— मैट थॉमसन

Answer 2

मैं आमतौर पर NOPASSWORDएक स्वचालित प्रक्रिया द्वारा चलाए जाने वाले आदेशों के उपयोग को प्रतिबंधित करता हूं । इन आदेशों के लिए एक सेवा खाता रखना बेहतर है और आवश्यक आदेशों के लिए sudo के उपयोग को प्रतिबंधित करना है।

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

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

Answer 3

मैं केवल दो परिस्थितियों में इसका उपयोग करूंगा:

• जब यह एक स्वचालित स्क्रिप्ट के लिए बिल्कुल आवश्यक है जो एक विशिष्ट उपयोगकर्ता के रूप में चल रहा है
• विशिष्ट व्यवस्थापक कार्यों के लिए (केवल व्यवस्थापक कार्यों को पढ़ें, न कि सिस्टम को बदलने के लिए कार्रवाई करने वाले) और फिर केवल विशिष्ट उपयोगकर्ताओं के लिए

डिफ़ॉल्ट रूप से अधिकांश sudoकॉन्फ़िगरेशन आपको उसी सत्र में थोड़ी देर के लिए फिर से नहीं पूछेगा (यदि आप एक नया शेल खोलते हैं जिसका कोई प्रभाव नहीं है)। आप timestamp_timeoutसेटिंग के साथ इस व्यवहार को एक हद तक नियंत्रित कर सकते हैं ।

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

अनुवर्ती 2 के बारे में:

अगर मेरे पास ssh के माध्यम से रूट के रूप में लॉग इन करने की कुंजी है

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

Comments

मेरी अनुवर्ती # 2 को संबोधित करने के लिए धन्यवाद। मैं अभी भी उलझन में हूँ: मैं rootसीधे रूप में लॉगिंग से बचने की कोशिश करता हूं लेकिन मुझे खाते तक पहुंचने के लिए किसी तरह की आवश्यकता नहीं है, है ना? तो फिर मैं इसे कैसे करूँ? पासवर्ड के साथ, ssh कुंजी नहीं? लेकिन चाबियाँ पासवर्ड से बेहतर नहीं हैं?

— दिमित्री पश्केविच

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

— डेविड स्पिललेट

Answer 4

आपके पास दोनों दुनिया के लिए सबसे अच्छा हो सकता है: एसएसएच प्रमाणीकरण दोनों लॉगिन और सुडो के लिए। यदि आप pam_ssh_agent_auth मॉड्यूल को एकीकृत करते हैं तो आप sudo होने पर पासवर्ड दिए बिना प्रमाणित करने के लिए SSH कुंजियों का उपयोग कर सकते हैं।

मैं पांच साल से अधिक समय से उत्पादन में इसका उपयोग कर रहा हूं।

इसे कॉन्फ़िगर करने के लिए, PAM मॉड्यूल स्थापित करें, और उसके बाद /etc/pam.d/sudoया अपने सिस्टम के समतुल्य के लिए एक पंक्ति जोड़ें :

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

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

आप उसी एसएसएच कुंजी का उपयोग कर सकते हैं जैसा कि आप लॉगिन करने के लिए करते हैं, या आप एक अलग कुंजी सेट कर सकते हैं जिसे आप केवल अपने एजेंट में जोड़ते हैं जब आप सूडो करते हैं। इसलिए यदि आप अतिरिक्त सावधानी बरतना चाहते हैं, तो आप एक अलग अधिकृत_की फाइल रख सकते हैं जिसमें एक अलग SSH कुंजी है जिसे आप केवल तब अपने एजेंट में जोड़ते हैं जब आपको sudo की आवश्यकता होती है:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Comments

वाह, यह बहुत अच्छा लग रहा है! तो क्या मैं sudoकमांड निष्पादित करने के लिए एक अलग कुंजी उत्पन्न करता हूं या मैं उसी का उपयोग करता हूं जिसका उपयोग एसएसएच प्रमाणीकरण के लिए किया गया था?

— दिमित्री पश्केविच

ये अद्भुत है। अगर मैं कर सकता तो मैं आपको कई बार अपवोट करता।

— nyuszika7h

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

— अश्लील टिप्पणी करना

Answer 5

चूंकि आपने पूछा था, इस sudoमुद्दे को संबोधित करने के तरीके के बारे में मेरी सामान्य सलाह है ।

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

एक ठीक से सेटअप सूडो ALL=(ALL) ALLसेटिंग का उपयोग नहीं करेगा , बल्कि कुछ और जो कि विशेष रूप से उपयोगकर्ता की जरूरत है, तक सीमित है। उदाहरण के लिए, यदि आपको एक उपयोगकर्ता को एक अटक सेवा को लॉगिन करने और पुनः आरंभ करने में सक्षम होने की आवश्यकता है, तो उन्हें नए सॉफ़्टवेयर को स्थापित करने या अपने सर्वर को बंद करने, फ़ायरवॉल नियमों को बदलने आदि की क्षमता की आवश्यकता नहीं है।

कभी-कभी लोगों के लिए स्वयं को रूट खाते में बढ़ाने के लिए सुडो का उपयोग करना आम है, अर्थात। sudo su -। एक बार जब वे ऐसा करते हैं, तो आप यह देखना बंद कर देते हैं कि रूट खाते से कौन क्या कर रहा है (रूट को कई बार समवर्ती रूप से लॉग इन किया जा सकता है)। इसलिए कभी-कभी लोग sudo su -कमांड को भी निष्क्रिय करना चाहते हैं । लेकिन, व्यावहारिक कारणों से, यदि आपको प्रशासन के लिए पूरी तरह से मूल-विशेषाधिकार वाले खाते की आवश्यकता है, तो कम से कम किसी को यह sudo su -आदेश जारी करने की आवश्यकता होगी कि कौन रूट को ऊपर उठाए और कब।

मैं अपने बक्से को कैसे सुरक्षित करूं:

SSH पोर्ट को डिफ़ॉल्ट के अलावा किसी अन्य चीज़ में बदलें। यह उन डंबल-बॉट्स से बचने के लिए है जो पोर्ट नंबरों की तलाश करते हैं, जब तक कि वे अंदर नहीं जाते (तब तक नहीं)।

SSH पर रूट लॉगिन AllowRootLogin noको अपने sshd_config में सेटिंग का उपयोग करके हटा दें। यह आपके रूट खाते में किसी को जानवर से जबरदस्ती रोकने से रोकता है। यह आम तौर पर अच्छा अभ्यास है कि किसी को सीधे ऑडिट कारणों के साथ-साथ सुरक्षा के लिए रूट / व्यवस्थापक खाते में लॉग इन करने की अनुमति न दें। यदि आप सीधे रूट लॉगिन की अनुमति देते हैं, तो आप नहीं जानते कि कौन लॉग इन किया है, उन्हें पासवर्ड किस से मिला है, आदि, लेकिन, अगर कोई जिमी के खाते में लॉग इन करता है, तो अपनी अनुमतियों को रूट में बढ़ा देता है, आपके पास एक बेहतर विचार है कि आप कहां से शुरू करें ऑडिट खोज (और रीसेट करने के लिए कौन खाता है)।

केवल उपयोगकर्ताओं को ही SSH की आवश्यकता होती है जो AllowUsersसेटिंग और अन्वेषण का उपयोग करते हैं, यह निर्दिष्ट करते हैं कि किन खातों को SSH की आवश्यकता है। यह डिफ़ॉल्ट रूप से, SSH के अन्य सभी खातों को ब्लॉक कर देगा।

सुडोर्स को विडियो के माध्यम से संपादित करें और केवल उन कमांड को अनुमति दें जिनकी उपयोगकर्ता को आवश्यकता है। यह कैसे करना है, इसके बारे में गहराई से गाइड में बहुत सारे हैं, इसलिए मैं यहां विस्तार नहीं करूंगा। यहाँ एक स्टार्टर है: http://ubuntuforums.org/showthread.php?t=1132821

इसका सार यह है कि एक समझौता किए गए खाते को अपनी मशीन को खतरे में डालने से रोकना है। अर्थात। यदि सैली का खाता टूट गया, और सैली केवल वेब सर्वर को पुनरारंभ करने के लिए sudo का उपयोग कर सकती है, तो हमलावर को अपने वेब सर्वर को लूप में पुनः आरंभ करने में मज़ा आ सकता है, लेकिन कम से कम वे rm -rf /your/webserver/directoryआपके सभी फ़ायरवॉल पोर्ट्स को खोल या खोल नहीं सकते , आदि।

अच्छा फ़ायरवॉल नियम सेट करें जो केवल आपके बॉक्स के संचालन के लिए आवश्यक पोर्ट की अनुमति देता है। आम तौर पर आप सब कुछ छोड़ना चाहते हैं और केवल स्पष्ट रूप से अनुमति देते हैं कि आपको क्या चाहिए। बहुत सारे सभ्य iptables और अन्य फ़ायरवॉल ऑनलाइन शुरू होते हैं, यहाँ एक मैं उपयोग करता हूँ (यह एक मूल स्टार्टर है):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

इसके अलावा एक मजबूत पासवर्ड कुंजी है।यहां तक ​​कि अगर आप अपने रिमोट एक्सेस के लिए एसएसएच कुंजी का उपयोग करते हैं, तो भी आपको सूडो उपयोग के लिए पासवर्ड की आवश्यकता होगी। यह एक ऐसा मामला है जहां सूडो कुछ और सुरक्षा मुहैया करा सकते थे। यदि कोई आपकी ssh कीज़ को चुराने के लिए आता है, तब भी उन्हें आपके बॉक्स पर कुछ भी महत्वपूर्ण करने से रोका जाएगा यदि उन्हें अभी भी sudo का उपयोग करने के लिए आपके खाते के पासवर्ड को बाध्य करना है। पासवर्ड एक शब्द नहीं होना चाहिए, बल्कि एक पास वाक्यांश होना चाहिए। एक वाक्य के बारे में सोचो, और उस का उपयोग करें। यह आम तौर पर आपको 8 वर्णों से अधिक लंबा कुछ मिलेगा, जो बहुत सारे एन्ट्रापी प्रदान करता है, लेकिन कुछ यादृच्छिक पासवर्ड की तुलना में याद रखना भी आसान है। बेशक, अच्छा पासवर्ड प्रथा जॉन रिपर जैसे उपकरणों को बेवकूफ बनाने के लिए एक मशीन-जनित यादृच्छिक पासवर्ड का उपयोग करने के लिए कहती है, जो अधिकांश पासफ़्रेज़ और पासवर्ड के माध्यम से सही चीर देगा। नहीं, ई को 3 के साथ बदलने से काम नहीं होता है, जॉन को उन क्रमोन्नति के साथ भी मिलता है।

Comments

एक व्यापक उत्तर के लिए धन्यवाद! मुझे निश्चित रूप से अपने बक्से को सुरक्षित करने के लिए इन सभी सलाह का उपयोग करने की आवश्यकता है। मैं अभी भी EEAA के उत्तर को स्वीकार करूंगा, क्योंकि यह थोड़ा और विशिष्ट है जो मैं पूछ रहा था।

— दिमित्री पश्केविच

@DmitryPashkevich यह ठीक है, EEAA का एक अच्छा और उचित जवाब है। आपने मुझे अपनी टिप्पणी विस्तार से देने के लिए कहा, इसलिए मैंने किया। कोई चिंता नहीं है

— स्नेकडॉक

के रूप में sudo su -और बदलाव के लिए, sudoreplayकाम में आ सकता है।

— nyuszika7h

Answer 6

कुछ मामलों में ऐसा करना आवश्यक है। उदाहरण के लिए कुछ हाइपरविजर एपीआई के पासवर्ड रहित लॉगिन और पासवर्ड रहित sudo। लेकिन आप अभी भी बिना ब्रेक लिए उसे प्रतिबंधित कर सकते हैं।

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

इसके अलावा यदि आप बहुत से विशेषाधिकार प्राप्त कमांडों में टाइप कर रहे हैं और हर समय suया तो आप उन लोगों के सामने सूडो नहीं डालना चाहते sudo -sहैं जो रूट शेल प्राप्त कर सकते हैं । आप अपना पासवर्ड एक बार दर्ज करेंगे और फिर वह है।

Answer 7

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

टाइपिंग मेक 'मेक' और स्क्रिप्ट बेस बेस को प्रदर्शित या प्रदर्शित किए बिना 'सुडो मेक इनस्टॉल' पार्ट के लिए कर रही है, और स्क्रिप्ट पहले स्थान पर इतनी ब्रिंडेड हो रही है कि आप सुनिश्चित नहीं हैं कि वे / usr / लोकल के बारे में जानते हों। और इसलिए आप संशोधनों के लिए जाँच / usr शुरू करें ...

मैंने कभी भी NOPASSWD का उपयोग नहीं करने की कसम खाई और उस टाइमआउट सेटिंग को 0 में बदल दिया।

Answer 8

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

से sudoers आदमी पेज :

timestamp_timeout

सूडो से पहले बीतने वाले मिनटों की संख्या फिर से एक पासवार्ड मांगेगी। टाइमआउट में एक भिन्नात्मक घटक शामिल हो सकता है यदि मिनट ग्रैन्युलैरिटी अपर्याप्त है, उदाहरण के लिए 2.5। डिफ़ॉल्ट है 5. पासवर्ड के लिए हमेशा संकेत देने के लिए इसे 0 पर सेट करें। यदि 0 से कम मान पर सेट किया जाता है तो उपयोगकर्ता की समय सीमा कभी समाप्त नहीं होगी। इसका उपयोग उपयोगकर्ताओं को क्रमशः "sudo -v" और "sudo -k" के माध्यम से अपने स्वयं के समय टिकटों को बनाने या हटाने की अनुमति देने के लिए किया जा सकता है।

इस ब्लॉग पोस्ट कुछ उदाहरण से पता चलता का उपयोग कर visudoइस तरह के रूप मिनट, में समय समाप्ति सेट करने के लिए:

Defaults timestamp_timeout=60

हो सकता है कि यह सुरक्षा और आसानी से उपयोग के बीच एक खुशहाल मैदान हो?

Comments

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

— दिमित्री पश्केविच

Answer 9

यहां अन्य उत्तर महान हैं, और अधिकांश महत्वपूर्ण बिंदुओं पर स्पर्श करते हैं। एक चीज जो मैंने नहीं देखी है वह यह तथ्य है कि किसी भी प्रकार का प्रमाणीकरण जब आप अपने आप में लॉग इन करते हैं तो एक दूरस्थ हमलावर द्वारा कब्जा किया जा सकता है जिसने पहले से ही आपके खाते में एक पैर जमाने की स्थापना की है। वे कीगलर स्थापित करने के लिए आपकी शेल लॉगिन फ़ाइलों या PATH को संशोधित कर सकते हैं ताकि आप जो कुछ भी टाइप करें, जिसमें आपका sudo पासवर्ड भी शामिल है, उन्हें भेजा जाए। वे आपके पासवर्ड को इकट्ठा करने के लिए आपके PATH में एक हैक किए गए sudo बाइनरी को जोड़ सकते हैं। वे ssh एजेंट कनेक्शन को अपने कनेक्टिंग मशीन पर वापस जा सकते हैं ताकि pam_ssh_agent_auth को हरा सकें और कनेक्ट होते ही खुद जड़ हो जाएं। इसलिए पूर्ण सुरक्षा के संदर्भ में, मुझे sudo के पासवर्ड का उपयोग करने और नहीं करने के बीच कोई अंतर नहीं दिखता है। बेशक, यह इसे और अधिक जटिल हमला बनाता है,

संक्षेप में, मेरा मानना ​​है कि अगर आप सूडो एक्सेस को खुद से दूर करना चाहते हैं, या कभी भी इसका उपयोग नहीं करते हैं तो एक समझौता किए गए उपयोगकर्ता खाते को जड़ बनने से रोकने का एकमात्र तरीका है। यदि आप असहमत हैं, तो मुझे बताएं, क्योंकि मैं गलत होना पसंद करूंगा!