SSH के लिए सार्वजनिक कुंजी प्रमाणीकरण सेट करने के बाद क्या मुझे उपयोगकर्ताओं के पासवर्ड को हटा देना चाहिए?

Question

SSH के लिए सार्वजनिक कुंजी का उपयोग करना सबसे अच्छा है। तो मेरे sshd_configपास है PasswordAuthentication no।

कुछ उपयोगकर्ता कभी लॉग-इन नहीं करते हैं, उदाहरण के लिए शेल के साथ एक sftp उपयोगकर्ता /usr/sbin/nologin। या एक सिस्टम अकाउंट।

इसलिए मैं ऐसे यूजर को बिना पासवर्ड के बना सकता हूं adduser gary --shell /usr/sbin/nologin --disabled-password।

क्या यह एक अच्छा / बुरा विचार है? क्या मेरे विचार में ऐसे कोई प्रभाव नहीं हैं?

Comments

इसलिए जब तक ये वास्तविक उपयोगकर्ताओं के खाते नहीं हैं, या उन्हें sudoएक्सेस के लिए अपने पासवर्ड की आवश्यकता नहीं है (या तो sudo अनुमति नहीं होने के कारण, या sudo अनुमति होने के साथ NOPASSWD), आपके द्वारा चयनित उत्तर उपयुक्त होना चाहिए। मैंने सूडो चिंता को शामिल करने के लिए उस उत्तर पर एक संपादन प्रस्तुत किया है, लेकिन मुझे लगा कि इस बीच मैं आपको यहां बुलाऊंगा।

— डॉकटोर जे।

Answer 1

यदि आपके पास सर्वर तक रूट एक्सेस है और अपने उपयोगकर्ताओं के लिए ssh कुंजियों को पुनर्जीवित कर सकते हैं, यदि वे उन्हें खो देते हैं

तथा

आपको यकीन है कि एक उपयोगकर्ता (एक व्यक्ति के रूप में) के पास कई उपयोगकर्ता खाते नहीं होंगे और उन्हें SSH सत्र में उन लोगों के बीच स्विच करने की आवश्यकता होती है (ठीक है, वे जरूरत पड़ने पर कई SSH सत्र खोल सकते हैं )

तथा

उन्हें "भौतिक" (कीबोर्ड + मॉनिटर के माध्यम से या वीएम के लिए रिमोट कंसोल के माध्यम से) सर्वर तक पहुंच की आवश्यकता नहीं होगी

तथा

किसी भी उपयोगकर्ता के पास पासवर्ड-गेटेड sudoएक्सेस नहीं है (यानी या तो उसके पास सूडो एक्सेस नहीं है, या उसके पास sudo एक्सेस है NOPASSWD)

मुझे लगता है कि आप अच्छे होंगे।

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

Comments

मैं यह भी जोड़ता हूं कि "आप जानते हैं कि उपयोगकर्ताओं को कभी भी दूरस्थ सिस्टम से सिस्टम का उपयोग नहीं करना पड़ेगा जिसमें उनकी निजी SSH कुंजी का अभाव है"। और "आप उन उपयोगकर्ताओं से निपटने के लिए तैयार हैं जो ऐसी स्थिति में भाग लेते हैं जिसके बारे में आपने नहीं सोचा था।"

— एंड्रयू हेनले

पहली शर्त है आईएमओ आवश्यक नहीं है। आपके उपयोगकर्ताओं को अपनी कुंजियाँ स्वयं बनानी चाहिए। आप बस उनकी सार्वजनिक कुंजी को अधिकृत करते हैं क्योंकि वे उन्हें आपको देते हैं। यदि वे एक कुंजी को ढीला करते हैं, तो वे बस एक और उत्पन्न करेंगे और आप सर्वर पर पुराने को बदल देंगे।

— क्रिस्टोफ ड्रेवेट-ड्रोगेट

@AndrewHenle यह एक अच्छा बिंदु है, हालांकि अगर sshd है PasswordAuthentication noतो यह एक अलग समस्या है (उपयोगकर्ता वैसे भी लॉग इन करने में सक्षम नहीं होगा)।

— lonix

"नेवर" इतना लंबा समय है। जरूरत पड़ने पर एडमिन आसानी से पासवर्ड ऑथेंटिकेशन को वापस जोड़ सकता है।

— हाइड

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

— क्रिश्चियन गाव्रोन

Answer 2

यह प्रश्न मूल रूप से उल्लिखित है passwd --delete <username> जो असुरक्षित है : इसके साथ, एन्क्रिप्टेड पासवर्ड फ़ील्ड /etc/shadowपूरी तरह से खाली हो जाएगा।

username::...

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

---

adduser --disabled-passwdएक /etc/shadowप्रविष्टि का उत्पादन करेगा जहां एन्क्रिप्टेड पासवर्ड फ़ील्ड सिर्फ एक तारांकन है, अर्थात

