scp عبر SFTP: كتابة مسارات بعيدة تُحل فعليًا

أمر scp كان يعمل في سكربت لسنوات قد يفشل على عميل حالي بخطأ في المسار لا علاقة له بالنفق. نقل الـ VPN البايتات؛ وطلب العميل من الخادم اسمًا لم يستطع الخادم حله. نقل scp في OpenSSH الحالي يتم عبر SFTP افتراضيًا، وSFTP لا يقوم بالتوسيع على طريقة الصدفة كما فعل البروتوكول القديم. تتبع الأمر من حسابك الخاص يُظهر أين يُفسَّر المسار حقًا.

ابدأ من الحساب، ثم من الدليل الذي يمكنه الكتابة فيه

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

اطلب من الخادم رؤيته الخاصة: ssh [email protected] pwd و ssh [email protected] ls -ld /srv/archive. إذا أبلغ الأمر الثاني عن رفض الإذن، فالنفق سليم والمسار غير قابل للاستخدام لذلك الحساب. أصلح الملكية أو اختر وجهة مختلفة بدلًا من توسيع الأذونات كي يمضي النقل.

يمكن لتهيئة SFTP المقيدة أن تعرض chroot كجذر لنظام الملفات. داخل تلك الرؤية يكون المسار المطلق مطلقًا داخل الـ chroot، وهو ليس الموقع نفسه الذي يراه المدير على المضيف.

سمِّ طرفي النقطتين صراحةً

ينبغي للرفع أن يذكر اسم الملف البعيد بدلًا من افتراض أن الاسم الأساسي المحلي سيكون مقبولًا في الطرف الآخر.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

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

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

تجنب ~otheruser في سكربت تتم صيانته. كان توسيع دليل منزل حساب آخر ميزةً في صدفة بعيدة، وقد لا ينفذ خادم SFTP الامتداد الذي يحاكيه. اكتب المسار المطلق الذي يمكن للحساب فتحه فعلًا، وضع المسارات المحلية التي تحتوي مسافات بين علامتي اقتباس بدلًا من نسخ طبقات اقتباس كُتبت لصدفة على الخادم.

اعرف أي بروتوكول يستخدمه scp لديك فعليًا

منذ OpenSSH 9.0 يستخدم العميل SFTP افتراضيًا، وتعتمد التوزيعات ذلك السلوك أو تستورده وفق جدولها الخاص. تخبرك سلسلة الإصدار بما ينوي العميل فعله، لكن بناء بائع قد يختلف عن المنبع، لذا افحص العميل الذي تشغله فعلًا: ssh -V.

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

يطبع scp -v النظام الفرعي الذي يطلبه، ويؤكد سطر النظام الفرعي sftp أن المسار الحديث قيد الاستخدام. يفرض scp -O البروتوكول القديم حيث يكون مدعومًا ومطلوبًا حقًا، ويعيد معه قواعد الاقتباس الخاصة به. ليس خيار VPN، وليس طريقة لتمكين أي شيء على الخادم، وليس سببًا لتخفيف فحص مفتاح المضيف.

اختبر المسار قبل أن يعتمد عليه السكربت

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

افحص جانب الخادم كذلك. يُظهر grep -i subsystem /etc/ssh/sshd_config ما إذا كان النظام الفرعي SFTP مهيأً، ولا ينجح sftp -b /dev/null [email protected] في الخروج إلا عندما يستجيب ذلك النظام الفرعي. المضيف الذي يقبل تسجيلات SSH لكنه بلا نظام فرعي يفشل في كل نقل حديث بينما يبدو سليمًا تمامًا في اختبار تسجيل الدخول.

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