OpenSSH इमरजेंसी फिक्स: Alpine Linux लॉगिन बाईपास की व्याख्या, एक व्यावहारिक उदाहरण के साथ

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

आज 6 नवंबर, 2026 है, और यह मामला अभी इसलिए महत्वपूर्ण है क्योंकि Portable OpenSSH 10.6p2 केवल कल ही, 5 नवंबर को प्रोजेक्ट से एक तत्काल अनुरोध के साथ जारी किया गया था। यदि आप पासवर्ड प्रमाणीकरण चालू रखकर musl-आधारित Linux सर्वर चलाते हैं, तो डेवलपर्स चाहते हैं कि जब तक आप कार्रवाई न कर लें, तब तक तुरंत पासवर्ड लॉगिन अक्षम कर दें या SSH को तुरंत अक्षम कर दें।

कई टीमें उस हेडलाइन को पढ़कर या तो घबरा जाएँगी या इसे नज़रअंदाज़ कर देंगी। दोनों ही गलतियाँ हैं। अधिकांश Linux सर्वर प्रभावित नहीं हैं, लेकिन जो सर्वर प्रभावित हैं, उनमें वे भी शामिल हो सकते हैं जिन्हें आपने हमेशा "केवल-की" (key-only) कहा है। यह गाइड इस बग को सरल भाषा में समझाती है, दिखाती है कि किसी सर्वर की ठीक से जाँच कैसे करें, और समस्या का पता लगाने से लेकर सत्यापित फिक्स तक के पूरे उदाहरण का मार्गदर्शन करती है।

सरल शब्दों में, क्या हुआ

SSH वह टूल है जिसका उपयोग एडमिनिस्ट्रेटर सर्वर पर रिमोटली लॉगिन करने के लिए करते हैं। OpenSSH इसका सबसे व्यापक रूप से इस्तेमाल किया जाने वाला वर्शन है।

प्रत्येक Linux प्रोग्राम एक C लाइब्रेरी पर निर्भर करता है, जो बुनियादी फ़ंक्शंस का एक साझा संग्रह है। अधिकांश Linux सिस्टम glibc नामक लाइब्रेरी का उपयोग करते हैं। Alpine Linux musl नामक एक छोटी लाइब्रेरी का उपयोग करता है, जो एक बड़ा कारण है कि कंटेनरों और छोटे क्लाउड सर्वरों के लिए Alpine इतना लोकप्रिय क्यों है।

यह बग सॉफ़्टवेयर के उन दो घटकों के मिलन बिंदु पर मौजूद है। OpenSSH के डेवलपर्स का मानना है कि इसका मूल कारण OpenSSH के बाहर है, लेकिन वे यह भी स्वीकार करते हैं कि SSH सर्वर इसका फायदा उठाने का मार्ग और इसे ब्लॉक करने का एक व्यावहारिक स्थान प्रदान करता है। इसलिए 10.6p2 एक वर्कअराउंड जोड़ता है। इस खामी का पता वेकफील्ड के ओजग्युन कुल्तेकिन (Özgün Kültekin) ने लगाया था।

एक एरर कैसे सफल लॉगिन में बदल जाती है

यहाँ बिना किसी एक्सप्लॉइट विवरण के, चरण-दर-चरण तर्क दिया गया है।

जब कोई सर्वर बिना PAM (लॉगिन प्रबंधित करने का एक सामान्य सिस्टम - Pluggable Authentication Modules) के पासवर्ड की जाँच करता है, तो वह एक सीधा काम करता है। वह विज़िटर द्वारा टाइप किए गए पासवर्ड को हैश करता है, फिर परिणाम की तुलना उस अकाउंट के लिए संग्रहीत मान से करता है।