username:*:...

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

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

यदि आपको इस राज्य में एक मौजूदा खाता सेट करने की आवश्यकता है, तो आप इस आदेश का उपयोग कर सकते हैं:

echo 'username:*' | chpasswd -e

---

एन्क्रिप्टेड पासवर्ड फ़ील्ड के लिए एक तीसरा विशेष मूल्य है: adduser --disabled-loginफिर फ़ील्ड में केवल एक विस्मयादिबोधक चिह्न होगा।

username:!:...

तारांकन की तरह, यह पासवर्ड प्रमाणीकरण को सफल करना असंभव बनाता है, लेकिन इसका एक अतिरिक्त अर्थ भी है: यह पासवर्ड को कुछ प्रशासन उपकरणों के लिए "लॉक" के रूप में चिह्नित करता है। passwd -lमौजूदा पासवर्ड हैश को विस्मयादिबोधक चिह्न के साथ जोड़कर बहुत अधिक प्रभाव होता है, जो फिर से पासवर्ड प्रमाणीकरण का उपयोग करना असंभव बनाता है।

लेकिन यहाँ बेखबर के लिए एक जाल है: वर्ष 2008 में, passwdपुराने shadowपैकेज से आने वाले कमांड के संस्करण को passwd -l"लॉकिंग अकाउंट" से केवल "पासवर्ड लॉक करना" में फिर से परिभाषित करने के लिए बदल दिया गया था । बताया गया कारण "अन्य पासवार्ड संस्करण के साथ संगतता के लिए" है।

यदि आपने (मेरे जैसा) बहुत पहले यह जान लिया, तो यह एक आश्चर्यजनक आश्चर्य के रूप में आ सकता है। यह उन मामलों में मदद नहीं करता है जो adduser(8)स्पष्ट रूप से अभी तक इस भेद के बारे में नहीं जानते हैं।

प्रमाणीकरण के सभी तरीकों के लिए खाते को निष्क्रिय करने वाला हिस्सा वास्तव में खाते के लिए 1 की समाप्ति तिथि मान सेट कर रहा है usermod --expiredate 1 <username>:। वर्ष 2008 से पहले, passwd -lयह shadowस्रोत किट से उत्पन्न होता है जो पासवर्ड को एक विस्मयादिबोधक चिह्न के साथ उपसर्ग करने के अलावा करता था - लेकिन अब ऐसा नहीं करता है।

डेबियन पैकेज चैंजोग कहते हैं:

• debian / पैच / 494_passwd_lock-no_account_lock: passwd -l के पिछले व्यवहार को पुनर्स्थापित करें (जो # 389183 में बदल गया): केवल उपयोगकर्ता के पासवर्ड को लॉक करें, उपयोगकर्ता के खाते को नहीं। मतभेदों को भी स्पष्ट रूप से प्रलेखित करें। यह पासवार्ड के पिछले संस्करणों और अन्य कार्यान्वयन के साथ एक व्यवहार को सामान्य बनाता है। बंद: # 492307

डेबियन बग 492307 और बग 389183 के लिए बग इतिहास इसके पीछे की सोच को समझने में मददगार हो सकता है।

Comments

चेतावनी के लिए धन्यवाद ... मैं प्रश्न को संपादित करने वाला हूं इसलिए कोई भी गलती नहीं करता है!

— lonix

क्या आपकी चेतावनी उस मामले पर भी लागू होती है जहां मैं उपयोग करता हूं adduser --disabled-passwd- इसलिए यदि कोई अन्य सेवा पासवर्ड प्रमाणीकरण की अनुमति देती है, तो उपयोगकर्ता पासवर्ड के बिना लॉगिन कर सकता है?

— lonix

नहीं, adduser --disabled-passwordविशेष रूप से पासवर्ड प्रमाणीकरण को उस खाते के लिए सफल होना असंभव बनाता है।

— टेल्कोएम

क्योंकि पासवर्ड हटाना इतना निर्दोष लगता है, लेकिन इतना खतरनाक है कि मैं इसके बारे में पैराग्राफ के साथ इसके बारे में पैराग्राफ को स्विच करने का सुझाव देता हूं *ताकि यह उन लोगों के बारे में पढ़ा जाए जो पहले पढ़ा जा सके।

— कप्तान मैन

वाह, यह एक बुरा आश्चर्य है कि ऐसा होने की प्रतीक्षा कर रहा है ... और हमेशा की तरह, इसके लिए दोष देने के लिए स्पष्ट रूप से एक संगतता मुद्दा है। यह passwd2008 में स्रोत कोड में दिखाई दिया । क्या आपको यह पसंद नहीं है, जब आपने कुछ सीखा है और फिर किसी और पर निर्भर हो तो ऐसा नहीं है?

— टेल्कम