USSH

USSH एक शेल प्रोटोकॉल और क्लाइंट/सर्वर जोड़ी है जो USTP-Secure के ऊपर बनाई गई है।

यह TCP टनल नहीं है और SSH को TCP के अंदर रैप नहीं करता है।

स्थिति: बीटा

लाइसेंस: MIT

AEAD सिफर नाम

• chacha20 = CHACHA20_POLY1305
• aes-256-gcm = AES_256_GCM
• aes-128-gcm = AES_128_GCM
• डिफ़ॉल्ट AEAD सिफर: chacha20

डिफ़ॉल्ट पोर्ट

• 5322

सर्वर

python3 ussh_server.py \
  --peer-ip <CLIENT_IP_OR_DOMAIN> \
  --peer-port 0 \
  --bind-ip 0.0.0.0 \
  --bind-port 5322 \
  --cipher chacha20 \
  --congestion-control auto

यदि --password छोड़ दिया गया है, तो सर्वर स्टार्टअप पर USSH लॉगिन पासवर्ड के लिए संकेत देता है।

इंटरैक्टिव स्टार्टअप पर, सर्वर पूछता है कि क्या उसे खुद को systemd सेवा के रूप में स्थापित करना चाहिए। इसे सामान्य रूप से चलाने के लिए n उत्तर दें। उस प्रश्न को छोड़ने के लिए --no-systemd-prompt का उपयोग करें।

क्लाइंट

python3 ussh_client.py \
  --peer-ip <SERVER_IP_OR_DOMAIN> \
  --peer-port 5322 \
  --bind-ip 0.0.0.0 \
  --bind-port 0 \
  --cipher chacha20 \
  --congestion-control off \
  --cleartext off

क्लाइंट SSH की तरह पासवर्ड के लिए इंटरैक्टिव रूप से संकेत देता है।

क्लाइंट पहली बार देखी गई सर्वर X25519 सार्वजनिक कुंजी को ~/.ussh_known_hosts.json में संग्रहीत करता है। यदि वह कुंजी बाद में बदलती है, तो क्लाइंट नई कुंजी पर चुपचाप भरोसा करने के बजाय TOFU बेमेल त्रुटि के साथ रुक जाता है। यदि आपने जानबूझकर सर्वर होस्ट कुंजी को घुमाया है, तो इंटरैक्टिव पुष्टि के बाद संग्रहीत TOFU कुंजी को बदलने की अनुमति देने के लिए क्लाइंट को --regen-key के साथ चलाएं।

इंटरनेट-ड्राफ्ट

• USSH इंटरनेट-ड्राफ्ट: https://datatracker.ietf.org/doc/draft-x1co-ussh/

नोट्स

• ट्रांसपोर्ट UDP पर USTP-Secure है।
• USSH प्रति-पैकेट HMAC अखंडता के साथ वैकल्पिक क्लियरटेक्स्ट DATA मोड का भी समर्थन करता है:
  • सर्वर पक्ष: --cleartext auto|on|off
  • क्लाइंट पक्ष: --cleartext on|off
  • सर्वर auto के साथ, USSH क्लाइंट अनुरोध का पालन करता है।
  • सर्वर on या off के साथ, सर्वर अंतिम क्लियरटेक्स्ट मोड को बाध्य करता है।
  • जब --cleartext on का उपयोग किया जाता है, तो USSH एक चेतावनी प्रिंट करता है कि क्लियरटेक्स्ट वास्तविक इंटरनेट पर खतरनाक है और केवल नियंत्रित वातावरण जैसे स्थानीय नेटवर्क में अनुशंसित है।
