सवाल क्लाउड सर्वर पर पासवर्ड रहित 'सुडो' सेट करना ठीक है?


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

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

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

स्पष्टीकरण

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

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

1 का पालन करें

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

2 का पालन करें

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


56
2018-03-09 21:40


मूल


इसकी बिल्कुल अनुशंसा नहीं करेंगे, क्योंकि उपयोगकर्ता के रूप में खोल पाने के कई तरीके होते हैं (क्योंकि सभी सेवाएं सुरक्षा उल्लंघन के अधीन होती हैं, लेकिन वे आमतौर पर सिस्टम तक पूर्ण पहुंच से बचने के लिए उपयोगकर्ता के रूप में चलती हैं), लेकिन लॉगिन करने के लिए पासवर्ड रखना रूट अनधिकृत लोगों को रूट पहुंच प्राप्त करने से रोकता है। यदि कोई नहीं है, तो सोचता है कि जो कोई भी आपके उपयोगकर्ता खाते तक किसी भी तरह से पहुंच प्राप्त करता है, उसके पास सर्वर तक पूर्ण पहुंच है। पासवर्ड सेट करना ज्यादा नहीं हो सकता है, लेकिन यह मदद करता है। - piernov
कृपया मेरे अनुवर्ती प्रश्न देखें - Dmitry Pashkevich
सूडो कभी पासवर्ड रहित नहीं होना चाहिए। रूट को एसएसएच के माध्यम से रिमोट लॉगिन से अक्षम किया जाना चाहिए, एसएसएच पोर्ट डिफ़ॉल्ट नहीं होना चाहिए (गूंगा-बॉट को कुचलने के लिए), और किसी भी खाते को सूडो की आवश्यकता होनी चाहिए, जो कि उन्हें जो कुछ भी चाहिए, उसके लिए केवल न्यूनतम न्यूनतम सूडो शक्तियों तक ही सीमित होनी चाहिए (सेवा को पुनरारंभ करें केवल, आदि), और बहुत मजबूत पासवर्ड भी हैं। - SnakeDoc
@SnakeDoc धन्यवाद, यह एक तरह का उत्तर है जिसे मैं उम्मीद कर रहा था। एक विस्तृत उत्तर लिखने की देखभाल? मुझे सीखने में खुशी है! - Dmitry Pashkevich
@EEAA यह वास्तव में लिनक्स में काफी आसान है। सूडो में केवल एक ही खाते को पासवर्ड रहित होने की अनुमति दी जानी चाहिए, वह सिस्टम अकाउंट होगा जो कोई लॉग इन नहीं कर सकता है और इसलिए उस खाते में नहीं जा सकता है और आपके खिलाफ उन अनुमतियों का उपयोग नहीं कर सकता है। खाते के लिए एक फर्जी खोल सेट करें /etc/passwd जैसे कि नोलिन, कोई पासवर्ड सेट नहीं करें, और फिर विसुडो में पासवर्ड रहित सेट करें। यदि आप ऐसा करते हैं, तो आपको यह भी सुनिश्चित करना चाहिए कि विज़ुडो सेटिंग केवल उस सिस्टम खाते की आवश्यकता है, यानी इसे केवल उसी आदेश पर लॉक करें जो इसे कभी भी चलाना चाहिए। - SnakeDoc


जवाब:


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

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

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

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

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

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

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

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

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

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

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


46
2018-03-09 21:48



