scp sa ibabaw ng SFTP: pagsulat ng malalayong path na talagang nareresolba

Ang utos na scp na gumana sa isang script nang maraming taon ay maaaring mabigo sa kasalukuyang client na may error sa path na walang kinalaman sa tunnel. Dinala ng VPN ang mga byte; hiniling ng client sa server ang pangalang hindi kayang resolbahin ng server. Ang kasalukuyang OpenSSH scp ay naglilipat sa pamamagitan ng SFTP bilang default, at ang SFTP ay hindi gumagawa ng shell-style na expansion tulad ng lumang protocol. Ang pagsunod sa utos mula sa iyong sariling account pakanluran ay nagpapakita kung saan talaga binibigyang-kahulugan ang path.

Magsimula sa account, pagkatapos sa direktoryo kung saan ito makakasulat

Hinahati ng tutuldok ang dalawang namespace, at ang kaliwang bahagi lamang ang pag-aari ng makina kung saan ka nagta-type. Lahat ng sumusunod ay nireresolba ng server, sa ilalim ng account na pinatunayan mo, sa loob ng anumang view ng file system na mayroon ang account na iyon. Kumpirmahin ang dalawa bago buuin ang utos, dahil ang path na tama para sa administrador ay hindi awtomatikong tama para sa user ng paglilipat. Ang pagkakaibang iyon ang pinagmumulan ng karamihan ng mga error sa pahintulot na mukhang sira ng network.

Itanong sa server ang sarili nitong view: ssh [email protected] pwd at ssh [email protected] ls -ld /srv/archive. Kung ang pangalawang utos ay nag-uulat ng pahintulot na tinanggihan, maayos ang tunnel at hindi magagamit ang path para sa account na iyon. Ayusin ang pagmamay-ari o pumili ng ibang destinasyon sa halip na palawakin ang mga pahintulot upang makapagpatuloy ang paglilipat.

Ang isang limitadong configuration ng SFTP ay maaaring magpakita ng chroot bilang ugat ng file system. Sa loob ng view na iyon ang isang absolute path ay absolute sa loob ng chroot, na hindi kaparehong lokasyon ng nakikita ng administrador sa host.

Pangalanan nang tahasan ang dalawang panig ng tutuldok

Ang pag-upload ay dapat magsaad ng malayong pangalan ng file sa halip na ipagpalagay na tatanggapin sa kabilang panig ang lokal na batayang pangalan.

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

Ang pag-download ay dapat magsaad ng lokal na destinasyon sa eksaktong parehong dahilan. Ang dalawang namespace ay independyente, at ang script na nagpapalagay na tugma ang mga ito ay masisira sa unang pagkakataon na gumamit ang malayong puno ng ibang layout.

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

Iwasan ang ~otheruser sa isang script na inaalagaan. Ang pagpapalawak ng home directory ng ibang account ay tampok ng malayong shell, at maaaring hindi ipatupad ng SFTP server ang extension na gumagaya nito. Isulat ang absolute path na talagang kayang buksan ng account, at ilagay sa mga quote ang lokal na path na may espasyo sa halip na kopyahin ang mga patong ng quote na isinulat para sa shell sa server.

Alamin kung aling protocol ang talagang ginagamit ng iyong scp

Mula sa OpenSSH 9.0 ang client ay gumagamit ng SFTP bilang default, at ang mga distribusyon ay nag-aampon o nagba-backport ng gawi na iyon ayon sa sarili nilang iskedyul. Sinasabi ng version string kung ano ang balak ng client, ngunit ang build ng vendor ay maaaring naiiba sa upstream, kaya suriin ang client na talagang pinapatakbo mo: ssh -V.

Iba ang pagresolba ng pangalan ng dalawang protocol. Hinihiling ng lumang SCP sa shell ng malayong user na palawakin ang path, kaya ang mga wildcard at tilde ay pinangangasiwaan ng shell na iyon ayon sa sarili nitong mga tuntunin. Sa halip, naglalabas ang SFTP ng mga operasyon ng paglilipat ng file, kaya ang wildcard ay pinalalawak ng client o hindi pinalalawak talaga. Pareho silang naglalakbay sa loob ng SSH patungo sa parehong makina, kaya ang isang host ay maaaring kumilos nang iba sa ilalim ng dalawang client.

scp -v ay nagpi-print ng subsystem na hinihiling nito, at ang linya ng subsystem na sftp ay nagpapatunay na ginagamit ang modernong path. Pinipilit ng scp -O ang lumang protocol kung saan ito sinusuportahan at talagang kailangan, at ibinabalik nito ang sarili nitong mga tuntunin sa quote. Hindi ito opsyon ng VPN, hindi paraan upang paganahin ang isang bagay sa server, at hindi dahilan upang luwagan ang pagsusuri ng host key.

Subukan ang path bago umasa ang script dito

Ang problema sa path ay lumalabas sa pinakamasamang oras, sa isang automated na trabaho sa gabi na walang nanonood. Patunayan muna ang destinasyon gamit ang maliit na file at ang eksaktong account na ginagamit ng trabaho, at itago ang test command na iyon sa tabi ng depinisyon ng trabaho. Kung ang test ay nangangailangan ng ibang account o ibang direktoryo, kakailanganin din ito ng trabaho.

Suriin din ang panig ng server. Ipinapakita ng grep -i subsystem /etc/ssh/sshd_config kung may naka-configure na SFTP subsystem, at ang sftp -b /dev/null [email protected] ay matagumpay na lumalabas lamang kapag tumugon ang subsystem na iyon. Ang host na tumatanggap ng SSH login ngunit walang subsystem ay nabigo sa bawat modernong paglilipat habang mukhang perpektong malusog sa isang pagsubok ng login.

Itala ang bersyon ng client, ang protocol na ginagamit at ang absolute na malayong path sa mga tala ng trabaho. Kapag binago ng susunod na upgrade ang isang default, ang talang iyon ang pagkakaiba ng limang minutong pagwawasto at ng isang hapong puno ng hula.