एक हैश को सॉल्ट (salt) की आवश्यकता होती है, जो एक छोटा यादृच्छिक मान होता है जिसे मिलाया जाता है ताकि एक समान पासवर्ड भी अलग परिणाम दें। यदि किसी अकाउंट के लिए संग्रहीत मान इतना छोटा है कि वह सॉल्ट नहीं दे सकता, तो OpenSSH उसी मशीन के किसी अन्य अकाउंट से सॉल्ट उधार ले सकता है। वह ऐसा एक अच्छे कारण से करता है: 2016 से उसने हमलावरों को यह अनुमान लगाने से रोकने की कोशिश की है कि कौन से यूज़रनेम मौजूद हैं, जो खामी CVE-2016-6210 की प्रतिक्रिया थी।

अब टकराव। जब musl के crypt() फ़ंक्शन को ऐसा पासवर्ड दिया जाता है जो कुछ हैश प्रकारों के लिए बहुत लंबा है, तो यह इनकार कर देता है और केवल एक वर्ण * लौटाकर एरर का संकेत देता है।

लेकिन * वह मान भी है जिसे कई सिस्टम ऐसे अकाउंट के पासवर्ड फ़ील्ड में संग्रहीत करते हैं जिसका कोई पासवर्ड होना ही नहीं चाहिए।

इसलिए सर्वर दो मानों की तुलना करता है:

• इसने क्या गणना की: *, जिसका वास्तव में अर्थ "error" है।
• इसके पास क्या संग्रहीत है: *, जिसका वास्तव में अर्थ "no usable password" है।

वे मेल खा जाते हैं। लॉगिन सफल हो जाता है।

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

शोधकर्ता इस परस्पर क्रिया (interaction) को 2012 के musl परिवर्तनों और 2016 के OpenSSH परिवर्तन से जोड़ते हैं। उन्होंने AI एजेंटों की मदद से विभिन्न बिल्ड और लॉगिन संयोजनों में लगभग 17,600 परीक्षण लॉगिन के माध्यम से इसका पता लगाने की बात कही है।

क्या आप प्रभावित हैं? चार स्थितियाँ

Alpine एडवाइज़री में चार स्थितियों की सूची दी गई है, और वे सभी महत्वपूर्ण हैं:

1. OpenSSH बिना PAM के पासवर्ड की जाँच करता है।
2. PasswordAuthentication सक्षम है।
3. टारगेट अकाउंट के पासवर्ड फ़ील्ड में मौजूद है: *.
4. किसी अन्य स्थानीय अकाउंट का पासवर्ड हैश शुरू होता है $5$ या $6$.

Alpine का मानक openssh-server पैकेज PAM का उपयोग नहीं करता। यहाँ तक कि openssh-server-pam इंस्टॉल करने से भी यह हल नहीं होता, क्योंकि आप तब भी जोखिम में हैं यदि UsePAM no सेट है।

ये बताए गए दायरे से बाहर हैं:

• गैर-Linux प्लेटफ़ॉर्म।
• glibc का उपयोग करने वाले Linux सिस्टम।
• PAM के ज़रिए पासवर्ड जाँचने वाले Linux सिस्टम।
• बिना किसी चालू SSH सर्वर वाले कंटेनर।
• पासवर्ड प्रमाणीकरण अक्षम वाले सिस्टम।
• ऐसे अकाउंट जिन्हें ! से लॉक किया गया है, न कि *.

यही अंतिम समूह कारण है कि "हम Alpine का उपयोग करते हैं" का अर्थ "हम असुरक्षित हैं" नहीं होता। अधिकांश Alpine कंटेनर कोई भी SSH सर्वर नहीं चलाते हैं। इसी तरह, "OpenSSH इंस्टॉल है" कहने से बहुत कम जानकारी मिलती है। आपको C लाइब्रेरी, पैकेज, चालू कॉन्फ़िगरेशन और अकाउंट डेटा को जानने की आवश्यकता है।

खतरनाक स्थिति: आधिकारिक क्लाउड इमेज

