scp prin SFTP: scrierea căilor la distanță care chiar se rezolvă

O comandă scp care a funcționat ani de zile într-un script poate eșua pe un client actual cu o eroare de cale care nu are nimic de-a face cu tunelul. VPN-ul a transportat octeții; clientul a cerut serverului un nume pe care serverul nu l-a putut rezolva. scp actual din OpenSSH transferă implicit prin SFTP, iar SFTP nu face extindere în stil shell cum făcea protocolul vechi. Urmărirea comenzii din propriul cont spre exterior arată unde este calea interpretată cu adevărat.

Începeți cu contul, apoi cu directorul în care poate scrie

Două puncte separă două spații de nume, iar doar partea stângă aparține mașinii pe care tastați. Tot ce urmează este rezolvat de server, sub contul cu care v-ați autentificat, în interiorul vederii sistemului de fișiere pe care o are acel cont. Confirmați ambele înainte de a compune comanda, deoarece o cale corectă pentru administrator nu este automat corectă pentru utilizatorul transferului. Această diferență este sursa majorității erorilor de permisiuni care arată ca defecțiuni de rețea.

Întrebați serverul despre propria vedere: ssh [email protected] pwd și ssh [email protected] ls -ld /srv/archive. Dacă a doua comandă raportează permisiune refuzată, tunelul este în regulă, iar calea este inutilizabilă pentru acel cont. Corectați proprietatea sau alegeți o altă destinație în loc să extindeți permisiunile pentru ca transferul să poată continua.

O configurație SFTP restricționată poate prezenta un chroot ca rădăcină a sistemului de fișiere. În acea vedere o cale absolută este absolută în interiorul chroot-ului, ceea ce nu este același loc pe care administratorul îl vede pe gazdă.

Numiți explicit ambele părți ale celor două puncte

Un upload ar trebui să indice numele fișierului la distanță în loc să presupună că numele de bază local va fi acceptabil în cealaltă parte.

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

Un download ar trebui să indice destinația locală exact din același motiv. Cele două spații de nume sunt independente, iar un script care presupune că se potrivesc se strică prima dată când arborele de la distanță folosește o altă dispunere.

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

Evitați ~otheruser într-un script întreținut. Extinderea directorului home al altui cont era o funcție a shell-ului la distanță, iar un server SFTP poate să nu implementeze extensia care o emulează. Scrieți calea absolută pe care contul chiar o poate deschide și puneți între ghilimele căile locale cu spații, în loc să copiați straturi de ghilimele scrise pentru un shell pe server.

Aflați ce protocol folosește de fapt scp-ul dumneavoastră

Din OpenSSH 9.0 clientul folosește implicit SFTP, iar distribuțiile adoptă sau retroportează acest comportament după propriul calendar. Șirul versiunii spune ce intenționează clientul, dar o compilare a furnizorului poate diferi de upstream, așa că verificați clientul pe care îl rulați de fapt: ssh -V.

Cele două protocoale rezolvă numele diferit. SCP vechi cere shell-ului utilizatorului de la distanță să extindă calea, așa că metacaracterele și tildele sunt gestionate de acel shell după propriile reguli. SFTP emite în schimb operații de transfer de fișiere, așa că un metacaracter este fie extins de client, fie deloc. Ambele călătoresc în interiorul SSH către aceeași mașină, motiv pentru care o gazdă se poate comporta diferit sub doi clienți.

scp -v afișează subsistemul pe care îl solicită, iar o linie de subsistem sftp confirmă că se folosește calea modernă. scp -O forțează protocolul vechi acolo unde este acceptat și chiar necesar, și aduce înapoi propriile reguli de citare. Nu este o opțiune VPN, nu este o modalitate de a activa ceva pe server și nu este un motiv pentru a relaxa verificarea cheii gazdei.

Testați calea înainte ca scriptul să depindă de ea

O problemă de cale apare în cel mai rău moment posibil, într-o sarcină automatizată noaptea, fără ca nimeni să se uite. Dovediți mai întâi destinația cu un fișier mic și cu contul exact pe care îl folosește sarcina, și păstrați acea comandă de test lângă definiția sarcinii. Dacă testul are nevoie de alt cont sau de alt director, și sarcina va avea nevoie.

Verificați și partea de server. grep -i subsystem /etc/ssh/sshd_config arată dacă este configurat un subsistem SFTP, iar sftp -b /dev/null [email protected] se termină cu succes doar când acel subsistem răspunde. O gazdă care acceptă autentificări SSH, dar nu are subsistem, eșuează la fiecare transfer modern, deși într-un test de autentificare pare perfect sănătoasă.

Notați versiunea clientului, protocolul utilizat și calea absolută la distanță în notele sarcinii. Când următoarea actualizare va schimba o valoare implicită, acea notă este diferența dintre o corectare de cinci minute și o după-amiază de presupuneri.