scp דרך SFTP: כתיבת נתיבים מרוחקים שבאמת נפתרים

פקודת scp שעבדה בסקריפט במשך שנים עשויה להיכשל בלקוח נוכחי עם שגיאת נתיב שאין לה שום קשר למנהרה. ה-VPN נשא את הבתים; הלקוח ביקש מהשרת שם שהשרת לא הצליח לפתור. OpenSSH scp הנוכחי מעביר דרך 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 כברירת מחדל, והפצות מאמצות או מייבאות לאחור את ההתנהגות הזו לפי לוח הזמנים שלהן. מחרוזת הגרסה אומרת מה הלקוח מתכוון לעשות, אבל בנייה של ספק עשויה להיות שונה מה-upstream, לכן בדקו את הלקוח שאתם באמת מריצים: 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 אך אין לו תת-מערכת נכשל בכל העברה מודרנית בעודו נראה בריא לחלוטין בבדיקת התחברות.

רשמו את גרסת הלקוח, הפרוטוקול שבשימוש והנתיב המרוחק המוחלט בהערות המשימה. כשהשדרוג הבא ישנה ברירת מחדל, ההערה הזו היא ההבדל בין תיקון של חמש דקות לבין אחר צהריים של ניחושים.