Alpine विशेष रूप से एक परिदृश्य की ओर इशारा करता है। इसके आधिकारिक tiny-cloud इमेज, वर्शन 3.18.11 से 3.24.3 तक, में एक alpine अकाउंट शामिल है जिसमें * पासवर्ड फ़ील्ड और पासवर्ड-रहित doas अधिकार हैं। doas एक छोटा टूल है, जो sudoके समान है, और यह किसी यूज़र को root के रूप में कमांड चलाने की अनुमति देता है।

वे इमेज शुरुआत में सुरक्षित होती हैं, क्योंकि चौथी स्थिति गायब होती है। मशीन पर कोई योग्य (qualifying) पासवर्ड हैश मौजूद नहीं होता है।

फिर कोई सामान्य पासवर्ड वाला यूज़र जोड़ता है, शायद कंसोल एक्सेस के लिए। वह अकेला सामान्य बदलाव शर्तों के इस सेट को पूरा कर सकता है। कोई हमलावर alpine के रूप में प्रवेश कर सकता है और root बन सकता है।

डिफ़ॉल्ट PermitRootLogin prohibit-password सेटिंग यहाँ कोई मदद नहीं करती है। यह root पर सीधे पासवर्ड लॉगिन को रोकती है, लेकिन यह मार्ग अप्रत्यक्ष रूप से root तक पहुँच जाता है।

एक व्यावहारिक उदाहरण: Acme का जंप होस्ट

आइए एक काल्पनिक कंपनी का उदाहरण लेते हैं। Acme एक छोटा Alpine सर्वर चलाती है, bastion.example.com, जिसके माध्यम से कर्मचारी आंतरिक सिस्टम तक पहुँचने के लिए कनेक्ट होते हैं। हर कोई कहता है कि यह केवल-की (key-only) है। एक नए इंजीनियर, रोहित, से इसे साबित करने के लिए कहा गया है।

चरण 1: प्लेटफ़ॉर्म की पुष्टि करें

रोहित लॉगिन करता है और सिस्टम की जाँच करता है:

cat /etc/alpine-release
ldd --version
apk info -e openssh-server openssh-server-pam

पहली कमांड Alpine वर्शन दिखाती है। दूसरी musl का नाम बताती है। तीसरी सूची देती है कि दोनों में से कौन-से पैकेज इंस्टॉल हैं। Acme के सर्वर पर, केवल openssh-server दिखाई देता है, इसलिए कोई PAM नहीं है।

यदि ldd --version इसके बजाय glibc दिखाता है, या मशीन में कोई SSH सर्वर नहीं चल रहा है, तो वे रुक सकते हैं और अगले सिस्टम पर आगे बढ़ सकते हैं।

चरण 2: पढ़ें कि sshd वास्तव में क्या लागू करता है

यह वह चरण है जिसे टीमें छोड़ देती हैं। कॉन्फ़िग फ़ाइल पढ़कर सिर्फ अनुमान न लगाएँ। सर्वर से उसकी प्रभावी सेटिंग्स पूछें:

sshd -T | grep -iE '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods)'

रोहित यह देखता है:

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

यह रहा आश्चर्य। पासवर्ड लॉगिन चालू हैं। कर्मचारी हमेशा कीज़ (keys) का उपयोग करते थे, इसलिए किसी ने ध्यान नहीं दिया। बिना PAM वाला बिल्ड शायद usepam बिल्कुल प्रिंट न करे, यही कारण है कि इस आउटपुट में ऐसी कोई लाइन नहीं है।

सेटिंग्स प्रति कनेक्शन Match नियमों के माध्यम से भी बदल सकती हैं, इसलिए वे किसी विशिष्ट यूज़र और पते के लिए दृश्य (view) का परीक्षण करते हैं:

sshd -T -C user=deploy,host=bastion.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication'

चरण 3: अकाउंट डेटा की जाँच करें

root के रूप में चलाई जाने पर, ये दो कमांड केवल अकाउंट के नाम प्रिंट करती हैं, हैश कभी नहीं:

awk -F: '$2 == "*" {print "star: " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "hash: " $1}' /etc/shadow

