Ing. Calogero Bono
5 नवंबर 2026 को OpenSSH 10.6p2 जारी हुआ, जो «*sshole» नाम के एक बग को ठीक करता है। यह उन Linux SSH सर्वरों को प्रभावित करता है जो musl लाइब्रेरी इस्तेमाल करते हैं, जैसे Alpine Linux, और जिनमें PAM बंद है। SSH पोर्ट तक पहुँचने वाला कोई भी व्यक्ति बहुत लंबा पासवर्ड भेजकर बिना पासवर्ड के अकाउंट में घुस सकता है। यह मायने रखता है क्योंकि इसके लिए एक कनेक्शन काफी है और Alpine की आधिकारिक क्लाउड इमेज root के रूप में पहुँच दे सकती हैं।
कुछ शब्द, तथ्यों में जाने से पहले। musl glibc का एक वैकल्पिक C लाइब्रेरी है, जिसे Alpine, OpenWrt, Buildroot और Yocto इस्तेमाल करते हैं। crypt() वह फ़ंक्शन है जो पासवर्ड को उसके hash में बदलता है। PAM Linux की मॉड्यूलर प्रमाणीकरण प्रणाली है। /etc/shadow वह फ़ाइल है जिसमें पासवर्ड के hash रखे जाते हैं। doas एक टूल है, sudo जैसा, जिससे root के अधिकार मिलते हैं।
*sshole बग कैसे काम करता है?
Linux अकाउंट में /etc/shadow के hash की जगह एक तारा (*) होता है। कोई पासवर्ड उसे खोलना नहीं चाहिए। BleepingComputer के अनुसार 2016 का OpenSSH बदलाव, जो CVE-2016-6210 (user enumeration) ठीक करने के लिए आया था, इन अकाउंट के लिए भी hash की गणना करवाता है।
यहीं musl आता है। Alpine की चेतावनी के अनुसार musl का crypt() जब key 256 bytes से लंबी होती है, तो error संकेत के रूप में * लौटाता है। यह तारा अकाउंट में सेव तारे से मेल खा जाता है, और तुलना सफल हो जाती है। शोधकर्ता Özgün Kültekin कहते हैं कि यह खामी 2016 से मौजूद है।
किसे सच में खतरा है?
कई शर्तें एक साथ होनी चाहिए। Alpine के अनुसार openssh-server पैकेज PAM के बिना compile हुआ हो, या openssh-server-pam के साथ UsePAM no हो। PasswordAuthentication चालू होना चाहिए, जैसा डिफ़ॉल्ट है। एक अकाउंट में * होना चाहिए और कम से कम एक और अकाउंट में $5$ या $6$ hash हो। एक भी उपयोगकर्ता के पासवर्ड वाला होने पर बाकी सभी तक पहुँच संभव हो जाती है।
Alpine ने 3.21 से 3.24 और edge, साथ ही पुराने 3.16-3.20 संस्करणों की जाँच की है। sshd के बिना चलने वाले containers, PasswordAuthentication no वाले सिस्टम और PAM चालू वाले सिस्टम प्रभावित नहीं हैं। BleepingComputer लिखता है कि glibc इस्तेमाल करने वाले Debian, Ubuntu और Fedora सुरक्षित हैं।
Alpine की क्लाउड इमेज क्यों चिंता बढ़ाती हैं?
आधिकारिक tiny-cloud इमेज, 3.18.11 से 3.24.3 तक, में alpine नाम का एक यूज़र होता है जिसका पासवर्ड * है और doas बिना पासवर्ड के चलता है। Alpine बताता है कि पहली बूट पर ये सुरक्षित हैं। ये तब कमज़ोर हो जाती हैं जब $6$ hash आ जाए, जैसे कोई एडमिन console पासवर्ड सेट करे या user-data में hashed_passwd वाला यूज़र जोड़ा जाए।
उस स्थिति में हमलावर को alpine के रूप में shell मिल जाती है और doas से वह root बन जाता है। cloud-init से कॉन्फ़िगर की गई इमेज, जिनमें PasswordAuthentication no लिखा होता है, प्रभावित नहीं हैं। root के लिए डिफ़ॉल्ट PermitRootLogin prohibit-password केवल सीधे प्रयास से बचाता है।
इसे कैसे ठीक करें और हमले की जाँच कैसे करें?
सुधार OpenSSH 10.6p2 में है। Alpine पर apk upgrade -U -a चलाएँ, फिर sshd रीस्टार्ट करें, क्योंकि अपडेट चल रहे daemon को नहीं बदलता। Alpine ने 3.16 तक के सुधारित पैकेज जारी किए हैं, यहाँ तक कि उन releases के लिए भी जो अब समर्थित नहीं हैं।
अगर अभी अपडेट नहीं कर सकते, तो PasswordAuthentication no लिखकर sshd रीस्टार्ट करें, पर पहले जाँच लें कि key से प्रवेश काम करता है। निशान खोजने के लिए /var/log/messages में उन «Accepted password» पंक्तियों को देखें जो बिना पासवर्ड वाले अकाउंट के लिए हों। Alpine जोड़ता है कि अगर किसी पहुँच को नकारा नहीं जा सकता, तो मशीन को समझौता हुआ मानना चाहिए। अकाउंट की अनुमतियों के लिए Linux अनुमतियों की गाइड भी उपयोगी है।
सीमाएँ जो जानना ज़रूरी हैं
Alpine के अनुसार प्रकाशन के समय इस बग के लिए कोई CVE नहीं दिया गया था। OpenSSH लिखता है कि इसकी जड़ sshd के बाहर है, पर sshd के ज़रिये इसका फायदा उठाया जा सकता है और वहीं इसे रोका जाता है। अभी वास्तविक हमलों का कोई डेटा नहीं है। 17,600 AI एजेंट परीक्षणों वाले दावे शोधकर्ता के हैं, BleepingComputer ने इन्हें रिपोर्ट किया है, और इनकी स्वतंत्र पुष्टि नहीं हुई है।
डिजिटल काम करने वालों के लिए क्या बदलता है
अगर आप Alpine सर्वर, OpenWrt राउटर या Yocto और Buildroot वाले embedded सिस्टम चलाते हैं, तो जाँच करें कि sshd पासवर्ड की अनुमति देता है या नहीं, और कहीं ऐसे अकाउंट तो नहीं जिनमें * लगा है। बहुत से लोग Alpine को बिना sshd के containers में चलाते हैं, वे प्रभावित नहीं हैं। tiny-cloud इमेज वाली क्लाउड मशीनें रखने वालों को चल रहे हर इंस्टेंस की जाँच करनी होगी। नियमित अपडेट वाला प्रबंधित सर्वर इस तरह के जोखिम को कम करता है, इस पर हमारा पेज होस्टिंग और प्रबंधित सर्वर देखें। साथ ही AI से बने exploits वाले संबंधित मामले पर भी नज़र रखें, जिस पर हमने इस लेख में लिखा था।
हमारी राय
यह मामला दिखाता है कि उन components के बीच की सीमा कितनी नाज़ुक है जो एक-दूसरे पर भरोसा करते हैं। OpenSSH ने 2016 में एक वैध बचाव जोड़ा, musl ने एक आम error मान चुना, और दोनों ने मिलकर दस साल तक एक दरवाज़ा खुला रखा। यह बात भी ध्यान खींचती है कि बग AI एजेंटों से मिला। OpenSSH खुद चेतावनी देती है कि AI से मिले बग अक्सर दूसरे लोग भी दोबारा खोज लेते हैं, इसलिए इंतज़ार करना जोखिम भरा है। सबसे मज़बूत उपाय वही है जो हमेशा रहा है – पासवर्ड की जगह keys।
अक्सर पूछे जाने वाले सवाल
क्या Debian और Ubuntu *sshole से प्रभावित हैं?
नहीं। ये glibc इस्तेमाल करते हैं, musl नहीं। BleepingComputer की पुष्टि है कि PAM प्रमाणीकरण वाले सिस्टम प्रभावित नहीं हैं, पर Alpine बताता है कि UsePAM no वाला openssh-server-pam प्रभावित है, जबकि UsePAM yes के साथ वह सुरक्षित है।
क्या सिर्फ openssh पैकेज अपडेट करना काफी है?
नहीं, sshd को रीस्टार्ट करना भी ज़रूरी है। Alpine बताता है कि अपडेट चल रहे daemon की जगह नहीं लेता, इसलिए कमज़ोर संस्करण चालू रह जाएगा।
क्या अपडेट किए बिना खुद को बचा सकते हैं?
हाँ, अस्थायी रूप से। sshd की configuration में PasswordAuthentication no लिखें और सेवा रीस्टार्ट करें। पहले जाँच लें कि key से प्रवेश काम कर रहा है।
क्या root भी खुला है?
सिर्फ कुछ स्थितियों में। डिफ़ॉल्ट PermitRootLogin prohibit-password के साथ root सीधे पहुँच में नहीं आता। यह तब खुलता है जब PermitRootLogin yes चालू हो, या जब कोई दूसरा यूज़र doas के ज़रिये root बन सके।
क्या इस बग के लिए CVE है?
Alpine के अनुसार अभी तक नहीं। चेतावनी कहती है कि लिखने के समय तक कोई पहचानकर्ता नहीं दिया गया था। संदर्भ OpenSSH 10.6p2 के release notes हैं।
OpenSSH 10.6p2 के बाद आगे क्या देखें
OpenSSH ने सुधार उपयोगकर्ताओं तक तेज़ी से पहुँचाने के लिए बार-बार रिलीज़ करने की घोषणा की है। इस बग से कुछ सवाल खुले रह जाते हैं, जिन पर नज़र रखनी चाहिए।
- देखते रहें कि CVE दिया जाता है या नहीं, और आपके scanning tools उसे पहचानते हैं या नहीं।
- जाँचें कि OpenWrt, Buildroot और Yocto पर आधारित firmware बनाने वाली कंपनियाँ अपडेट कब जारी करती हैं।
- OpenSSH के छोटे releases को तय schedule का इंतज़ार किए बिना इंस्टॉल करने की routine तैयार रखें।
