scp per SFTP: nuotolinių kelių, kurie tikrai išsprendžiami, rašymas

scp komanda, kuri metų metus veikė scenarijuje, gali nepavykti dabartiniame kliente su kelio klaida, kuri neturi nieko bendra su tuneliu. VPN perdavė baitus; klientas paprašė serverio vardo, kurio serveris negalėjo išspręsti. Dabartinis OpenSSH scp pagal nutylėjimą perduoda per SFTP, o SFTP neatlieka apvalkalo stiliaus išplėtimo kaip senasis protokolas. Komandos sekimas nuo jūsų pačių paskyros į išorę parodo, kur kelias iš tikrųjų interpretuojamas.

Pradėkite nuo paskyros, tada nuo katalogo, į kurį ji gali rašyti

Dvitaškis skiria dvi vardų erdves, ir tik kairioji pusė priklauso mašinai, kurioje rašote. Viską po jo išsprendžia serveris, pagal paskyrą, kuria autentifikavotės, tos paskyros turimo failų sistemos vaizdo viduje. Patvirtinkite abu prieš sudarydami komandą, nes administratoriui teisingas kelias nėra automatiškai teisingas perdavimo naudotojui. Šis skirtumas yra daugumos leidimų klaidų, atrodančių kaip tinklo gedimai, šaltinis.

Paklauskite serverio jo paties vaizdo: ssh [email protected] pwd ir ssh [email protected] ls -ld /srv/archive. Jei antroji komanda praneša apie leidimo atsisakymą, tunelis tvarkingas, o kelias tai paskyrai netinkamas. Ištaisykite nuosavybę arba pasirinkite kitą paskirties vietą, o ne plėskite leidimus, kad perdavimas galėtų tęstis.

Apribota SFTP konfigūracija gali pateikti chroot kaip failų sistemos šaknį. To vaizdo viduje absoliutus kelias yra absoliutus chroot viduje, o tai nėra ta pati vieta, kurią administratorius mato pagrindiniame kompiuteryje.

Aiškiai įvardykite abi dvitaškio puses

Įkėlimas turėtų nurodyti nuotolinį failo vardą, o ne daryti prielaidą, kad vietinis bazinis vardas bus priimtinas kitoje pusėje.

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

Atsisiuntimas turėtų nurodyti vietinę paskirties vietą dėl lygiai tos pačios priežasties. Dvi vardų erdvės yra nepriklausomos, ir scenarijus, kuris daro prielaidą, kad jos sutampa, sugenda pirmą kartą, kai nuotolinis medis naudoja kitokį išdėstymą.

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

Venkite ~otheruser prižiūrimame scenarijuje. Kitos paskyros namų katalogo išplėtimas buvo nuotolinio apvalkalo funkcija, ir SFTP serveris gali neįgyvendinti plėtinio, kuris tai imituoja. Rašykite absoliutų kelią, kurį paskyra iš tikrųjų gali atidaryti, o vietinius kelius su tarpais dėkite į kabutes, o ne kopijuokite kabučių sluoksnius, parašytus serverio apvalkalui.

Žinokite, kokį protokolą jūsų scp iš tikrųjų naudoja

Nuo OpenSSH 9.0 klientas pagal nutylėjimą naudoja SFTP, o distribucijos tą elgesį perima arba atgaline data perkelia savo grafiku. Versijos eilutė pasako, ko ketina klientas, bet tiekėjo rinkinys gali skirtis nuo upstream, todėl patikrinkite klientą, kurį iš tikrųjų paleidžiate: ssh -V.

Du protokolai vardus išsprendžia skirtingai. Senasis SCP prašo nuotolinio naudotojo apvalkalo išplėsti kelią, todėl pakaitos simbolius ir tildes tvarko tas apvalkalas pagal savo taisykles. SFTP vietoj to išduoda failų perdavimo operacijas, todėl pakaitos simbolį arba išplečia klientas, arba jis visai neišplečiamas. Abu keliauja SSH viduje į tą pačią mašiną, todėl vienas pagrindinis kompiuteris gali elgtis skirtingai su dviem klientais.

scp -v išspausdina posistemį, kurio prašo, o sftp posistemio eilutė patvirtina, kad naudojamas šiuolaikinis kelias. scp -O verčia naudoti senąjį protokolą ten, kur jis palaikomas ir tikrai reikalingas, ir su savimi grąžina savo kabučių taisykles. Tai ne VPN parinktis, ne būdas ką nors įjungti serveryje ir ne priežastis susilpninti pagrindinio kompiuterio rakto tikrinimą.

Išbandykite kelią, prieš scenarijui juo pasikliaujant

Kelio problema iškyla pačiu blogiausiu metu, automatizuotoje naktinėje užduotyje, kai niekas nežiūri. Pirmiausia įrodykite paskirties vietą mažu failu ir tikslia paskyra, kurią naudoja užduotis, ir laikykite tą bandomąją komandą prie užduoties apibrėžimo. Jei bandymui reikia kitos paskyros ar kito katalogo, jų reikės ir užduočiai.

Patikrinkite ir serverio pusę. grep -i subsystem /etc/ssh/sshd_config parodo, ar sukonfigūruotas SFTP posistemis, o sftp -b /dev/null [email protected] sėkmingai baigiasi tik tada, kai tas posistemis atsako. Pagrindinis kompiuteris, kuris priima SSH prisijungimus, bet neturi posistemio, nepavyksta kiekvieno šiuolaikinio perdavimo metu, nors prisijungimo teste atrodo visiškai sveikas.

Užrašykite kliento versiją, naudojamą protokolą ir absoliutų nuotolinį kelią užduoties pastabose. Kai kitas atnaujinimas pakeis numatytąją reikšmę, ta pastaba yra skirtumas tarp penkių minučių pataisymo ir popietės spėlionių.