रोहित का परिणाम:

star: deploy
hash: backup-admin

तो deploy, जो "केवल-की" अकाउंट है, उसमें एक * फ़ील्ड है। और backup-admin, जिसे पिछले साल कंसोल एक्सेस के लिए बनाया गया था, उसमें एक योग्य (qualifying) हैश है। चारों शर्तें पूरी होती हैं। यह सर्वर जोखिम में है।

चरण 4: पहले दरवाज़ा बंद करें, फिर पैच करें

रोहित अपना वर्तमान सेशन खुला रखता है और पुष्टि करता है कि उसकी की (key) दूसरे टर्मिनल से काम कर रही है। यहाँ एक गलती सभी को बाहर (lock out) कर सकती है, और खुला हुआ सेशन ही उनकी सुरक्षा की रस्सी है।

वे इस सेटिंग को इसमें जोड़ते हैं /etc/ssh/sshd_config:

PasswordAuthentication no

एक जाल: OpenSSH अधिकांश सेटिंग्स के लिए पढ़े गए पहले मान का उपयोग करता है। यदि फ़ाइल में शीर्ष के पास एक Include लाइन है, या नीचे की ओर एक Match ब्लॉक है, तो नई लाइन शायद प्रभावी न हो। यही कारण है कि संपादन के तुरंत बाद जाँच की जाती है:

sshd -t
sshd -T | grep -i '^passwordauthentication'

sshd -t कॉन्फ़िगरेशन में एरर्स की जाँच करता है। यदि यह पास हो जाता है, तो वे प्रकाशित Alpine फिक्स लागू करते हैं। Alpine ने 3.21.10, 3.22.8, 3.23.8 और 3.24.4 जारी किए हैं, और OpenRC सिस्टम पर इसका समाधान है:

apk upgrade -U -a
rc-service sshd restart

रीस्टार्ट वैकल्पिक नहीं है। पैकेज इंस्टॉल करने से वह SSH सर्वर नहीं बदलता जो पहले से मेमोरी में चल रहा है।

चरण 5: बाहर से इसे साबित करें

अब रोहित एक बाहरी व्यक्ति की तरह, किसी अन्य मशीन से अपने सर्वर के विरुद्ध परीक्षण करता है:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

वे जो उत्तर चाहते हैं वह अस्वीकृति का है, जैसे Permission denied (publickey)। इसका मतलब है कि सर्वर अब पासवर्ड की पेशकश बिल्कुल नहीं करता है। फिर वे एक नए टर्मिनल में एक सामान्य की-आधारित सेशन खोलते हैं ताकि यह पुष्टि हो सके कि कर्मचारी अभी भी अंदर आ सकते हैं।

चरण 6: पिछले दुरुपयोग की जाँच करें

पैचिंग दरवाज़ा बंद कर देती है, लेकिन यह इस बारे में कुछ नहीं बताती कि कौन पहले ही इसमें से होकर गुज़र चुका है। Alpine इस सटीक प्रविष्टि के लिए लॉग्स की समीक्षा करने की सलाह देता है:

grep 'Accepted password for' /var/log/messages

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

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

किसी भी संदिग्ध लॉगिन के समय अकाउंट की स्थिति कैसी थी, इसकी भी जाँच करें। इसकी वर्तमान स्थिति बाद के किसी बदलाव को दर्शा सकती है।

चरण 7: सिर्फ उत्पाद ही नहीं, फ़ैक्टरी को भी ठीक करें

Acme एक सहेजी गई इमेज से सर्वर बनाती है। यदि रोहित चरण 6 पर रुक जाता, तो अगला रीबिल्ड या ऑटोस्केलिंग इवेंट पुरानी सेटिंग्स को सीधे वापस ला सकता था। वे टेम्पलेट को अपडेट करते हैं, वहाँ PasswordAuthentication no सेट करते हैं, और पूछते हैं कि आख़िर backup-admin को किसी पासवर्ड की आवश्यकता ही क्यों है।

