الخلاصة

  • تمنح SSH_MSG_CHANNEL_WINDOW_ADJUST الإذن بإرسال بايتات إضافية في قناة SSH، ولا تثبت أن أمراً بعيداً استهلكها أو اكتمل.
  • يصف رد طلب exec وحالة الخروج الاختيارية وEOF والإغلاق المتبادل لحظات مختلفة، ولا يقوم أي منها تلقائياً مقام نتيجة تطبيق دائمة.
  • تحتاج العمليات ذات الأثر إلى هوية مانعة للتكرار وطريق للاستعلام عن النتيجة يبقيان بعد انتهاء جلسة SSH، كي لا يصبح الانقطاع سبباً لإعادة عمياء.

أربعة أوضاع تختبئ خلف لون أخضر واحد

يريد مستخدم التنفيذ البعيد جواباً واحداً: هل نجح؟ أما البروتوكول فيجيب أسئلة أصغر: هل فُتحت القناة؟ هل قبل الخادم طلب exec؟ هل صار للمرسل أن يبعث مزيداً من البيانات؟ هل أبلغت العملية البعيدة حالة خروج؟ وهل أغلق الطرفان القناة؟

التمييز عملي لا شكلي. قد يُقبل طلب البدء ثم يفشل البرنامج. وقد تتحرك البيانات بينما لم يفسرها البرنامج بعد. وقد تضع العملية العمل في طابور آخر ثم تنتهي. ويمكن أن ينقطع الاتصال بعد ثبوت الأثر في النظام البعيد وقبل وصول خبره إلى العميل.

لذلك ينبغي أن يحتفظ نموذج التشغيل بأربع حالات مستقلة: قبول الطلب، ورصيد تدفق القناة، وانتهاء العملية، والنتيجة الدائمة للتطبيق. يمكن رصد الثلاث الأولى عبر SSH؛ أما الرابعة فيعرّفها البرنامج الذي يجري تشغيله.

ما الذي تمنحه النافذة فعلاً؟

يعرّف القسم 5.2 من RFC 4254 النافذة بالبايتات. فهي تحدد المقدار الذي يستطيع الطرف الآخر إرساله قبل أن ينتظر التعديل. وتحمل SSH_MSG_CHANNEL_WINDOW_ADJUST رقم قناة المستلم وعدد البايتات المضافة. وتستهلك البيانات العادية والممتدة، ومنها الخطأ القياسي، الرصيد نفسه.

هذا عقد للتحكم في التدفق. تتحدث حقوله عن قناة وكمية، لا عن معرّف أمر أو حالة تطبيق أو علامة تخزين دائم أو ملخص نتيجة. كما لا يفرض النص حدثاً داخلياً بعينه يجب أن يقع قبل زيادة الرصيد؛ فاختيارات الذاكرة والجدولة شأن التنفيذ.

يمكن إذاً استنتاج استعداد النظير لقبول مزيد من حركة القناة. لكن لا يمكن استنتاج أن بايتاً معيناً عبر مكتبة SSH ونظام التشغيل والعملية المستدعاة والخدمة التي قد تستدعيها. تحمي النافذة السعة المتفق عليها؛ ولا تمسك دفتر آثار التطبيق.

قبول البدء ليس اكتمالاً

لطلبات القناة آلية رد منفصلة. إذا كانت want reply صحيحة، يرسل المتلقي نجاح القناة أو فشلها أو متابعة خاصة بالطلب. ويطلب exec من الخادم بدء تنفيذ الأمر المحدد، ويوصي RFC بطلب الرد والتحقق منه.

يفصل ذلك الرد بين القبول والرفض، وهي معلومة مهمة. إلا أن دورة حياة الأمر لا تزال في بدايتها. لا تحمل رسالة النجاح رمز الخروج اللاحق ولا معرّف الكائن الدائم الذي قد ينشئه التطبيق.

حين تسمي مكتبة هذه اللحظة «success» من دون إظهار طبقتها، يبدو الاسم نهائياً أكثر مما يحتمل. يجب أن يسجل التشغيل ما تثبته الإشارة فعلاً، وأن يربطها بالجلسة والقناة وبصمة الأمر.

