OpenSSH में DSA समर्थन हटाने की समयरेखा

मूल लेख ↗ Hacker News चर्चा ↗

OpenSSH 2025 की शुरुआत तक legacy DSA public-key algorithm का समर्थन पूरी तरह हटाने की योजना बना रहा है, जो वर्षों से डिफ़ॉल्ट रूप से अक्षम रहने और 1024‑bit DSA को चरणबद्ध रूप से समाप्त करने के लिए NIST के लंबे समय के मार्गदर्शन के अनुरूप है। टिप्पणीकार obsolete cryptography को हटाने के सुरक्षा और maintenance लाभों—जैसे project को key handling सरल करने और post‑quantum algorithms की तैयारी—को उन संगठनों की operational कठिनाइयों के मुकाबले रखते हैं जिन्हें अभी भी unupgradable hardware, industrial systems, और air‑gapped environments तक पहुँच चाहिए। प्रचलित राय यह है कि ऐसे legacy needs वालों को पुराने OpenSSH releases को pin या containerize करना चाहिए, या वैकल्पिक clients का उपयोग करना चाहिए, बजाय इसके कि upstream से weak algorithms को अनिश्चितकाल तक बनाए रखने की अपेक्षा करें।

अप्रचलन की समयरेखा और इतिहास

  • OpenSSH DSA को चरणबद्ध तरीके से हटाने की योजना बना रहा है:
    • 2024-03: DSA compile time पर वैकल्पिक, डिफ़ॉल्ट रूप से सक्षम।
    • 2024-06: DSA वैकल्पिक, डिफ़ॉल्ट रूप से अक्षम।
    • 2025-01: DSA OpenSSH से हटाया गया।
  • टिप्पणीकारों का कहना है कि यह लंबे समय से चली आ रही मार्गदर्शन के अनुरूप है:
    • NIST ने 2010 तक 1024‑bit DSA के उपयोग को समाप्त करने की सिफारिश की थी।
    • OpenSSH ने कभी बड़े DSA keys का समर्थन नहीं किया और OpenSSH 7 (2015) में पहले ही DSA को डिफ़ॉल्ट रूप से अक्षम कर दिया था।

DSA हटाने का औचित्य

  • बताए गए मुख्य कारण:
    • SSHv2 में DSA 1024‑bit सार्वजनिक / 160‑bit निजी keys तक सीमित है और इसे कमजोर माना जाता है।
    • विरासती code को बनाए रखना महँगा है, खासकर refactors के दौरान और नए algorithms (जैसे post‑quantum signatures) जोड़ते समय।
    • पुराने, शायद ही परीक्षण किए गए code paths को सुरक्षा जोखिम माना जाता है।

विरासती प्रणालियों पर प्रभाव

  • कुछ उपयोगकर्ताओं को अभी भी DSA की आवश्यकता है, ताकि वे इन तक पहुँच सकें:
    • पुराने network hardware, switches, BMCs, iLO, telco gear, industrial control, पुराना RHEL, और partner systems।
  • चिंता: “cannot be fixed” प्रणालियाँ दशकों तक सेवा में रह सकती हैं, खासकर industrial और critical infrastructure में।
  • अन्य लोग तर्क देते हैं कि ऐसी प्रणालियों को अलग-थलग, air‑gapped, या बदला जाना चाहिए; यदि उन्हें अपडेट नहीं किया जा सकता, तो उन्हें व्यापक networks के सामने नहीं होना चाहिए।

जिम्मेदारी और अधिकारबोध

  • एक मजबूत विषय: open-source maintainers पर obsolete crypto को अनिश्चितकाल तक समर्थन देने की बाध्यता नहीं है।
  • प्रतिवाद: deprecation की लागत को downstream धकेलने से कुल काम बढ़ता है और भारी regulated या bureaucratic environments में यह कठिन हो सकता है।
  • कुछ लोग तर्क देते हैं कि पूर्ण हटाने के बजाय एक “dangerous/legacy” flag या plugin model बेहतर होगा।

विकल्प और workaround

  • सुझाव:
    • OpenSSH का पुराना client बनाए रखें (संभवतः VM, container, या विशेष “legacy jump host” में)।
    • ऐसे distro packages का उपयोग करें जो पुराने protocols को बनाए रखते हैं (जैसे ssh1 client)।
    • वैकल्पिक SSH implementations (Dropbear, PuTTY) का उपयोग करें, या अत्यधिक नियंत्रित networks में telnet तक।
  • आधुनिक systems पर बहुत पुराने OpenSSH को compile करने और legacy clients की सुरक्षा को लेकर चिंताएँ उठाई गईं।

संबंधित crypto चर्चाएँ

  • SSHv2 spec में उपयोग किए गए DSA parameters और इसकी अंतर्निहित 160‑bit private key पर स्पष्टीकरण।
  • अन्य key types पर चर्चा: RSA, ECDSA, Ed25519।
  • एक side thread में बड़े clouds का उल्लेख: AWS Ed25519 support जोड़ता है; Azure और कुछ GCP components में reportedly अभी भी यह अनुपस्थित है।