• USSH के नीचे, USTPS पठनीय ASCII नियंत्रण लाइनों का उपयोग करता है जैसे ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, साथ ही बाइनरी UPACK (UPAK) DATA फ्रेम।
• ACK और NACK डिबगेबिलिटी के लिए प्लेनटेक्स्ट रहते हैं, लेकिन वे नकली ACK/NACK नियंत्रण हमलों को रोकने के लिए प्रति-सत्र HMAC टैग के साथ प्रमाणित होते हैं।
• सामान्य मोड में, DATA पेलोड AEAD एन्क्रिप्शन का उपयोग करते हैं।
• क्लियरटेक्स्ट मोड में, DATA पेलोड एन्क्रिप्टेड नहीं होते हैं, लेकिन वे अभी भी एक HMAC रखते हैं ताकि कोई तीसरा पक्ष बिना पहचाने उन्हें संशोधित न कर सके।
• USSH प्रति UPACK DATA पेलोड के 900 बाइट्स की USTPS ट्रांसपोर्ट पेलोड सीमा विरासत में लेता है।
• USSH USTPS के नीचे दूसरी फ्रैगमेंटेशन परत को परिभाषित नहीं करता है।
• ट्रांसपोर्ट-स्तरीय MTU, PMTU, नॉनस व्यवहार, डुप्लिकेट हैंडलिंग, और स्टेल-पैकेट हैंडलिंग USTPS से विरासत में मिली हैं।
• स्वचालित नेटवर्क/पथ माइग्रेशन हटा दिया गया है।
• यदि क्लाइंट नेटवर्क बदलता है और उसका स्रोत IP:port बदलता है, तो वर्तमान USSH सत्र बंद होने की उम्मीद है और उपयोगकर्ता को साफ-सुथरे तरीके से फिर से कनेक्ट करना चाहिए।
• माइग्रेशन कार्यान्वयन हटा दिया गया था क्योंकि इससे व्यावहारिक विश्वसनीयता और सुरक्षा समस्याएं उत्पन्न हुईं:
  • जब NAT या मोबाइल नेटवर्क तेजी से पथ बदलते थे तो बार-बार माइग्रेशन बाढ़ आती थी
  • सत्र जो पुनर्प्राप्त दिखते थे लेकिन टर्मिनल डेटा वितरित करना बंद कर देते थे
  • क्लाइंट को पथ के मृत होने का पता चलने से पहले लंबी मौन अवधि
  • वास्तविक रोमिंग क्लाइंट और मौजूदा सत्र का दावा करने वाले स्पूफ किए गए पैकेट के बीच अस्पष्टता
  • पुनर्प्राप्ति स्थिति जो टर्मिनल को साफ-सुथरे तरीके से फिर से कनेक्ट करने के बजाय अटका सकती थी
