
तेज़, सुरक्षित शेल प्रोटोकॉल जो HTTP/3, QUIC, और TLS 1.3 पर निर्मित है। OAuth2, OpenID Connect, और पारंपरिक SSH प्रमाणीकरण का समर्थन करता है, UDP पोर्ट फ़ॉरवर्डिंग और छिपी सर्वर क्षमताओं के साथ।
[!NOTE] SSH3 संभवतः अपना नाम बदलने वाला है। यह अभी भी HTTP/3 Extended connect के ऊपर चलने वाला SSH कनेक्शन प्रोटोकॉल (RFC4254) है, लेकिन आवश्यक परिवर्तन भारी हैं और लोकप्रिय SSH कार्यान्वयनों के दर्शन से बहुत दूर हैं जिन्हें एकीकरण के लिए माना जा सके। विनिर्देश मसौदा का नाम पहले ही बदल दिया गया है ("Remote Terminals over HTTP/3"), लेकिन हमें एक अच्छा स्थायी नाम लाने में कुछ समय चाहिए।
SSH3, SSH प्रोटोकॉल का एक पूर्ण पुनरीक्षण है, जो इसके अर्थशास्त्र को HTTP तंत्र के शीर्ष पर मैप करता है। यह हमारे शोध कार्य से आया है और हम (शोधकर्ताओं) ने हाल ही में इसे एक इंटरनेट-ड्राफ्ट (draft-michel-remote-terminal-http3-00) के रूप में प्रस्तावित किया है।
संक्षेप में, SSH3 सुरक्षित चैनल स्थापना के लिए QUIC+TLS1.3 और उपयोगकर्ता प्रमाणीकरण के लिए HTTP प्राधिकरण तंत्र का उपयोग करता है। अन्य बातों के अलावा, SSH3 निम्नलिखित सुधारों की अनुमति देता है:
[!TIP] जल्दी से शुरू करना चाहते हैं? SSH3 स्थापित करना देखें। आप SSH3 सर्वर सेटअप करना और SSH3 क्लाइंट का उपयोग करना सीखेंगे।
सत्र स्थापना के लिए तेज़, थ्रूपुट के लिए नहीं! SSH3, SSHv2 की तुलना में काफी तेज़ सत्र स्थापना प्रदान करता है। SSHv2 के साथ एक नया सत्र स्थापित करने में 5 से 7 नेटवर्क राउंड-ट्रिप समय लग सकता है, जिसे उपयोगकर्ता आसानी से नोटिस कर सकता है। SSH3 को केवल 3 राउंड-ट्रिप समय की आवश्यकता होती है। चल रहे सत्र में कीस्ट्रोक विलंबता अपरिवर्तित रहती है।
SSH3 (ऊपर) बनाम SSHv2 (नीचे) सर्वर की ओर 100ms पिंग के साथ सत्र स्थापना।
जहाँ SSHv2 उपयोगकर्ता प्रमाणीकरण और सुरक्षित चैनल स्थापना के लिए अपने स्वयं के प्रोटोकॉल को परिभाषित करता है, वहीं SSH3 TLS 1.3, QUIC और HTTP के मजबूत और समय-परीक्षित तंत्रों पर निर्भर करता है। इन प्रोटोकॉल का उपयोग पहले से ही इंटरनेट पर ई-कॉमर्स और इंटरनेट बैंकिंग जैसे सुरक्षा-महत्वपूर्ण अनुप्रयोगों को सुरक्षित करने के लिए बड़े पैमाने पर किया जाता है।
SSH3 पहले से ही सामान्य पासवर्ड-आधारित और पब्लिक-की (RSA और EdDSA/ed25519) प्रमाणीकरण विधियों को लागू करता है। यह OAuth 2.0 जैसी नई प्रमाणीकरण विधियों का भी समर्थन करता है और आपको अपने Google/Microsoft/Github खातों का उपयोग करके अपने सर्वर में लॉग इन करने की अनुमति देता है।
जबकि SSH3 तेज़ सत्र स्थापना के लिए वादा दिखाता है, यह अभी भी एक प्रारंभिक प्रूफ-ऑफ-कॉन्सेप्ट चरण में है। किसी भी नए जटिल प्रोटोकॉल की तरह, उचित सुरक्षा निष्कर्ष निकालने से पहले एक विस्तारित समय सीमा में विशेषज्ञ क्रिप्टोग्राफ़िक समीक्षा आवश्यक है।
हम SSH3 को एक ओपन सोर्स प्रोजेक्ट के रूप में विकसित कर रहे हैं ताकि सामुदायिक प्रतिक्रिया और विश्लेषण को सुविधाजनक बनाया जा सके। हालाँकि, आगे की सहकर्मी समीक्षा के बिना हम अभी तक उत्पादन प्रणालियों के लिए इसकी उपयुक्तता का समर्थन नहीं कर सकते। यदि आपके पास प्रासंगिक विशेषज्ञता है तो कृपया हमारे साथ सहयोग करें!
वर्तमान प्रोटोटाइप स्थिति को देखते हुए, हम सैंडबॉक्स वातावरण या निजी नेटवर्क में SSH3 का परीक्षण करने की सलाह देते हैं। ध्यान रखें कि प्रयोगात्मक सर्वरों को सीधे इंटरनेट-सुलभ बनाने से पूरी तरह से सुरक्षा जांच से पहले जोखिम उत्पन्न हो सकता है।
जबकि गुप्त पथों के पीछे सर्वरों को छिपाने के संभावित लाभ हैं, यह उत्पादन में जाने से पहले कठोर भेद्यता विश्लेषण की आवश्यकता को नकारता नहीं है। हम SSH3 की भविष्य की संभावनाओं के बारे में उत्साहित हैं लेकिन पहले अतिरिक्त जांच को प्रोत्साहित करते हैं।
SSH3 का उपयोग करके, आप अपने SSH सर्वर के विरुद्ध स्कैनिंग और डिक्शनरी हमलों के सामान्य तनाव से बच सकते हैं। आपके गुप्त Google ड्राइव दस्तावेज़ों की तरह, आपके SSH3 सर्वर को एक गुप्त लिंक के पीछे छिपाया जा सकता है और केवल उन प्रमाणीकरण प्रयासों का उत्तर दे सकता है जिन्होंने इस विशिष्ट लिंक पर HTTP अनुरोध किया है, जैसे:
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
<my-long-secret> को, मान लीजिए, यादृच्छिक मान M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU से बदलकर, आपका SSH3 सर्वर केवल URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU पर किए गए SSH3 कनेक्शन प्रयासों का उत्तर देगा और अन्य अनुरोधों पर 404 Not Found का उत्तर देगा। इसलिए इंटरनेट पर हमलावर और क्रॉलर आपके SSH3 सर्वर की उपस्थिति का पता नहीं लगा सकते। वे केवल एक साधारण वेब सर्वर देखेंगे जो प्रत्येक अनुरोध पर 404 स्थिति कोड का उत्तर देता है।
ध्यान दें: अपने SSH3 सर्वर को एक गुप्त URL के पीछे रखने से स्कैनिंग हमलों के प्रभाव को कम किया जा सकता है लेकिन यह शास्त्रीय प्रमाणीकरण तंत्रों को कभी भी प्रतिस्थापित नहीं करेगा और न ही करना चाहिए। गुप्त लिंक का उपयोग केवल आपके होस्ट को खोजे जाने से बचाने के लिए किया जाना चाहिए। गुप्त URL जानने से किसी को आपके सर्वर तक पहुंच नहीं मिलनी चाहिए। अपने सर्वर को सुरक्षित रखने के लिए ऊपर वर्णित शास्त्रीय प्रमाणीकरण तंत्रों का उपयोग करें।
SSH3 नई सुविधाएँ प्रदान करता है जो SSHv2 प्रोटोकॉल द्वारा प्रदान नहीं की जा सकती थीं।
यह SSH3 कार्यान्वयन पहले से ही OpenSSH की कई लोकप्रिय सुविधाएँ प्रदान करता है, इसलिए यदि आप OpenSSH के आदी हैं, तो SSH3 को अपनाने की प्रक्रिया सहज होगी। यहाँ कुछ OpenSSH सुविधाओं की सूची दी गई है जिन्हें SSH3 भी लागू करता है:
~/.ssh/authorized_keys को पार्स करता हैknown_hosts तंत्रssh-agent का उपयोग करना-proxy-jump पैरामीटर देखें)। यदि A एक SSH3 क्लाइंट है और B और C दोनों SSH3 सर्वर हैं, तो आप B को गेटवे/प्रॉक्सी के रूप में उपयोग करके A से C से कनेक्ट हो सकते हैं। प्रॉक्सी A से C तक QUIC पैकेट को फ़ॉरवर्ड करने के लिए UDP फ़ॉरवर्डिंग का उपयोग करता है, इसलिए B A<->C SSH3 ट्रैफ़िक को डिक्रिप्ट नहीं कर सकता है।~/.ssh/config को पार्स करता है और Hostname, User, Port और IdentityFile कॉन्फ़िग विकल्पों को संभालता है (अन्य विकल्प वर्तमान में अनदेखा किए जाते हैं)। साथ ही एक नया UDPProxyJump पार्स करता है जो OpenSSH के ProxyJump के समान व्यवहार करता है।हमें SSH3 को जिम्मेदारी से आगे बढ़ाने में मदद करें! हम सक्षम सुरक्षा शोधकर्ताओं को हमारे कोडबेस की समीक्षा करने और प्रतिक्रिया प्रदान करने के लिए आमंत्रित करते हैं। कृपया हमें प्रासंगिक मानक निकायों से भी जोड़ें ताकि समय के साथ औपचारिक IETF/IRTF प्रक्रियाओं के माध्यम से SSH3 को आगे बढ़ाया जा सके।
सहयोगात्मक सहायता से, हम उम्मीद करते हैं कि SSH3 को सुरक्षित उत्पादन तत्परता की ओर पुनरावृत्तीय रूप से सुधारेंगे। लेकिन हम व्यापक विशेषज्ञ क्रिप्टोग्राफ़िक समीक्षा और सम्मानित सुरक्षा प्राधिकरणों द्वारा अपनाए जाने के साक्ष्य के बिना निश्चित सुरक्षा दावे नहीं कर सकते। आइए SSH3 की संभावनाओं को साकार करने के लिए मिलकर काम करें!
आप या तो नवीनतम रिलीज़ बाइनरी डाउनलोड कर सकते हैं,
go install का उपयोग करके स्थापित कर सकते हैं या स्रोत से कोड संकलित करके स्वयं ये बाइनरी उत्पन्न कर सकते हैं।
[!TIP] SSH3 अभी भी प्रायोगिक है और एक शोध कार्य का फल है। यदि आप सार्वजनिक रूप से एक नया SSH3 सर्वर तैनात करने से डरते हैं, तो आप इसे एक गुप्त URL के पीछे छिपाने के लिए SSH3 की गुप्त पथ सुविधा का उपयोग कर सकते हैं।
go install github.com/francoismichel/ssh3/cmd/...@latest
आपको ऐसा करने के लिए एक हालिया Golang संस्करण की आवश्यकता है। स्रोत कोड डाउनलोड करना और बाइनरी संकलित करना निम्नलिखित चरणों के साथ किया जा सकता है:
git clone https://github.com/francoismichel/ssh3 # रेपो क्लोन करें
cd ssh3
go build -o ssh3 cmd/ssh3/main.go # क्लाइंट बनाएं
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go # सर्वर बनाएं, gcc स्थापित होना आवश्यक है
यदि आपके पास रूट/सुडो विशेषाधिकार हैं और आप ssh3 को सभी उपयोगकर्ताओं के लिए सुलभ बनाना चाहते हैं,
तो आप सीधे बाइनरी को /usr/bin में कॉपी कर सकते हैं:
cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin
अन्यथा, आप अपने .bashrc या समकक्ष के अंत में निम्नलिखित पंक्ति जोड़कर निष्पादन योग्य को अपने PATH पर्यावरण चर में जोड़ सकते हैं:
export PATH=$PATH:/path/to/the/ssh3/directory
अपने होस्ट से कनेक्ट करने से पहले, आपको उस पर एक SSH3 सर्वर तैनात करना होगा। वर्तमान में कोई SSH3 डेमॉन नहीं है, इसलिए अभी आपको screen या समान उपयोगिता का उपयोग करके पृष्ठभूमि में ssh3-server निष्पादन योग्य चलाना होगा।
[!NOTE] चूँकि SSH3 HTTP/3 के शीर्ष पर चलता है, एक सर्वर को एक X.509 प्रमाणपत्र और उसकी संबंधित निजी कुंजी की आवश्यकता होती है। सार्वजनिक प्रमाणपत्र सर्वर पर
-generate-public-certकमांड-लाइन तर्क का उपयोग करके Let's Encrypt के माध्यम से आपके सार्वजनिक डोमेन नाम के लिए स्वचालित रूप से उत्पन्न किए जा सकते हैं। यदि आप वास्तविक प्रमाणपत्र प्राधिकरण द्वारा हस्ताक्षरित प्रमाणपत्र उत्पन्न नहीं करना चाहते हैं या यदि आपके पास कोई सार्वजनिक डोमेन नाम नहीं है, तो आप-generate-selfsigned-certकमांड-लाइन तर्क का उपयोग करके एक स्व-हस्ताक्षरित प्रमाणपत्र उत्पन्न कर सकते हैं। स्व-हस्ताक्षरित प्रमाणपत्र आपको SSHv2 के होस्ट कुंजी तंत्र के समान सुरक्षा गारंटी प्रदान करते हैं, उसी सुरक्षा समस्या के साथ: आप अपने सर्वर से अपने पहले कनेक्शन के दौरान मशीन-इन-द-मिडिल हमलों के प्रति संवेदनशील हो सकते हैं। Let's Encrypt जैसे सार्वजनिक प्रमाणपत्र प्राधिकरणों द्वारा हस्ताक्षरित वास्तविक प्रमाणपत्रों का उपयोग इस समस्या से बचाता है।
यहाँ ssh3-server निष्पादन योग्य का उपयोग है:
Usage of ./ssh3-server:
-bind string
सुनने के लिए पता:पोर्ट जोड़ी, जैसे 0.0.0.0:443 (default "[::]:443")
-cert string
सर्वर प्रमाणपत्र (या फुलचेन) का फ़ाइल नाम (default "./cert.pem")
-key string
प्रमाणपत्र निजी कुंजी का फ़ाइल नाम (default "./priv.key")
-enable-password-login
यदि सेट किया जाता है, तो पासवर्ड प्रमाणीकरण सक्षम करें (डिफ़ॉल्ट रूप से अक्षम)
-generate-public-cert value
प्रदान किए गए डोमेन नाम के लिए Let's Encrypt का उपयोग करके स्वचालित रूप से एक वैध सार्वजनिक प्रमाणपत्र उत्पन्न और उपयोग करें। फ़्लैग का उपयोग कई प्रमाणपत्र उत्पन्न करने के लिए कई बार किया जा सकता है। यदि पहले इस फ़्लैग का उपयोग करके प्रमाणपत्र उत्पन्न किए गए हैं, तो उन्हें पुन: उत्पन्न किए बिना पुन: उपयोग किया जाएगा। सर्वर चलने पर सार्वजनिक प्रमाणपत्र स्वचालित रूप से नवीनीकृत हो जाते हैं। स्वचालित रूप से उत्पन्न आईपी सार्वजनिक प्रमाणपत्र अभी तक उपलब्ध नहीं हैं।
-generate-selfsigned-cert
यदि सेट किया जाता है, तो एक स्व-हस्ताक्षरित प्रमाणपत्र और कुंजी उत्पन्न करता है जो -cert और -key तर्कों द्वारा इंगित पथों पर संग्रहीत की जाएगी (उनका पहले से मौजूद नहीं होना चाहिए)
-url-path string
गुप्त URL पथ जिस पर ssh3 सर्वर सुनता है (default "/ssh3-term")
-v वर्बोज़ मोड, यदि सेट किया जाता है
-version
यदि सेट किया जाता है, तो मानक आउटपुट पर सॉफ़्टवेयर संस्करण प्रदर्शित करता है और बाहर निकलता है
निम्नलिखित कमांड डोमेन my-domain.example.org के लिए एक वैध Let's Encrypt सार्वजनिक प्रमाणपत्र के साथ पोर्ट 443 पर एक सार्वजनिक SSH3 सर्वर शुरू करता है और /ssh3 URL पथ पूछने वाले नए सत्र अनुरोधों का उत्तर देता है:
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
यदि आपके पास सार्वजनिक डोमेन नाम नहीं है (अर्थात केवल एक आईपी पता), तो आप या तो -cert और -key तर्कों का उपयोग करके अपने आईपी पते के लिए मौजूदा प्रमाणपत्र का उपयोग कर सकते हैं या -generate-selfsigned-cert तर्क का उपयोग करके स्व-हस्ताक्षरित प्रमाणपत्र उत्पन्न कर सकते हैं।
यदि आपके पास मौजूदा प्रमाणपत्र और कुंजियाँ हैं, तो आप उनका उपयोग करने के लिए सर्वर को निम्नानुसार चला सकते हैं:
ssh3-server -cert /path/to/cert/or/fullchain -key /path/to/cert/private/key -url-path /ssh3
[!NOTE] OpenSSH के समान, अन्य उपयोगकर्ताओं के रूप में लॉग इन करने के लिए सर्वर को रूट विशेषाधिकारों के साथ चलाया जाना चाहिए।
डिफ़ॉल्ट रूप से, SSH3 सर्वर प्रत्येक उपयोगकर्ता के लिए ~/.ssh/authorized_keys और ~/.ssh3/authorized_identities फ़ाइलों में पहचान की तलाश करेगा।
~/.ssh3/authorized_identities नई पहचान जैसे कि OpenID Connect (oidc) की अनुमति देता है जिसकी चर्चा नीचे की गई है।
लोकप्रिय कुंजी प्रकार जैसे rsa, ed25519 और OpenSSH प्रारूप में कुंजियों का उपयोग किया जा सकता है।
एक बार जब आपके पास SSH3 सर्वर चल रहा हो, तो आप अपने शास्त्रीय SSHv2 टूल की तरह SSH3 क्लाइंट का उपयोग करके इससे कनेक्ट हो सकते हैं।
यहाँ ssh3 निष्पादन योग्य का उपयोग है:
Usage of ssh3:
-pubkey-for-agent string
यदि सेट किया जाता है, तो एक एजेंट कुंजी का उपयोग करें जिसकी सार्वजनिक कुंजी निर्दिष्ट पथ में मौजूद से मेल खाती हो
-privkey string
निजी कुंजी फ़ाइल
-use-password
यदि सेट किया जाता है, तो शास्त्रीय पासवर्ड प्रमाणीकरण करें
-forward-agent
यदि सेट किया जाता है, तो रिमोट होस्ट पर sshv2 कनेक्शन के साथ उपयोग करने के लिए ssh एजेंट को फ़ॉरवर्ड करता है
-forward-tcp string
यदि सेट किया जाता है, तो localport/remoteip@remoteport लेते हुए localhost@localport को remoteip@remoteport की ओर फ़ॉरवर्ड करता है
-forward-udp string
यदि सेट किया जाता है, तो localport/remoteip@remoteport लेते हुए localhost@localport को remoteip@remoteport की ओर फ़ॉरवर्ड करता है
-proxy-jump string
यदि सेट किया जाता है, तो निर्दिष्ट रिमोट होस्ट को प्रॉक्सी के रूप में उपयोग करके प्रॉक्सी जंप करता है
-insecure
यदि सेट किया जाता है, तो सर्वर प्रमाणपत्र सत्यापन छोड़ें
-keylog string
QUIC TLS कुंजियाँ और मास्टर सीक्रेट को निर्दिष्ट keylog फ़ाइल में लिखें: केवल डीबगिंग उद्देश्य के लिए
-use-oidc string
यदि सेट किया जाता है, तो पैरामीटर के रूप में निर्दिष्ट जारीकर्ता url के साथ OpenID Connect का उपयोग करने के लिए बाध्य करें
-oidc-config string
OpenID Connect json कॉन्फ़िग फ़ाइल जिसमें अधिकांश पहचान प्रदाताओं के लिए आवश्यक "client_id" और "client_secret" फ़ील्ड हैं
-do-pkce
यदि सेट किया जाता है, तो oidc के साथ PKCE चुनौती-प्रतिक्रिया करें
-v यदि सेट किया जाता है, तो वर्बोज़ मोड सक्षम करें
आप निम्नलिखित कमांड का उपयोग करके ~/.ssh/id_rsa में स्थित निजी कुंजी का उपयोग करके /my-secret-path पर सुन रहे my-server.example.org पर अपने SSH3 सर्वर से कनेक्ट हो सकते हैं:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
SSH3 क्लाइंट OpenSSH एजेंट के साथ काम करता है और इस एजेंट के साथ संचार करने के लिए शास्त्रीय SSH_AUTH_SOCK पर्यावरण चर का उपयोग करता है।
OpenSSH के समान, SSH3 एजेंट द्वारा प्रदान की गई कुंजियों को सूचीबद्ध करेगा और डिफ़ॉल्ट रूप से एजेंट द्वारा सूचीबद्ध पहली कुंजी का उपयोग करके कनेक्ट होगा।
यदि आप एजेंट के साथ उपयोग करने के लिए एक विशिष्ट कुंजी निर्दिष्ट करना चाहते हैं, तो आप या तो ऊपर की तरह -privkey तर्क के साथ सीधे निजी कुंजी निर्दिष्ट कर सकते हैं, या -pubkey-for-agent तर्क का उपयोग करके संबंधित सार्वजनिक कुंजी निर्दिष्ट कर सकते हैं। यह आपको उन स्थितियों में प्रमाणित करने की अनुमति देता है जहाँ केवल एजेंट के पास निजी कुंजी तक सीधी पहुंच है लेकिन आपके पास केवल सार्वजनिक कुंजी तक पहुंच है।
जबकि हतोत्साहित किया जाता है, आप निम्नलिखित कमांड का उपयोग करके अपने सर्वर से पासवर्ड का उपयोग करके कनेक्ट हो सकते हैं (यदि ssh3-server पर स्पष्ट रूप से सक्षम किया गया है):
ssh3 -use-password [email protected]/my-secret-path
ssh3 आपके OpenSSH कॉन्फ़िग को पार्स करता है। वर्तमान में, यह केवल Hostname; User, Port और IdentityFile OpenSSH विकल्पों को संभालता है।
यह केवल SSH3 द्वारा उपयोग किए जाने वाले नए विकल्प भी जोड़ता है, जैसे URLPath या UDPProxyJump। URLPath आपको अपने SSH3 कमांड में गुप्त URL पथ को छोड़ने की अनुमति देता है। UDPProxyJump आपको SSH3 (#proxy-jump)[प्रॉक्सी जंप] करने की अनुमति देता है और इसका -proxy-jump कमांड-लाइन तर्क के समान अर्थ है।
मान लीजिए कि आपके ~/.ssh/config में निम्नलिखित पंक्तियाँ हैं:
IgnoreUnknown URLPath
Host my-server
HostName 192.0.2.0
User username
IdentityFile ~/.ssh/id_rsa
URLPath /my-secret-path
OpenSSH की तरह, निम्नलिखित ssh3 कमांड आपको 192.0.2.0 पर UDP पोर्ट 443 पर चल रहे SSH3 सर्वर से .ssh/id_rsa में स्थित निजी कुंजी का उपयोग करके पब्लिक कुंजी प्रमाणीकरण के साथ जोड़ेगा:
ssh3 my-server/my-secret-path
यदि आप SSH3 का कॉन्फ़िग-आधारित उपयोग नहीं चाहते हैं, तो आप ssh3 के CLI पैरामीटर का उपयोग करने का तरीका जानने के लिए नीचे दिए गए अनुभाग पढ़ सकते हैं।
यह सुविधा आपको किसी बाहरी पहचान प्रदाता जैसे आपकी कंपनी के प्रदाता या किसी अन्य प्रदाता का उपयोग करके कनेक्ट करने की अनुमति देती है जो OpenID Connect मानक को लागू करता है, जैसे Google Identity, Github या Microsoft Entra। प्रमाणीकरण प्रवाह नीचे GIF में दिखाया गया है।
Google खाते का उपयोग करके निजी कुंजी के बिना सुरक्षित कनेक्शन।
यह आपके पहचान प्रदाता से कैसे जुड़ता है, यह ~/.ssh3/oidc_config.json नामक फ़ाइल में कॉन्फ़िगर किया गया है।
नीचे Google खाते के साथ उपयोग के लिए एक उदाहरण config.json फ़ाइल है। यह कॉन्फ़िगरेशन फ़ाइल एक सरणी है और इसमें कई पहचान प्रदाता कॉन्फ़िगरेशन हो सकते हैं।
[
{
"issuer_url": "https://accounts.google.com",
"client_id": "<your_client_id>",
"client_secret": "<your_client_secret>"
}
]
यह भविष्य में बदल सकता है, लेकिन वर्तमान में, इस सुविधा को अपने Google खाते के साथ काम करने के लिए, आपको अपने Google Cloud कंसोल में एक नया प्रायोगिक एप्लिकेशन सेट करना होगा और अपने ईमेल को अधिकृत उपयोगकर्ताओं के रूप में जोड़ना होगा।
यह आपको एक client_id और एक client_secret प्रदान करेगा जिसे आप अपने ~/.ssh3/oidc_config.json में सेट कर सकते हैं। सर्वर की ओर, आपको बस अपने ~/.ssh3/authorized_identities में निम्नलिखित पंक्ति जोड़नी होगी:
oidc <client_id> https://accounts.google.com <email>
हम वर्तमान में भविष्य में authorized_identities फ़ाइल में client_id सेट करने की आवश्यकता को हटाने पर विचार कर रहे हैं।
अक्सर ऐसा होता है कि कुछ SSH होस्ट केवल गेटवे के माध्यम से ही पहुँचा जा सकता है। SSH3 आपको OpenSSH द्वारा प्रस्तावित के समान प्रॉक्सी जंप करने की अनुमति देता है। आप B को गेटवे/प्रॉक्सी के रूप में उपयोग करके A से C से कनेक्ट हो सकते हैं। B और C दोनों पर एक मान्य SSH3 सर्वर चल रहा होना चाहिए। यह B पर UDP पोर्ट फ़ॉरवर्डिंग स्थापित करके A से C तक QUIC पैकेट को फ़ॉरवर्ड करने के लिए काम करता है। इसलिए A से C तक का कनेक्शन पूरी तरह से एंड-टू-एंड है और B A और C के बीच SSH3 ट्रैफ़िक को डिक्रिप्ट या बदल नहीं सकता है।