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 โดยค่าเริ่มต้น และดิสทริบิวชันรับหรือพอร์ตกลับพฤติกรรมนั้นตามกำหนดการของตนเอง สตริงเวอร์ชันบอกว่าไคลเอนต์ตั้งใจทำอะไร แต่บิลด์ของผู้จำหน่ายอาจต่างจาก upstream ดังนั้นตรวจสอบไคลเอนต์ที่คุณรันจริง: ssh -V

โปรโตคอลทั้งสองแก้ชื่อต่างกัน SCP เก่าขอให้เชลล์ของผู้ใช้ระยะไกลขยายพาธ ดังนั้นไวลด์การ์ดและ tilde ถูกจัดการโดยเชลล์นั้นตามกฎของมันเอง SFTP ส่งปฏิบัติการถ่ายโอนไฟล์แทน ดังนั้นไวลด์การ์ดจะถูกขยายโดยไคลเอนต์หรือไม่ถูกขยายเลย ทั้งสองเดินทางภายใน SSH ไปยังเครื่องเดียวกัน นี่คือเหตุผลที่โฮสต์เดียวอาจทำงานต่างกันภายใต้ไคลเอนต์สองตัว

scp -v พิมพ์ซับซิสเต็มที่มันขอ และบรรทัดซับซิสเต็ม sftp ยืนยันว่ากำลังใช้พาธสมัยใหม่ scp -O บังคับใช้โปรโตคอลเก่าในที่ที่รองรับและจำเป็นจริง และนำกฎเครื่องหมายคำพูดของมันกลับมาด้วย มันไม่ใช่ตัวเลือก VPN ไม่ใช่วิธีเปิดใช้งานสิ่งใดบนเซิร์ฟเวอร์ และไม่ใช่เหตุผลที่จะผ่อนการตรวจสอบคีย์โฮสต์

ทดสอบพาธก่อนที่สคริปต์จะพึ่งพามัน

ปัญหาพาธจะปรากฏในเวลาที่แย่ที่สุด ในงานอัตโนมัติตอนกลางคืนที่ไม่มีใครเฝ้าดู พิสูจน์ปลายทางก่อนด้วยไฟล์เล็กและบัญชีที่แน่นอนซึ่งงานใช้ และเก็บคำสั่งทดสอบนั้นไว้ข้างนิยามงาน หากการทดสอบต้องใช้บัญชีอื่นหรือไดเรกทอรีอื่น งานก็จะต้องใช้ด้วย

ตรวจสอบฝั่งเซิร์ฟเวอร์ด้วย grep -i subsystem /etc/ssh/sshd_config แสดงว่ามีการกำหนดค่าซับซิสเต็ม SFTP หรือไม่ และ sftp -b /dev/null [email protected] จะออกสำเร็จก็ต่อเมื่อซับซิสเต็มนั้นตอบสนอง โฮสต์ที่รับการล็อกอิน SSH แต่ไม่มีซับซิสเต็มจะล้มเหลวทุกการถ่ายโอนสมัยใหม่ทั้งที่ดูสมบูรณ์ดีในการทดสอบล็อกอิน

บันทึกเวอร์ชันไคลเอนต์ โปรโตคอลที่ใช้ และพาธระยะไกลสัมบูรณ์ไว้ในบันทึกงาน เมื่อการอัปเกรดครั้งถัดไปเปลี่ยนค่าเริ่มต้น บันทึกนั้นคือความต่างระหว่างการแก้ไขห้านาทีกับบ่ายทั้งบ่ายของการเดา