• वर्तमान व्यवहार जानबूझकर सरल है: वर्तमान IP:port पर क्लाइंट को सत्यापित करें, सत्र को उस एंडपॉइंट से बांधें, और यदि एंडपॉइंट बदलता है तो फिर से कनेक्ट करें।
• USSH ट्रांसपोर्ट से वैकल्पिक USTPS कंजेशन विरासत में लेता है।
• सर्वर पक्ष: --congestion-control auto|on|off
• क्लाइंट पक्ष: --congestion-control on|off
• सर्वर auto के साथ, USSH क्लाइंट अनुरोध का पालन करता है। सर्वर on या off के साथ, सर्वर अंतिम मोड को बाध्य करता है।
• USTP-Secure स्वयं अक्रमित रहता है।
• USSH ट्रांसपोर्ट को ऑर्डर किए गए TCP-जैसे चैनल में नहीं बदलता है।
• USSH टर्मिनल पर लिखने से पहले केवल तार्किक stdout बाइट स्ट्रीम को फिर से जोड़ता है।
• USSH शेल इनपुट/आउटपुट चंक्स के लिए एप्लिकेशन-स्तरीय ऑर्डरिंग भी बनाए रख सकता है जहां एक PTY सुसंगत बाइट-स्ट्रीम व्यवहार की अपेक्षा करता है।
• वह पुनःसंयोजन मौजूद है क्योंकि इंटरैक्टिव शेल आउटपुट एक निरंतर बाइट स्ट्रीम है, और टर्मिनल बाइट्स को कच्चे आगमन क्रम में प्रस्तुत करना ls, find, या कंपाइलर लॉग जैसे बड़े आउटपुट को दूषित कर सकता है।
• इसका मतलब है कि USTP-Secure अभी भी ट्रांसपोर्ट-स्तरीय हेड-ऑफ-लाइन ब्लॉकिंग से बचता है, जबकि USSH केवल टर्मिनल रेंडरिंग के लिए आवश्यक एप्लिकेशन-स्तरीय ऑर्डर को पुनर्स्थापित करता है।
• पेलोड प्रति पैकेट AEAD के साथ एन्क्रिप्टेड होते हैं।
• कोई स्थिर PSK उपयोग नहीं किया जाता है।
• प्रत्येक क्लाइंट को X25519 के माध्यम से एक अलग अस्थायी AEAD सत्र कुंजी प्राप्त होती है।
• सुरक्षित सत्र स्थापित होने के बाद पासवर्ड का उपयोग USSH प्रमाणीकरण के लिए किया जाता है।
• सर्वर ussh_server.py चलाने वाली मशीन पर एक वास्तविक PTY-समर्थित शेल लॉन्च करता है।
• क्लाइंट stdin बाइट्स भेजता है और stdout बाइट्स प्रस्तुत करता है।
• सर्वर कई क्लाइंटों का समर्थन करता है, प्रत्येक क्लाइंट के लिए एक शेल/सत्र के साथ।
• यदि सर्वर पर --cipher सेट है, तो सर्वर उसी सटीक सिफर का उपयोग करता है।
• यदि --cipher छोड़ दिया गया है या auto पर सेट है, तो सर्वर क्लाइंट द्वारा अनुरोधित सिफर का उपयोग करता है।
• क्लाइंट अप्रत्याशित सिफर वार्ता को अस्वीकार करते हैं।
• पहले कनेक्शन के बाद अप्रत्याशित सर्वर कुंजी परिवर्तनों का पता लगाने के लिए क्लाइंट पर TOFU (पहले उपयोग पर भरोसा) सक्षम है।
• सर्वर डिफ़ॉल्ट रूप से ~/.ussh_host_key में एक स्थायी X25519 होस्ट कुंजी रखता है ताकि TOFU पुनः कनेक्शन और पुनरारंभ के दौरान स्थिर रहे।
• एक सामान्य सर्वर पुनरारंभ होस्ट कुंजी को नहीं बदलता है।
• सर्वर पर --regen-key का उपयोग केवल तभी करें जब आप जानबूझकर उस होस्ट कुंजी को घुमाना चाहते हैं।
• TOFU प्रविष्टियाँ प्रति <peer-ip-or-domain>:<peer-port> संग्रहीत की जाती हैं, इसलिए एक अलग पते/पोर्ट पर एक अलग सर्वर को एक अलग होस्ट पहचान के रूप में माना जाता है।

ट्रांसपोर्ट हैंडशेक

• USSH USTP-Secure के समान USTPS रीट्राई-टोकन हैंडशेक विरासत में लेता है।
• सर्वर पहले क्लाइंट को रीट्राई टोकन और सत्र मेटाडेटा के साथ चुनौती देता है।
• एन्क्रिप्टेड USSH सत्र स्वीकार होने से पहले क्लाइंट को उस टोकन को वापस प्रतिध्वनित करना चाहिए।
• वही हैंडशेक अंतिम AEAD सिफर और यह भी वार्ता करता है कि USTPS कंजेशन on है या off।
• वही हैंडशेक यह भी वार्ता करता है कि DATA AEAD एन्क्रिप्शन या क्लियरटेक्स्ट प्लस HMAC का उपयोग करता है या नहीं।
• रीट्राई टोकन सत्र निर्माण से पहले केवल एक पहुंच-क्षमता प्रमाण है।
• यह सत्र कुंजी नहीं है, पैकेट नॉनस नहीं है, और बाद में व्युत्पन्न AEAD सत्र कुंजी का प्रतिस्थापन नहीं है।