USSH

USSH هو بروتوكول شل وزوج خادم/عميل مبني على USTP-Secure.

إنه ليس نفق TCP ولا يغلّف SSH داخل TCP.

الحالة: Beta

الترخيص: 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 بدلاً من الثقة الصامتة بالمفتاح الجديد. إذا قمت بتدوير مفتاح مضيف الخادم عمدًا، شغّل العميل مع --regen-key للسماح باستبدال مفتاح TOFU المخزّن بعد تأكيد تفاعلي.

مسودات الإنترنت

• مسودة إنترنت USSH: https://datatracker.ietf.org/doc/draft-x1co-ussh/

ملاحظات

• النقل هو USTP-Secure عبر UDP.
• يدعم USSH أيضًا وضع DATA النصي الواضح الاختياري مع سلامة HMAC لكل حزمة:
  • جانب الخادم: --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:، بالإضافة إلى إطارات DATA الثنائية UPACK (UPAK).
• تبقى ACK و NACK كنص واضح لأغراض قابلية التصحيح، لكنها موثّقة بعلامة HMAC لكل جلسة لمنع هجمات التحكم المزيفة عبر ACK/NACK.
• في الوضع العادي، تستخدم حمولات DATA تشفير AEAD.
• في وضع النص الواضح، لا يتم تشفير حمولات DATA، لكنها لا تزال تحمل HMAC بحيث لا يمكن لطرف ثالث تعديلها دون اكتشاف.
• يرث USSH سقف حمولة نقل USTPS البالغ 900 بايت لكل حمولة DATA من نوع UPACK.
• لا يعرّف USSH طبقة تجزئة ثانية أسفل USTPS.
• سلوك MTU على مستوى النقل، وPMTU، وسلوك nonce، ومعالجة التكرار، ومعالجة الحزم القديمة موروثة من USTPS.
• تمت إزالة الترحيل التلقائي للشبكة/المسار.
• إذا غيّر العميل شبكته وتغيّر IP:port المصدر الخاص به، فمن المتوقع أن تُغلق جلسة USSH الحالية ويجب على المستخدم إعادة الاتصال بشكل نظيف.
• تمت إزالة تنفيذ الترحيل لأنه تسبب في مشاكل موثوقية وأمان عملية:
  • فيضانات ترحيل متكررة عندما غيّرت شبكات NAT أو الشبكات المحمولة مساراتها بسرعة
  • جلسات بدت مستعادة لكنها توقفت عن تسليم بيانات الطرفية
  • فترات صمت طويلة قبل أن يلاحظ العميل أن المسار ميت
  • غموض بين عميل متجول حقيقي وحزم مزيفة تدّعي جلسة قائمة
  • حالة استعادة قد تترك الطرفية عالقة بدلاً من إعادة الاتصال بشكل نظيف
• السلوك الحالي أبسط عمدًا: التحقق من العميل على IP:port الحالي، وربط الجلسة بهذه النقطة الطرفية، وإعادة الاتصال إذا تغيّرت النقطة الطرفية.
• يرث USSH USTPS Congestion الاختياري من النقل.
• جانب الخادم: --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 لا يزال يتجنب حظر Head-of-Line على مستوى النقل، بينما يستعيد USSH فقط الترتيب على مستوى التطبيق المطلوب لعرض الطرفية.
• يتم تشفير الحمولات لكل حزمة باستخدام AEAD.
• لا يُستخدم PSK ثابت.
• يتلقى كل عميل مفتاح جلسة AEAD مؤقتًا منفصلًا عبر X25519.
• تُستخدم كلمة المرور لمصادقة USSH بعد إنشاء الجلسة الآمنة.
• يطلق الخادم شلًا حقيقيًا مدعومًا بـ PTY على الجهاز الذي يشغّل ussh_server.py.
• يرسل العميل بايتات stdin ويعرض بايتات stdout.
• يدعم الخادم عدة عملاء، مع شل/جلسة واحدة لكل عميل.
• إذا تم تعيين --cipher على الخادم، يستخدم الخادم ذلك التشفير بالضبط.
• إذا تم حذف --cipher أو تعيينه إلى auto، يستخدم الخادم التشفير الذي يطلبه العميل.
• يرفض العملاء التفاوض غير المتوقع على التشفير.
• TOFU (الثقة عند أول استخدام) مفعّل على العميل لاكتشاف تغييرات مفاتيح الخادم غير المتوقعة بعد أول اتصال.
• يحتفظ الخادم بمفتاح مضيف X25519 دائم في ~/.ussh_host_key افتراضيًا بحيث يبقى TOFU مستقرًا عبر عمليات إعادة الاتصال وإعادة التشغيل.
• إعادة تشغيل الخادم العادية لا تغيّر مفتاح المضيف.
• استخدم --regen-key على الخادم فقط عندما تريد عمدًا تدوير مفتاح المضيف هذا.
• تُخزَّن إدخالات TOFU لكل <peer-ip-or-domain>:<peer-port>، لذا يُعامل خادم مختلف على عنوان/منفذ مختلف كهوية مضيف مختلفة.

مصافحة النقل

• يرث USSH نفس مصافحة رمز إعادة المحاولة USTPS مثل USTP-Secure.
• يتحدى الخادم أولاً العميل برمز إعادة محاولة وبيانات وصفية للجلسة.
• يجب على العميل إعادة صدى هذا الرمز قبل قبول جلسة USSH المشفرة.
• تتفاوض نفس المصافحة أيضًا على تشفير AEAD النهائي وما إذا كان USTPS Congestion on أو off.
• تتفاوض نفس المصافحة أيضًا على ما إذا كانت DATA تستخدم تشفير AEAD أو نصًا واضحًا مع HMAC.
• رمز إعادة المحاولة هو فقط دليل على قابلية الوصول قبل إنشاء الجلسة.
• إنه ليس مفتاح الجلسة، وليس nonce للحزمة، وليس بديلاً عن مفتاح جلسة AEAD المشتق لاحقًا.