HTTPS के जरिए SSH कनेक्शन

 (trofi.github.io)
3 पॉइंट द्वारा GN⁺ 2023-12-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सीमित नेटवर्क में SSH पोर्ट ब्लॉक होने पर भी HTTPS 443 पोर्ट और CONNECT method से remote access का रास्ता बनाया जा सकता है
  • सर्वर apache2 के mod_proxy_connect से CONNECT खोलता है, लेकिन proxy का दायरा सीमित करने के लिए केवल ssh-server:22 target की अनुमति देता है
  • क्लाइंट OpenSSH के ProxyCommand को socat से जोड़ता है, और HTTPS में script सीधे CONNECT header भेजती है
  • कुछ firewall या httpd idle connection बंद कर सकते हैं, इसलिए ServerAliveInterval 30 से session बनाए रखने में मदद मिलती है
  • यह तरीका SSH को TLS के अंदर encapsulate करके blocking से बचना आसान बनाता है, लेकिन double encryption और client configuration का बोझ रहता है

सीमित नेटवर्क में SSH access path बनाना

  • अस्पताल के Wi-Fi environment में अधिकांश connection types block थे, और मुख्य रूप से HTTP का TCP 80 और HTTPS का TCP 443 ही allow था
  • DNS का UDP 53 और DoT का TCP 853 जाने-माने DNS providers के लिए काम करते दिखे
  • SSH TCP 22 और अधिकांश custom ports पर पूरी तरह block था
  • remote server को फिर से configure करने के लिए GSM alternative connection था, इसलिए कई bypass methods test किए जा सके

एक port share करना और protocol encapsulation

  • एक ही port पर SSH और HTTPS दोनों receive करके transparently route करने का तरीका मौजूद है
    • sslh project heuristics से protocol का अनुमान लगाकर वास्तविक backend यानी SSH, HTTPS या supported protocol पर redirect करता है
    • फायदा यह है कि ssh client में कोई खास setting की जरूरत नहीं होती, केवल non-default port specify करना होता है
    • नुकसान यह है कि अतिरिक्त service setup करनी पड़ती है, HTTPS को भी sslh से गुजरना पड़ता है, और backend पर connection का original address छिप सकता है, जिससे logging असुविधाजनक हो सकती है
  • दूसरा विकल्प एक protocol को दूसरे protocol के अंदर पूरी तरह encapsulate करना है
    • OpenSSH का ProxyCommand user को ssh protocol के लिए इस्तेमाल होने वाला transport तय करने देता है
    • heuristics के बिना SSH को किसी दूसरे stream के अंदर wrap किया जाता है, इसलिए DPI software के लिए इसे block करना ज्यादा मुश्किल हो सकता है
    • HTTPS खुद redirect नहीं होता और प्रभावित नहीं होता
    • बदले में double encryption से performance घट सकती है, और client configuration जरूरी है

SSH over HTTP configuration

  • पहले SSH को HTTP के जरिए pass कराने का तरीका आजमाया गया
  • server-side apache2 configuration में mod_proxy_connect load किया गया, और AllowCONNECT 22 से port 22 CONNECT allow किया गया
  • <Proxy *> को default रूप से सब deny करने के लिए रखा गया, और target को ssh-server:22 तक सीमित करने के लिए केवल <Proxy ssh-server> allow किया गया
  • client-side .ssh/config में ProxyCommand के भीतर socat का PROXY:http-server:%h:%p,proxyport=80 इस्तेमाल किया गया
  • इस setup से $ ssh ssh-via-http चलाने पर port 80 के जरिए SSH से connect किया जा सकता है
  • ServerAliveInterval 30 बीच के रास्ते में idle HTTP connection के चुपचाप बंद होने से बचने के लिए समय-समय पर probe भेजता है
  • default httpd TimeOut 60 इस्तेमाल करता है, जो input/output न होने की स्थिति 60 सेकंड तक रहने पर tunnel बंद कर देता है

SSH over HTTPS configuration

  • पता चला कि socat CONNECT method के जरिए HTTPS proxy support नहीं करता, केवल HTTP support करता है
  • इसके बजाय socat की TLS encapsulation capability इस्तेमाल की गई, और CONNECT-based request script में सीधे implement की गई
  • ~/.ssh/https-tunnel.bash इस flow में काम करता है
    • पहले CONNECT ssh-server:22 HTTP/1.1 header और Host: ssh-server output करता है
    • इसके बाद standard input को जस का तस आगे जोड़ता है
    • पूरा stream socat - "SSL:$3:$4" को pass किया जाता है, जिससे TLS connection बनता है
  • .ssh/config में Host ssh-via-https के लिए ProxyCommand ~/.ssh/https-tunnel.bash specify किया गया
  • $ ssh ssh-via-https चलाने पर उम्मीद के मुताबिक HTTPS tunnel के जरिए ssh-server से connection बनता है