स्कैनर के परिणामों को कैसे पढ़ें

इस सप्ताह बहुत अधिक शोर-शराबे वाली (noisy) रिपोर्टों की अपेक्षा रखें। दो बातों को अलग रखें।

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

प्रति सर्वर चार अलग-अलग तथ्यों को ट्रैक करें: असुरक्षित पैकेज की पहचान, प्रतिस्थापन इंस्टॉल होना, सर्विस रीस्टार्ट होना, कॉन्फ़िगरेशन सत्यापित होना। किसी टिकट में "Patched" का अर्थ अक्सर केवल दूसरा बिंदु ही होता है।

फिक्स इतनी जल्दी क्यों आया

डेमियन मिलर ने कहा कि OpenSSH टीम को वर्कअराउंड जारी करने से ठीक एक दिन पहले इस समस्या के बारे में पता चला था। उन्होंने AI एजेंटों द्वारा कुछ ही घंटों के भीतर स्वतंत्र रूप से कमजोरियों को फिर से खोजने के हालिया मामलों की ओर इशारा किया, और तर्क दिया कि लंबे समय तक जानकारी गोपनीय रखना (embargo) हमलावरों के पक्ष में जा सकता है।

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

हममें से अधिकांश के लिए, इसका व्यावहारिक परिणाम सरल है। गंभीर फिक्स अब आपके सामान्य रखरखाव विंडो से बाहर आ सकते हैं। वेंडर की घोषणाओं का सीधे पालन करें, और पहले से ही तय करें कि किसे आपातकालीन बदलाव करने की अनुमति है।

ये बिंदु जोखिम और समझदारी भरी प्रतिक्रिया का वर्णन करते हैं। ये किसी पुष्ट हमले अभियान का प्रमाण नहीं हैं।

असली सबक: तीन वाक्यांश जो एक समान नहीं हैं

"SSH कीज़ का उपयोग करता है", "कोई पासवर्ड सेट नहीं है" और "पासवर्ड से प्रमाणित नहीं हो सकता" सुनने में एक जैसे लगते हैं, लेकिन वे अलग-अलग चीजों का वर्णन करते हैं। पहला एक आदत है। दूसरा डेटा की एक स्थिति है। केवल तीसरा ही एक लागू किया गया नियंत्रण (enforced control) है, और आप चालू सर्वर का परीक्षण करके ही इसे जान सकते हैं।

निष्कर्ष

यह एक सीमित दायरे वाला लेकिन गंभीर बग है। अधिकांश Linux सिस्टम इसके दायरे से बाहर हैं, लेकिन चारों शर्तों से मेल खाने वाला musl-आधारित सर्वर ऐसे अकाउंट के लिए भी लॉगिन स्वीकार कर सकता है जिसका कोई पासवर्ड होना ही नहीं था। अपडेट करें, रीस्टार्ट करें, सेट करें PasswordAuthentication no, बाहर से सत्यापित करें, अपने लॉग्स पढ़ें और अपने टेम्पलेट्स को ठीक करें। फिर लिखें कि आपके संगठन में "केवल-की" (key-only) का क्या अर्थ है, और इसका परीक्षण करें।

सकारात्मक पहलू

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

नकारात्मक पहलू

• केवल "OpenSSH इंस्टॉल है" दिखाने वाली एसेट सूचियाँ इस प्रश्न का उत्तर नहीं दे सकती हैं।
• एक सामान्य बदलाव, जैसे कि पासवर्ड वाला यूज़र जोड़ना, एक सुरक्षित मशीन को भी जोखिम में डाल सकता है।
• SSH सेटिंग्स में गलतियाँ एडमिनिस्ट्रेटर्स को सिस्टम से बाहर (lock out) कर सकती हैं।
• पैचिंग किसी भी पुराने अनधिकृत एक्सेस को न तो उजागर करती है और न ही पूर्ववत करती है।

सावधानी

