Perintah scp yang berfungsi dalam skrip selama bertahun-tahun boleh gagal pada klien semasa dengan ralat laluan yang tiada kaitan dengan terowong. VPN membawa bait; klien meminta nama daripada pelayan yang pelayan tidak dapat selesaikan. scp OpenSSH semasa memindahkan melalui SFTP secara lalai, dan SFTP tidak melakukan pengembangan gaya shell seperti protokol lama. Menjejaki perintah daripada akaun anda sendiri ke luar menunjukkan di mana laluan benar-benar ditafsirkan.

Mulakan dengan akaun, kemudian direktori yang boleh ditulisnya

Titik bertindih memisahkan dua ruang nama, dan hanya sebelah kiri milik mesin yang anda taip. Semua selepas itu diselesaikan oleh pelayan, di bawah akaun yang anda sahkan, dalam paparan sistem fail yang dimiliki akaun itu. Sahkan kedua-duanya sebelum menyusun perintah, kerana laluan yang betul untuk pentadbir tidak semestinya betul untuk pengguna pemindahan. Perbezaan itulah punca kebanyakan ralat kebenaran yang kelihatan seperti kerosakan rangkaian.

Tanya pelayan tentang paparannya sendiri: ssh [email protected] pwd dan ssh [email protected] ls -ld /srv/archive. Jika perintah kedua melaporkan kebenaran ditolak, terowong baik dan laluan tidak boleh digunakan untuk akaun itu. Betulkan pemilikan atau pilih destinasi lain daripada meluaskan kebenaran supaya pemindahan dapat diteruskan.

Konfigurasi SFTP terhad boleh memaparkan chroot sebagai akar sistem fail. Dalam paparan itu laluan mutlak adalah mutlak dalam chroot, yang bukan lokasi sama seperti yang dilihat pentadbir pada hos.

Namakan kedua-dua belah titik bertindih secara eksplisit

Muat naik harus menyatakan nama fail jauh dan bukannya menganggap nama asas tempatan akan diterima di sebelah sana.

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

Muat turun harus menyatakan destinasi tempatan atas sebab yang sama. Kedua-dua ruang nama adalah bebas, dan skrip yang menganggap kedua-duanya sepadan akan rosak kali pertama pokok jauh menggunakan susun atur berbeza.

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

Elakkan ~otheruser dalam skrip yang diselenggara. Mengembangkan direktori rumah akaun lain ialah ciri shell jauh, dan pelayan SFTP mungkin tidak melaksanakan sambungan yang menirunya. Tulis laluan mutlak yang benar-benar boleh dibuka oleh akaun, dan letakkan laluan tempatan yang mengandungi ruang dalam tanda petikan dan bukannya menyalin lapisan petikan yang ditulis untuk shell pada pelayan.

Ketahui protokol yang sebenarnya digunakan oleh scp anda

Sejak OpenSSH 9.0 klien menggunakan SFTP secara lalai, dan pengedaran mengguna pakai atau memport semula tingkah laku itu mengikut jadual mereka sendiri. Rentetan versi memberitahu apa yang dimaksudkan klien, tetapi binaan vendor mungkin berbeza daripada upstream, jadi periksa klien yang benar-benar anda jalankan: ssh -V.

Kedua-dua protokol menyelesaikan nama secara berbeza. SCP lama meminta shell pengguna jauh mengembangkan laluan, jadi kad bebas dan tilde dikendalikan oleh shell itu dengan peraturannya sendiri. SFTP sebaliknya mengeluarkan operasi pemindahan fail, jadi kad bebas sama ada dikembangkan oleh klien atau tidak dikembangkan sama sekali. Kedua-duanya bergerak dalam SSH ke mesin yang sama, sebab itulah satu hos boleh berkelakuan berbeza di bawah dua klien.

scp -v mencetak subsistem yang dimintanya, dan baris subsistem sftp mengesahkan laluan moden sedang digunakan. scp -O memaksa protokol lama di tempat yang disokong dan benar-benar diperlukan, dan ia membawa kembali peraturan petikannya sendiri. Ia bukan pilihan VPN, bukan cara untuk mendayakan apa-apa pada pelayan, dan bukan alasan untuk melonggarkan pemeriksaan kunci hos.

Uji laluan sebelum skrip bergantung padanya

Masalah laluan timbul pada masa paling buruk, dalam tugas automatik pada waktu malam tanpa sesiapa memerhati. Buktikan destinasi dahulu dengan fail kecil dan akaun tepat yang digunakan tugas, dan simpan perintah ujian itu di sebelah definisi tugas. Jika ujian memerlukan akaun lain atau direktori lain, tugas juga akan memerlukannya.

Periksa sebelah pelayan juga. grep -i subsystem /etc/ssh/sshd_config menunjukkan sama ada subsistem SFTP dikonfigurasikan, dan sftp -b /dev/null [email protected] berjaya keluar hanya apabila subsistem itu menjawab. Hos yang menerima log masuk SSH tetapi tiada subsistem gagal pada setiap pemindahan moden walaupun kelihatan sihat sepenuhnya dalam ujian log masuk.

Catat versi klien, protokol yang digunakan dan laluan jauh mutlak dalam nota tugas. Apabila peningkatan seterusnya mengubah lalai, nota itulah perbezaan antara pembetulan lima minit dan sepanjang petang meneka.

Artikel berkaitan