संचालन के दौरान ध्यान देने वाली बातें

  • जिन environments में HTTPS व्यापक रूप से allow होता है, वहां बहुत restrictive intermediate equipment से होकर data भेजा जा सकता है
  • CONNECT method पुराने अवशेष जैसा दिख सकता है, लेकिन arbitrary TCP payload stream को TLS host stream के अंदर wrap करने में उपयोगी है
  • ServerAliveInterval तब OpenSSH connection बनाए रखने में मदद करता है जब lower transport layer idle connections के लिए अनुकूल नहीं होती
  • nginx configuration variant CONNECT passthrough on nginx में है

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

1 टिप्पणियां

 
GN⁺ 2023-12-25
Hacker News की राय

  • लेख में “HTTPS हर जगह मौजूद है, इसलिए बहुत सीमित middleboxes भी डेटा को गुजरने दे सकते हैं” वाला हिस्सा ही वह वजह है कि लगभग हर proprietary VPN protocol, यानी तथाकथित “SSL VPN”, HTTPS पर tunnel खोलने वाला mode implement करता है
    भले ही यह default behavior न हो, कम-से-कम इसे fallback path के रूप में रखते हैं, ताकि दुनिया भर के इंटरनेट पर लगभग किसी भी connection में काम करने वाला mode मिल सके
    मैं https://gitlab.com/openconnect/openconnect के मुख्य developers में से एक हूं, जो कई TLS-based VPN protocols implement करता है, और मैंने https://github.com/dlenski/what-vpn भी बनाया है, जो और अधिक TLS-based VPN server types को detect और identify करता है

    • यह अफसोसजनक है कि connection की उपयोगिता को मोटे तौर पर सीमित करने की कोशिशों की वजह से ports के मूल उद्देश्य के हिसाब से उनका इस्तेमाल करना मुश्किल हो जाता है

  • पहले Netherlands की इंटरनेट provider XS4ALL बिल्कुल यही feature देती थी
    वह port 80 पर SSH access खोलकर देती थी, और यात्रा के दौरान जब hotel WiFi ने port 80 के अलावा सब कुछ block कर दिया था, तब इसने कई बार मदद की

    • XS4ALL शानदार थी, और KPN ने उस brand को खत्म करने का फैसला किया, यह सच में अफसोस की बात है
      हालांकि KPN के नजरिए से, XS4ALL की hacker culture शायद शुरू से ही comfortable नहीं रही होगी
    • मैं XS4ALL user था; वह सच में बेहतरीन थी, और उसमें शुरुआती इंटरनेट की spirit जिंदा थी
      यह 1960s की pirate radio culture के दोबारा बनने जैसा लगता था
      https://en.wikipedia.org/wiki/Pirate_radio_in_Europe
    • SSH के non-standard ports में port 443 ऊपर की तरफ आता है
      https://www.shodan.io/search/facet?query=ssh&facet=port
      https://www.shodan.io/search/facet.png?query=ssh&facet=port
      इसके उलट port 80 काफी कम common है
    • मुझे पता नहीं था कि XS4ALL एक full-fledged internet provider थी
      मुझे याद है कि पहले मैं उसे सिर्फ newsgroup provider के रूप में इस्तेमाल करता था
    • XS4ALL कुछ हद तक Freedom के रूप में जारी है: https://freedom.nl/en

  • एक तीसरा विकल्प भी अक्सर होता है: किसी दूसरे host के port 80 या 443 पर SSH चलाकर, वहां से destination तक ProxyJump इस्तेमाल करना
    या उस host पर SOCKS खोलकर कुल मिलाकर कम-filtered इंटरनेट connection भी पाया जा सकता है
    मैं SOCKS इस्तेमाल करता हूं, और SSH connection के port forwarding से TLS-based DNS भी भेजता हूं
    कुछ साल पहले जब मैंने पहली बार SOCKS proxy setup किया और WiFi काफी इस्तेमाल किया, तो मुझे port check करने से आगे जाने वाली कोई जगह नहीं दिखी, लेकिन ऐसे devices मौजूद हैं और अब शायद ज्यादा common भी हों

    • हाई स्कूल के पहले साल में मैंने self-hosting अभी शुरू ही की थी; school ने websites तो block की थीं, लेकिन port blocking बिल्कुल नहीं की थी
      इसलिए मैंने बस अपने server पर SSH से connect किया और हमेशा की तरह इस्तेमाल किया
      बाद में जब मैंने Windows .iso files का archive बनाया, उन्हें laptop पर download किया और scp से server पर upload किया, तो शायद non-80/443 port पर upload और download मिलाकर दर्जनों GB traffic traffic inspection trigger करने के लिए काफी था, इसलिए दोपहर तक IT ने port 22 block कर दिया
      लेकिन उन्होंने बाकी ports block नहीं किए थे, इसलिए मैंने port forwarding में SSH को 443 पर move किया और इस्तेमाल जारी रखा
      उसके बाद school IT ने 443 पर SSH इस्तेमाल होते पकड़ लिया और 80/443 पर SSH block करने के लिए basic traffic analysis लगाया, लेकिन फिर भी बाकी सारे ports खुले थे
      आखिर में उन्होंने मेरे server को IP level पर block कर दिया, लेकिन बाकी सभी IP खुले थे
      VPS के जरिए ProxyJump इस्तेमाल करके bypass किया जा सकता था, लेकिन यह early college high school program था, इसलिए दूसरे साल के बाद मैं school में मुश्किल से जाता था, तो मेहनत करने लायक ज्यादा फायदा नहीं था
      अगली बार जाने पर मैं यह साबित करने के लिए try करने वाला हूं कि यह संभव है, और अगर वे सभी ports पर SSH block कर दें, तो VPS पर HTTPS over SSH चढ़ा दूंगा
      graduation के बाद guest WiFi पर क्या-क्या संभव है, यह फिर से देखने का सोच रहा हूं

  • थोड़ा खुले तौर पर promotion है, लेकिन Adaptive [1] में हम data security infrastructure बना रहे हैं
    हमारे एक product में SSH और कई दूसरे protocols को HTTP/3 के ऊपर forward किया जाता है, ताकि users एक single outbound port से databases, servers और अन्य resources से connect कर सकें
    Ngrok जैसी चीजों से मिलता-जुलता है, लेकिन self-host किया जा सकता है, और passwordless access या temporary credentials और maker-checker protection जोड़े जा सकते हैं
    [1] https://adaptive.live/

  • असल में openssh को सिर्फ port 443 पर listen करवाने से ही ज्यादातर firewalls bypass किए जा सकते थे

  • अच्छा है। अजीब बात है कि मैंने CONNECT method को forward proxy नहीं बल्कि reverse proxy की तरह कभी सोचा ही नहीं था
    हालांकि मेरे मामले में सिर्फ CONNECT काफी नहीं था, इसलिए company proxy को पार करने के लिए मैंने WebSocket के ऊपर SSH इस्तेमाल किया
    वह proxy custom CA से HTTPS connections inspect करती थी
    मैंने socat में बदलाव करके Apache के जरिए अपना SSH server WebSocket के रूप में expose किया, और client side पर इसे OpenSSH के ProxyCommand के साथ इस्तेमाल किया
    मैं सोचता रहता हूं कि वह patch upload करूं, लेकिन websocat जैसे दूसरे विकल्प भी हैं

    • इसलिए लगता है कि कई company proxies या firewalls WebSocket को default रूप से block करते हैं
    • सुनने में ऐसा लगता है जैसे आपने अनजाने में huproxy फिर से बना दिया

  • लगभग 20 साल पहले कंपनी के firewall में रास्ता निकालने के लिए मैंने ठीक यही काम करने वाला tool corkscrew[0] इस्तेमाल किया था
    standalone implementation और लेख साफ-सुथरे हैं
    0: https://github.com/bryanpkc/corkscrew

    • मेरी समझ के मुताबिक corkscrew सिर्फ खास conditions में काम करता है: आप HTTP proxy के पीछे हों, और वह HTTP proxy CONNECT method को support करता हो
      करीब 20 साल पहले एक छोटे contract काम के दौरान पहली condition थी, लेकिन दूसरी नहीं थी
      सौभाग्य से ऐसे मामलों में भी इस्तेमाल किए जा सकने वाले tools हैं, हालांकि server-side setup चाहिए
      https://github.com/larsbrinkhoff/httptunnel

  • कुल मिलाकर HTTP/2 के जरिए tunneling अच्छा विकल्प साबित होता है
    HTTP/2 के ऊपर बना remote procedure call protocol gRPC[1] है
    क्योंकि HTTP/2 एक ही TCP connection का उपयोग करके कई data structures को साथ-साथ भेजने और पाने वाली multiplexing में मजबूत है
    हालांकि QUIC खुद multiplexing देता है, इसलिए HTTP/3 इस्तेमाल करने की वजह शायद न हो
    आगे चलकर, क्योंकि middlebox बनाने वाले भेदभाव करना बंद नहीं कर पाएंगे, ज्यादातर communication encrypted HTTP/2 और QUIC के ऊपर चला जाएगा ऐसा लगता है
    active probing[2] को कम करने के लिए random, शायद AI-generated HTTP/2·HTTP/3 content serve करना पड़ सकता है
    [1] <https://grpc.io>
    [2] <https://blog.torproject.org/learning-more-about-gfws-active-...>

    • HTTP के ऊपर एक और remote procedure call protocol चढ़ाने की वजह मुझे ठीक से समझ नहीं आती
      HTTP खुद पहले से request/response protocol है, और मूल रूप से remote procedure calls के लिए इस्तेमाल किया जा सकता है
      HTTP 1, 2, 3 में से कोई भी हो, बड़ा फर्क नहीं दिखता
      उस protocol का evolution भी कुछ हद तक संदिग्ध है, और remote procedure call environment में जिन चीजों की जरूरत नहीं होती, उनका इस्तेमाल कराने के लिए design किया गया पहलू इसमें है
      मूल रूप से यह local service नहीं, बल्कि public internet के लिए design की गई चीज के ज्यादा करीब है
    • SSH के मामले में केवल एक single connection होता है, और असल में SSH अपनी multiplexing खुद implement करता है, इसलिए HTTP/2 का फायदा साफ नहीं दिखता
    • HTTP/2 अभी भी TCP है, इसलिए TCP head-of-line blocking झेलता है
      HTTP/3 QUIC के ऊपर चलता है

  • मैं इसके उलट SSH के ऊपर HTTP को ज्यादा पसंद करता हूं
    आधा मजाक है, लेकिन अच्छा होगा अगर browser में SSH जैसी identity management built-in हो
    public key HTTP authentication proposal hobo पहली बार पढ़कर मैं उत्साहित हुआ था, लेकिन पता चला कि न server implementation है और न browser client implementation
    JavaScript implementation है, लेकिन वह वह रूप नहीं था जो मैं चाहता था

    • ssh -D “*:8080” host
      यह command port 8080 पर SOCKS proxy चलाती है
      Firefox में मैं इसे हमेशा इस्तेमाल करता हूं, और यह original-style VPN की तरह काम करता है
      संदिग्ध use cases के लिए भी सुविधाजनक है, लेकिन AWS के private network में मौजूद rmq dashboard तक पहुंचने के लिए भी इस्तेमाल करता हूं
    • HTTPS client certificate कैसा रहेगा?
      https://techcommunity.microsoft.com/t5/iis-support-blog/clie...
      जरूरतों पर फिट बैठता है या नहीं, इतना detail में नहीं जानता, लेकिन university के समय server authentication के लिए इसे इस्तेमाल किया था
    • क्या आप passkey की बात नहीं कर रहे?
    • काश browser में ssh://google.com संभव होता
    • अगर पिछले हफ्ते छूट गया हो, तो इसी दिशा में एक लेख था: SSH3, HTTP/3 और QUIC इस्तेमाल करने वाला SSHv2
      https://news.ycombinator.com/item?id=38664729

  • sslh को प्यार क्यों नहीं मिलता?
    यह HTTP, TLS/SSL(SNI और ALPN सहित), SSH, OpenVPN, tinc, XMPP, SOCKS5 को detect करता है, और regex से जांचे जा सकने वाले दूसरे protocols को भी पहचान सकता है
    classic use case port 443 पर कई services को साथ में serve करना है
    उदाहरण के लिए, company firewall के अंदर से SSH से connect करते हुए भी उसी port पर HTTPS लगातार serve कर सकते हैं
    https://www.rutschle.net/tech/sslh/README.html

    • लेख का शुरुआती आधा हिस्सा sslh और पूरी encapsulation में से क्या चुनना है, इस पर था
      पूरी encapsulation चुनने की वजह शायद यह थी कि configure करने वाली एक service कम हो जाती है, HTTP server connection handle करता है इसलिए logs में remote address सही रहता है, और शायद hacker spirit के हिसाब से existing solution से ज्यादा नया solution पसंद आता है