scp lewat SFTP: menulis jalur jarak jauh yang benar-benar terurai

Perintah scp yang bertahun-tahun berjalan di skrip bisa gagal pada klien saat ini dengan galat jalur yang tidak ada hubungannya dengan tunnel. VPN membawa byte-nya; klien meminta nama dari server yang tidak dapat diuraikan server. OpenSSH scp saat ini mentransfer lewat SFTP secara default, dan SFTP tidak melakukan perluasan gaya shell seperti protokol lama. Menelusuri perintah dari akun Anda sendiri ke luar menunjukkan di mana jalur benar-benar ditafsirkan.

Mulai dari akun, lalu dari direktori yang dapat ditulisnya

Titik dua memisahkan dua ruang nama, dan hanya sisi kiri milik mesin tempat Anda mengetik. Semua setelahnya diuraikan oleh server, di bawah akun yang Anda autentikasi, di dalam tampilan sistem berkas yang dimiliki akun itu. Pastikan keduanya sebelum menyusun perintah, karena jalur yang benar bagi administrator tidak otomatis benar bagi pengguna transfer. Perbedaan itulah sumber sebagian besar galat izin yang tampak seperti gangguan jaringan.

Tanyakan kepada server tampilannya sendiri: ssh [email protected] pwd dan ssh [email protected] ls -ld /srv/archive. Jika perintah kedua melaporkan izin ditolak, tunnel baik-baik saja dan jalur tidak dapat dipakai untuk akun itu. Perbaiki kepemilikan atau pilih tujuan lain alih-alih memperluas izin agar transfer dapat berlanjut.

Konfigurasi SFTP yang dibatasi dapat menyajikan chroot sebagai akar sistem berkas. Di dalam tampilan itu jalur absolut bersifat absolut di dalam chroot, yang bukan lokasi sama dengan yang dilihat administrator pada host.

Sebutkan kedua sisi titik dua secara eksplisit

Unggahan harus menyebutkan nama berkas jarak jauh alih-alih menganggap nama dasar lokal akan diterima di sisi seberang.

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

Unduhan harus menyebutkan tujuan lokal karena alasan yang persis sama. Kedua ruang nama itu independen, dan skrip yang menganggap keduanya cocok akan rusak pertama kali pohon jarak jauh memakai tata letak berbeda.

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

Hindari ~otheruser dalam skrip yang dipelihara. Memperluas direktori rumah akun lain adalah fitur shell jarak jauh, dan server SFTP mungkin tidak menerapkan ekstensi yang menirunya. Tulis jalur absolut yang benar-benar dapat dibuka akun, dan kutip jalur lokal yang berisi spasi alih-alih menyalin lapisan kutip yang ditulis untuk shell di server.

Ketahui protokol apa yang sebenarnya dipakai scp Anda

Sejak OpenSSH 9.0 klien memakai SFTP secara default, dan distribusi mengadopsi atau mem-backport perilaku itu sesuai jadwalnya sendiri. String versi memberi tahu apa yang dimaksud klien, tetapi build vendor dapat berbeda dari upstream, jadi periksa klien yang benar-benar Anda jalankan: ssh -V.

Kedua protokol menguraikan nama secara berbeda. SCP lama meminta shell pengguna jarak jauh memperluas jalur, jadi wildcard dan tilde ditangani shell itu dengan aturannya sendiri. SFTP mengeluarkan operasi transfer berkas, jadi wildcard diperluas oleh klien atau tidak diperluas sama sekali. Keduanya berjalan di dalam SSH menuju mesin yang sama, karena itu satu host dapat berperilaku berbeda di bawah dua klien.

scp -v mencetak subsistem yang dimintanya, dan baris subsistem sftp menegaskan jalur modern sedang dipakai. scp -O memaksa protokol lama di tempat yang didukung dan benar-benar diperlukan, dan membawa kembali aturan kutipnya sendiri. Ini bukan opsi VPN, bukan cara mengaktifkan apa pun di server, dan bukan alasan melonggarkan pemeriksaan kunci host.

Uji jalur sebelum skrip bergantung padanya

Masalah jalur muncul pada waktu terburuk, dalam tugas otomatis di malam hari tanpa siapa pun mengawasi. Buktikan tujuan lebih dulu dengan berkas kecil dan akun persis yang dipakai tugas, dan simpan perintah uji itu di samping definisi tugas. Jika uji memerlukan akun lain atau direktori lain, tugas juga akan memerlukannya.

Periksa sisi server juga. grep -i subsystem /etc/ssh/sshd_config menunjukkan apakah subsistem SFTP dikonfigurasi, dan sftp -b /dev/null [email protected] keluar dengan sukses hanya ketika subsistem itu menjawab. Host yang menerima login SSH tetapi tidak punya subsistem gagal pada setiap transfer modern sementara tampak sepenuhnya sehat dalam uji login.

Catat versi klien, protokol yang dipakai, dan jalur jarak jauh absolut dalam catatan tugas. Ketika peningkatan berikutnya mengubah default, catatan itu adalah selisih antara perbaikan lima menit dan sepanjang sore menebak-nebak.