SSH3 - HTTP/3 का उपयोग करने वाला तेज़ और अधिक सक्षम secure shell

 (github.com/francoismichel)
8 पॉइंट द्वारा GN⁺ 2025-09-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SSH3 एक अगली पीढ़ी का secure shell protocol है जो HTTP/3 के ऊपर काम करता है, और पारंपरिक SSHv2 की तुलना में session connection speed को काफी बेहतर बनाता है
  • QUIC और TLS 1.3 के जरिए एक secure channel बनाता है, और OAuth 2.0, OpenID Connect जैसी आधुनिक authentication systems को सपोर्ट करता है
  • सर्वर को एक secret path के पीछे छिपाया जा सकता है, इसलिए यह port scanning जैसे हमलों के खिलाफ अधिक मज़बूत है, और UDP port forwarding/QUIC multipath जैसी नई क्षमताएँ देता है
  • इसने OpenSSH की कई core features पहले ही अपना ली हैं, लेकिन फिलहाल यह experimental चरण में है, इसलिए production environment में इसकी deployment की सिफारिश नहीं की जाती
  • SSH3 नाम को लेकर काफ़ी आपत्तियाँ थीं, इसलिए standardization draft का नाम बदलकर “Remote Terminals over HTTP/3” कर दिया गया है और नाम बदलने की प्रक्रिया जारी है

SSH3 प्रोजेक्ट का अवलोकन और महत्व

  • SSH3 एक open source solution है जो मौजूदा SSH protocol को HTTP/3 और आधुनिक web technologies के अनुरूप फिर से डिज़ाइन करता है
    • मौजूदा SSH connection protocol (RFC4254) के semantics को HTTP/3 Extended CONNECT और QUIC+TLS 1.3 channel के ऊपर फिर से बनाया गया है
  • इसे IETF Internet-Draft draft-michel-remote-terminal-http3 के रूप में प्रस्तावित किया गया है, और यह session connection speed को काफ़ी कम latency वाला बनाते हुए आधुनिक authentication methods के विस्तार जैसे कई फायदे देता है
  • दूसरी SSH implementations की तुलना में, QUIC का उपयोग और hidden server configuration जैसे नए विचार इसकी खास पहचान हैं