حالة الخروج أقوى، لكنها محدودة

يحدد RFC 4254 رسالة exit-status لما بعد انتهاء الأمر في الطرف البعيد. إعادتها موصى بها وليست إلزامية؛ ولا يُرسل إقرار بها، ويجوز للعميل تجاهلها. ويقول النص إن الصفر يعني «عادةً» انتهاءً ناجحاً.

هذه بينة أقوى من رصيد البايتات. فإذا كان البرنامج متزامناً ويَعِد بألا يخرج بصفر إلا بعد إنجاز العمل، فقد تكون إشارة النهاية المناسبة.

لكن غلافاً برمجياً قد يخرج بصفر فور إيداع المهمة في طابور. وقد يقبل مدير خدمة طلب إعادة التشغيل قبل عودة الصحة. وقد يحدّث أمر نشر مستوى التحكم فيما النسخ ما زالت تتقارب. ينقل SSH نتيجة العملية بأمانة؛ ولا ينشئ معنى التطبيق.

الإغلاق ينهي القناة ولا يمحو المجهول

تفيد EOF أن طرفاً لن يرسل بيانات أخرى، ولا يصلها رد صريح ولا تغلق الاتجاه المعاكس. ويمكن لأي طرف إرسال close من دون EOF سابقة. ويعد الطرف القناة مغلقة بعد أن يرسل close ويتلقاها. أما إيصال البيانات السابقة إلى مقصدها الفعلي فموصى به «إن أمكن».

هذه نهاية مرتبة لمورد الاتصال، وليست ضماناً بأن كل بايت أحدث أثراً. وفي المقابل، غياب الرسالة الأخيرة لا يثبت غياب الأثر. قد ينقطع المسار بعد تثبيت التغيير على الخادم ويبقى العميل جاهلاً به.

تحويل هذا الجهل إلى فشل مؤكد، ثم إعادة عملية غير مانعة للتكرار، يصنع الازدواج الذي لم تُصمم القناة لحله.

تبقى ضمانات الأمان داخل حدودها

يقسم RFC 4251 SSH إلى النقل ومصادقة المستخدم والاتصال. يوفر RFC 4253 التشفير ومصادقة الخادم والتكامل، ويصادق RFC 4252 المستخدم في جانب العميل، ثم يعدد بروتوكول الاتصال القنوات المنطقية فوق هذه الأسس.

تجيب هذه الضمانات عن هوية الخادم والمستخدم وعن حماية البيانات أثناء النقل. ولا تجيب هل ثُبت ترحيل قاعدة بيانات، أو بلغ تثبيت حزمة حالته المنشودة، أو أنهت واجهة برمجية استدعتها العملية عملها. تجعل المصادقة القوية الدليل منسوباً إلى صاحبه؛ ولا توسع مدلوله.

هوية للعملية تعيش بعد الجلسة

ينبغي أن تحمل العملية المكلفة أو غير القابلة للعكس معرّفاً لا يختفي مع SSH. يستطيع النظام البعيد أن يربط به صاحب الهوية المصادق عليها والهدف وبصمة الطلب ووقت القبول والحالة والنتيجة النهائية والكائن المنشأ. ويحتاج العميل إلى الاستعلام عنه بعد إعادة الاتصال.

لا يتطلب ذلك امتداداً جديداً لـSSH. يمكن لعقد سطر الأوامر أن يستقبل مفتاح منع التكرار، ويعيد معرّف عملية، ويوفر استعلاماً عنه. وقد تكفي المخرجات ورمز الخروج لقراءة أو أمر ثابت التكرار. يلزم العقد الأقوى حين يمكن للإعادة إنشاء موردين أو تدوير اعتماد مرتين أو تعطيل أسطول مرة أخرى.

القاعدة هي إبقاء الأسماء صادقة: تعديل النافذة رصيد بايتات، ونجاح الطلب قبول، وحالة الخروج دليل عملية، وclose نهاية قناة. أما اكتمال العمل فيجب أن يثبته العمل نفسه.

المصادر