+1 चाहिए पासवर्ड छोड़ दो ... - Chris S
+1 सूडो पासवर्ड नहीं है वास्तव में वहाँ सुरक्षा के लिए (जहां तक ​​मैं देख सकता हूं) लेकिन बेवकूफ जांच के रूप में अधिक। वहां अनगिनत हावोक का कारण नहीं हो सकता है। - Boris the Spider
यदि आप अपनी कुंजी खो देते हैं, तो आप तब तक कर चुके हैं जब तक कि आपके पास कोई पिछवाड़े न हो, लेकिन फिर हमलावर भी होता है। अगर सही तरीके से खोए गए कुंजी को ठीक करने का एकमात्र तरीका शारीरिक रूप से वास्तविक टर्मिनल पर बैठना होगा। यदि आपको एसएसबी कुंजी प्रदान करने की सुरक्षा की आवश्यकता है, तो आपको नुकसान के बारे में पता होना चाहिए, और बस ... बस अपनी चाबियाँ ढीली न करें। - SnakeDoc
आपके पिछले पैराग्राफ की ओर एक टिप्पणी, और किसी भी वीपीएस के लिए सामान्य रूप से पहुंच खोने के संबंध में ... कुछ वीपीएस प्रदाता वास्तव में आपकी मदद करेंगे यदि आप लॉक हो जाते हैं। मैंने अपने वीएम को एकल उपयोगकर्ता मोड में बूट किया है और जब मैंने खुद को बंद कर दिया है तो यह मेरे लिए कुछ चीजें करता है (ऐसा होता है ... खराब फ़ायरवॉल नियम लॉल)। आपके मेजबान के आधार पर, वे आपको सेवा के लिए चार्ज कर सकते हैं; वे हैं , आखिरकार, आप पर विशेष ध्यान समर्पित करना। इसके अलावा, कुछ छोटे मूल्य या कभी-कभी मुफ्त में बैकअप / स्नैपशॉट करेंगे, जो कि यदि आप बड़े, संभावित रूप से विघटनकारी परिवर्तन करने वाले हैं, तो इसके लायक हो सकते हैं। - SnakeDoc
@DmitryPashkevich - संबंधित PasswordAuthentication सभी उपयोगकर्ताओं को प्रभावित करना, आप हमेशा उपयोग कर सकते हैं Match कुछ उपयोगकर्ताओं या समूहों के लिए इसे वापस चालू करने के लिए sshd_config में सेक्शन। - Matt Thomason


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

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

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


10
2018-03-10 00:18





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

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

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

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

फॉलो-अप 2 के बारे में:

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

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


8
2018-03-10 09:47



मेरे अनुवर्ती # 2 को संबोधित करने के लिए धन्यवाद। मैं अभी भी उलझन में हूं: मैं लॉग इन करने से बचने की कोशिश करता हूं root सीधे लेकिन मुझे खाते तक पहुंचने के लिए कुछ रास्ता चाहिए, है ना? तो मैं इसे कैसे करूँ? पासवर्ड के साथ, एसएसएच कुंजी नहीं? लेकिन पासवर्ड से पासवर्ड बेहतर नहीं हैं? - Dmitry Pashkevich
आप हमेशा रूट के रूप में स्थानीय रूप से लॉगिन कर सकते हैं, लेकिन यह अनुशंसा की जाती है कि रिमोट होस्ट (एसएसएच या इसी तरह के माध्यम से) से रूट करने के लिए सीधे लॉग इन पूरी तरह अक्षम हो जाएं। यदि आपके पास ऐसा खाता है जो सूडो (कोर्स के पासवर्ड के साथ) के माध्यम से रूट बन सकता है तो आप खाते में सभी पहुंच कभी नहीं खो देते हैं। - David Spillett


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

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

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

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

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

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

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

7
2018-03-12 12:34



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


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

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

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

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

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

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

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

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

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

इसका एक समझौता एक समझौता खाते को आपकी मशीन को खतरे में डालने से रोकने के लिए है। अर्थात। यदि सैली का खाता टूट जाता है, और सैली वेब सर्वर को पुनरारंभ करने के लिए केवल सूडो का उपयोग कर सकती है, तो हमलावर को आपके वेब सर्वर को लूप में पुनरारंभ करना मजेदार हो सकता है, लेकिन कम से कम वे नहीं कर सकते 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

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


5
2018-03-10 19:54



एक व्यापक उत्तर के लिए धन्यवाद! मुझे अपने बक्से को सुरक्षित करने के लिए इन सभी सलाहयों का उपयोग करने की ज़रूरत है। मैं अभी भी ईईएए के जवाब को स्वीकार करूंगा हालांकि यह पूछने के लिए थोड़ा और विशिष्ट है। - Dmitry Pashkevich
@DmitryPashkevich यह ठीक है, ईईएए का एक अच्छा और उपयुक्त जवाब है। आपने मुझे ऊपर मेरी टिप्पणी का विवरण देने के लिए कहा, इसलिए मैंने किया। कोई चिंता नहीं :) - SnakeDoc
से संबंधित sudo su - और विविधताएं, sudoreplay काम में आ सकता है। - nyuszika7h


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

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

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


3
2018-03-10 03:18





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

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

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


2
2017-10-17 00:05





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

वहाँ से sudoers मैन पेज:

timestamp_timeout

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

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

Defaults timestamp_timeout=60

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


1
2017-09-05 03:52



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