मुख्य फीचर्स और विशेषताएँ

  • तेज़ session connection
    • जहाँ पारंपरिक SSHv2 connection को औसतन 5~7 network round trips की ज़रूरत होती है, वहीं SSH3 को केवल 3 round trips चाहिए, जिससे उपयोगकर्ता की प्रतीक्षा काफी कम हो जाती है
    • key input latency मौजूदा स्तर के बराबर रहती है
  • मज़बूत सुरक्षा
    • TLS1.3, QUIC, और HTTP authentication पर आधारित होने के कारण यह उन tested security protocols का उपयोग करता है जो पहले से e-commerce और internet banking जैसी सेवाओं में इस्तेमाल होते हैं
    • RSA, EdDSA/ed25519 आधारित public key methods और OAuth 2.0, OpenID Connect जैसी विभिन्न authentication methods को सपोर्ट करता है
    • Google, Microsoft, Github accounts से भी login किया जा सकता है
  • सर्वर को छिपाने की सुविधा
    • सर्वर को किसी खास secret URL (उदाहरण: https://192.0.2.0:443/M3MzkxYWMx... आदि) के पीछे रखा जा सकता है, और केवल उसी URL पर authentication request आने पर जवाब दिया जाता है
    • बाकी सभी requests पर 404 Not Found लौटाया जाता है, जिससे इंटरनेट पर मौजूद attackers या crawlers सर्वर के अस्तित्व का पता नहीं लगा पाते
    • हालांकि secret path authentication का विकल्प नहीं है, इसलिए अलग authentication mechanism (public key, password, OIDC आदि) का उपयोग ज़रूर करना चाहिए
  • लगातार विकसित होता experimental project
    • इसकी संरचना के लिहाज़ से भरोसेमंद security validation अभी ज़रूरी है, और production servers पर इसे अपनाने की सिफारिश नहीं की जाती
    • फिलहाल experimental environments या closed networks में community feedback लिया जा रहा है
  • OpenSSH compatibility और अतिरिक्त फीचर्स
    • ~/.ssh/authorized_keys और known_hosts parsing, ssh-agent integration, TCP/UDP port forwarding, Proxy Jump support
    • UDP forwarding के समर्थन से DNS·RTP·QUIC services जैसी UDP-आधारित servers तक पहुँच मिलती है, और इसके लिए QUIC datagram path का उपयोग होता है
    • X.509 certificates के माध्यम से HTTPS-स्तर की server authentication सुविधा
    • Keyless authentication: OpenID Connect के जरिए public key कॉपी किए बिना enterprise SSO या Google/Github जैसे external accounts से ही access संभव

निष्कर्ष

  • SSH3 एक open source experimental project है जो आधुनिक network protocols और authentication को अपनाकर SSH वातावरण को आगे बढ़ाता है
  • यह speed, flexibility और security को काफ़ी मज़बूत बनाता है, लेकिन पर्याप्त validation से पहले production use में सावधानी बरतनी चाहिए
  • यह OpenSSH जैसा user experience देता है और नए फीचर्स भी भरपूर प्रदान करता है
  • सही security evaluation और community participation के साथ यह अगली पीढ़ी के SSH के रूप में उभरने की क्षमता रखता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-28
Hacker News टिप्पणियाँ
  • मुझे ssh3 नाम बिल्कुल पसंद नहीं आया, इसलिए अच्छा लगा कि रिपॉज़िटरी के सबसे ऊपर लिखा है: “SSH3 का नाम बदला जाएगा। अभी यह SSH Connection Protocol(RFC4254) को HTTP/3 Extended connect के ऊपर चलाने का एक रूप है, लेकिन इसमें बहुत सारे ज़रूरी बदलाव हैं और यह मौजूदा SSH से इतना अलग है कि इसे आसानी से एकीकृत नहीं किया जा सकता। स्पेसिफिकेशन ड्राफ्ट का नाम पहले ही ‘Remote Terminals over HTTP/3’ कर दिया गया है, और बेहतर स्थायी नाम पर सोचने के लिए समय चाहिए।”
    • ऐसा नाम वैसा लगता है जैसे कोई “Windows 12” या “Linux 7” नाम का रेपो बना दे
    • SSH3 की जगह Secure Hypertext Interactive TTY जैसा नाम सुझाया गया
    • मैंने सोचा SSH/3 कैसा रहेगा (SSH + HTTP/3 वाली भावना)
    • यह थ्रेड सच में पूरी तरह की ‘bike-shedding’ बहस का एक शाहकार है
    • मैंने सोचा SSH2/3 भी ठीक हो सकता है, क्योंकि ज्यादातर चीज़ SSH2 है लेकिन यह HTTP/3 के ऊपर चलती है
  • राय यह थी कि SSH धीमा है, और मेरे अनुभव में सबसे बड़ा bottleneck session setup में होता है। चाहे वह PAM की वजह से हो या OpenBSD की policy की वजह से, SSH connection को reuse करो या नया बनाओ, हर बार session setup stage बहुत धीमा लगता है। लंबे session में तो ठीक है, लेकिन सिर्फ एक साधारण command चलाने के लिए भी हर बार overhead आता है, इसलिए Ansible का performance भी संतोषजनक नहीं लगा, और इसी वजह से मैंने बिना session overhead वाला remote command execution mini ansible खुद बना लिया
  • पहले मुझे शक हुआ, ‘क्या यह सच में पारंपरिक SSH से तेज़ है?’ लेकिन README देखकर समझ आया कि सिर्फ connection setup चरण तेज़ है, connection के बाद वास्तविक speed वही रहती है। इतना भी अपने-आप में एक सही सुधार है
    • दरअसल उस मायने में यह ज़्यादा तेज़ नहीं है। एक ही SSH connection में कई ports पर traffic forwarding करते समय head-of-line blocking होता है, और QUIC/HTTP3 protocol इस समस्या को हल कर सकता है
    • मैं शर्त लगा सकता हूँ कि high-latency links पर यह protocol SSH से बहुत तेज़ होगा, क्योंकि यह UDP-based है और ack का इंतज़ार किए बिना bulk data लगातार भेज सकता है, इसलिए दुनिया भर में बड़े files को scp करते समय काफ़ी speed improvement की उम्मीद है
    • VPN के ऊपर यह सच में तेज़ हो सकता है, क्योंकि इसमें “TCP के अंदर फिर TCP” वाला जाल (performance समस्या) नहीं है
    • HTTP/3 और QUIC का मुख्य फ़ायदा ही यही है कि पहले की तुलना में round trips कम होते हैं, इसलिए connection setup तेज़ होना उसी से मेल खाता है
  • इसकी व्याख्या यह थी: “SSHv2 में session initialization के लिए लगभग 5~7 round trips चाहिए होते हैं, जबकि SSH3 में सिर्फ 3। असली session के दौरान input latency (key press–response time) समान रहती है।” उपयोगकर्ता के नज़रिए से मुझे कभी connection speed इतनी बड़ी समस्या नहीं लगी, इसलिए इसमें ज़्यादा आकर्षण नहीं दिखता। SSH की reliability भी लंबे समय से battle-tested है, और ऐसा नया tool production-grade हो तब भी उस पर भरोसा करना जोखिम भरा लगता है
    • UDP tunnel इसका मुख्य feature है, यह wireguard से काफ़ी हल्का है और इसमें OpenID authentication जैसी चीज़ें भी हैं
    • ‘Connection speed’ हमेशा मुझे थोड़ा परेशान करती रही है। remote पर command तुरंत चलानी हो तो उसकी धीमी शुरुआत खास तौर पर खलती थी
    • ssh3 में head-of-line blocking के हल होने की संभावना ज़्यादा है, इसलिए एक physical connection पर कई ports या connections को multiplex करने पर यह तेज़ हो सकता है
    • अगर smooth user experience चाहिए तो Mosh की सिफारिश है
  • यह बात न जाने क्यों उदास करती है कि सारे application-layer protocols आख़िरकार http में समा रहे हैं
    • अगर सच में यही रुझान है तो दुख की बात है। HTTP का पारंपरिक मॉडल ज़्यादातर मामलों में बहुत सीमित भी है और जटिल भी, इसलिए हर जगह फिट नहीं बैठता। लेकिन HTTP/2 या QUIC (जो HTTP/3 का transport है) इतने general-purpose हैं कि HTTP नाम अपने-आप में ज़्यादा मायने नहीं रखता। कम-से-कम QUIC को TCP replacement के रूप में काफ़ी साफ़ तरीके से position किया जा रहा है
    • सच कहूँ तो अगर सारे protocols इस तरह standardize हो जाएँ तो traffic shaping, censorship वगैरह मुश्किल हो जाएँगे, इसलिए मैं इसे सकारात्मक भी मानता हूँ। आख़िर में traffic या तो HTTP होता है, या random byte stream—यानी अगर वह अलग से नज़र न आए तो network monitoring/blocking मुश्किल हो जाती है। अगर नया protocol बनाना है, तो जब तक telecom operator उसे कोई ख़ास फ़ायदा न दे, HTTP जैसा दिखना अक्सर बिना धीमा हुए सही से चलने का सबसे अच्छा तरीका होता है
    • ऐसी blocking का एक कारण corporate security teams की वह आदत भी है जिसमें वे हर चीज़ को block या intercept करना चाहती हैं। Zscaler या TLS middleman mode इस्तेमाल करने वाली teams, मैं तुम लोगों की ही बात कर रहा हूँ
    • इस तरह की रुकावटें airport Wi-Fi या दुनिया भर के hotels में भी दिखती हैं। जैसे Apple Mail से mail न भेज पाना, क्योंकि corporate policy के नाम पर port 25 block कर दिया जाता है। spam रोकने के बहाने 143, 587, 993 आदि भी block कर दिए जाते हैं, और आख़िर में सिर्फ 80, 443 ही खुले रहते हैं। उम्मीद है IPv6 कुछ सुधार लाएगा। और EU की ChatControl जैसी कोशिशें भी रुकनी चाहिए। काश सच में IT समझने वाले लोगों की सुनी जाती
    • connection init, यानी network connection initialization, की जटिलता बढ़ जाने पर आख़िरकार battle-tested protocols पर आधारित best practice का सहारा लेना समझ में आता है। लेकिन जब वास्तविक transport अब hypertext नहीं रहा, तब भी उसे लगातार http कहना थोड़ा अटपटा लगता है
  • SSH की functionality का evolve होना अच्छी बात है, लेकिन अगर काम लगभग नए सिरे से ही हो रहा है तो थोड़ा और experimental features भी जोड़ने चाहिए थे। जैसे Mosh जैसी “roaming / अस्थायी network instability” को संभालने वाली सुविधाएँ होतीं तो अच्छा रहता https://mosh.org/
    • Mosh का फ़ायदा यह है कि key input का response बहुत तेज़ लगता है, मानो आप local shell पर सीधे काम कर रहे हों। सोच रहा हूँ SSH3 में इस दिशा में कोई सुधार है या नहीं। QUIC थोड़ा मदद कर सकता है, लेकिन वह Mosh जैसा नहीं है
    • मेरी समझ से connection migration और multipath support, QUIC की बुनियादी विशेषताएँ हैं, और roaming feature तथा 'built-in tmux' के बीच फर्क यह है कि क्या उसका सीधे system में घुला-मिला होना वाकई इतना मूल्यवान है, इस पर मुझे यक़ीन नहीं
  • जो लोग छोटे नामों/abbreviations पर अटके रहते हैं, वे मुझे समझ नहीं आते; यह सच में अच्छा नहीं लगता। अब command लंबी हो तो भी चलेगा, लेकिन नाम तकनीकी रूप से जितना संभव हो उतना स्पष्ट और लंबा होना चाहिए। पूरा नाम default होना चाहिए, और abbreviation कुछ system administrators या distributions चाहें तो छोटा करके इस्तेमाल करें। लोगों को full name सिखाया जाना चाहिए। उदाहरण के लिए Set-Location, cd से ज़्यादा बेहतर है, और remote-terminals-over-http3, ssh3 से बेहतर नाम है
  • आख़िरी commit एक साल पहले की है, क्या किसी को इस project की हाल की प्रगति के बारे में पता है?
  • project की योजना को लेकर जिज्ञासा हुई। release हो या GitHub activity, एक साल से ज़्यादा समय से कोई अपडेट नहीं है। चूँकि इसकी शुरुआत paper से हुई थी, हो सकता है संबंधित research या कोई और सहायक काम चलता रहा हो
    • इस point को उठाने के लिए धन्यवाद। निजी तौर पर मुझे लगता है कि यह project अब ख़त्म हो चुका है। लगभग 239 commits के साथ यह असल में Proof of Concept स्तर का ही लगता है, अभी गंभीर उपयोग के लायक नहीं। दूसरी ओर OpenBSD पक्ष (OpenSSH) अब भी बेहद सक्रिय है, इसलिए निकट भविष्य में इसके replace होने की संभावना नहीं दिखती https://github.com/openbsd/src/commits/master/
  • project का idea अच्छा है। अगर इसे सामान्य H3 proxy के ज़रिए proxy किया जा सके, तो खास तौर पर उम्मीद बढ़ती है। और अगर यह multipath/migration तथा TCP से जुड़ी blocking issues भी हल कर दे, तो यह पहले से ही बहुत बड़ी प्रगति होगी