यह लेख शैक्षिक है और लेखन के समय उपलब्ध प्रकाशित एडवाइज़री और रिपोर्टिंग पर आधारित है। Acme, रोहित, deploy, backup-admin, होस्टनेम और IP एड्रेस काल्पनिक प्लेसहोल्डर हैं, इसलिए उन्हें अपने मानों से बदलें। SSH सेटिंग्स बदलते समय एक सक्रिय सेशन खुला रखें, केवल उन्हीं सिस्टम्स का परीक्षण करें जिनके लिए आप अधिकृत हैं, और उन पर निर्भर रहने से पहले वर्तमान OpenSSH और Alpine एडवाइज़रीज़, या अपने वेंडर के मार्गदर्शन से विवरण सत्यापित करें।

अक्सर पूछे जाने वाले प्रश्न

• OpenSSH 10.6p2 क्या है? — यह 5 नवंबर 2026 की एक आपातकालीन Portable OpenSSH रिलीज़ है, जिसमें लॉगिन बायपास के लिए एक वर्कअराउंड दिया गया है जो कुछ musl-आधारित Linux सिस्टम्स को प्रभावित करता है।
• क्या प्रत्येक Alpine Linux सिस्टम वल्नरेबल है? — नहीं। सिस्टम को PAM के बिना पासवर्ड चेक करने वाले एक रनिंग SSH सर्वर, सक्षम पासवर्ड ऑथेंटिकेशन, एक ऐसे टारगेट अकाउंट की आवश्यकता होती है जिसमें * पासवर्ड फ़ील्ड हो, और एक अन्य लोकल अकाउंट जिसमें $5$ या $6$ हैश हो।
• क्या Ubuntu, Debian और अन्य glibc सिस्टम प्रभावित हैं? — glibc का उपयोग करने वाले Linux सिस्टम बताए गए दायरे से बाहर हैं, साथ ही गैर-Linux प्लेटफ़ॉर्म और PAM के माध्यम से पासवर्ड चेक करने वाले Linux सिस्टम भी।
• क्या Alpine Docker कंटेनर जोखिम में हैं? — बिना रनिंग SSH सर्वर वाले कंटेनर इस अटैक पाथ से बाहर हैं, इसलिए सवाल यह है कि क्या कोई कंटेनर वास्तव में sshd चलाता है।
• क्या PermitRootLogin prohibit-password मुझे सुरक्षित रखता है? — यह root पर सीधे पासवर्ड लॉगिन को ब्लॉक करता है, लेकिन यह किसी हमलावर को किसी अन्य अकाउंट के माध्यम से प्रवेश करने और एस्केलेट करने से नहीं रोकता, जैसा कि tiny-cloud alpine अकाउंट परिदृश्य में।
• क्या पैकेज को अपडेट करना ही काफ़ी है? — नहीं। आपको SSH सर्विस को रीस्टार्ट भी करना होगा, क्योंकि जब तक आप ऐसा नहीं करते, पुराना सर्वर मेमोरी में चलता रहता है।
• अगर मैं आज अपडेट नहीं कर सकता तो मुझे क्या करना चाहिए? — सेट करें PasswordAuthentication no, प्रभावी सेटिंग की पुष्टि sshd -Tसे करें, और मौजूदा सेशन खुला रखते हुए की एक्सेस का परीक्षण करें।
• मैं कैसे जाँचूँ कि क्या किसी ने पहले ही इसका इस्तेमाल किया है? — सर्च करें /var/log/messages में Accepted password for प्रविष्टियों के लिए उन खातों पर जिन्हें पासवर्ड का उपयोग नहीं करना चाहिए, और यदि अनधिकृत लॉगिन से इनकार नहीं किया जा सकता है तो होस्ट को कॉम्प्रोमाइज़्ड मानें।

टैग

#OpenSSH #AlpineLinux #LinuxSecurity #SSH #AuthenticationBypass #Musl #DevSecOps #CloudSecurity #PatchManagement #IncidentResponse