scp SFTP-n keresztül: távoli útvonalak, amelyek tényleg feloldódnak
A modern scp SFTP-n keresztül továbbít, ezért a tilde-kiterjesztés és a helyettesítő karakterek másképp viselkednek. Írjon explicit kiszolgálóútvonalakat, és válassza a protokollt szándékosan.
Egy scp-parancs, amely évekig működött egy szkriptben, egy mai kliensen meghiúsulhat egy útvonalhibával, amelynek semmi köze az alagúthoz. A VPN vitte a bájtokat; a kliens olyan nevet kért a kiszolgálótól, amelyet a kiszolgáló nem tudott feloldani. A jelenlegi OpenSSH scp alapértelmezés szerint SFTP-n keresztül továbbít, és az SFTP nem végez héjstílusú kiterjesztést, mint a régi protokoll. Ha a parancsot a saját fiókjától kifelé követi, láthatja, hol értelmeződik valójában az útvonal.
Kezdje a fiókkal, majd azzal a könyvtárral, ahová írhat
A kettőspont két névteret választ el, és csak a bal oldal tartozik ahhoz a géphez, amelyen gépel. Mindent, ami utána jön, a kiszolgáló old fel, az alatt a fiók alatt, amellyel hitelesítette magát, azon fájlrendszer-nézet keretén belül, amellyel az a fiók rendelkezik. Erősítse meg mindkettőt, mielőtt összeállítja a parancsot, mert a rendszergazdának megfelelő útvonal nem feltétlenül megfelelő az átviteli felhasználónak. Ez a különbség a hálózati hibáknak tűnő engedélyhibák többségének forrása.
Kérdezze meg a kiszolgálót a saját nézetéről: ssh [email protected] pwd és ssh [email protected] ls -ld /srv/archive. Ha a második parancs engedélymegtagadást jelent, az alagút rendben van, és az útvonal használhatatlan ahhoz a fiókhoz. Javítsa a tulajdonjogot, vagy válasszon másik célt ahelyett, hogy kibővítené az engedélyeket, hogy az átvitel folytatódhasson.
Egy korlátozott SFTP-konfiguráció chrootot mutathat a fájlrendszer gyökereként. Ezen a nézeten belül az abszolút útvonal abszolút a chrooton belül, ami nem ugyanaz a hely, amelyet a rendszergazda a gazdagépen lát.
Nevezze meg kifejezetten a kettőspont mindkét oldalát
A feltöltésnek meg kell adnia a távoli fájlnevet ahelyett, hogy feltételezné, a helyi alapnév elfogadható lesz a túloldalon.
scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csvA letöltésnek pontosan ugyanezen okból meg kell adnia a helyi célt. A két névtér független, és a szkript, amely feltételezi, hogy megegyeznek, az első alkalommal eltörik, amikor a távoli fa más elrendezést használ.
scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csvKerülje a ~otheruser használatát karbantartott szkriptben. Egy másik fiók otthoni könyvtárának kiterjesztése távoli héjfunkció volt, és az SFTP-kiszolgáló lehet, hogy nem valósítja meg az ezt utánzó kiterjesztést. Írja be az abszolút útvonalat, amelyet a fiók valóban meg tud nyitni, és a szóközt tartalmazó helyi útvonalakat tegye idézőjelek közé, ahelyett hogy a kiszolgálón lévő héjhoz írt idézőjelrétegeket másolná.
Tudja, melyik protokollt használja valójában az scp-je
Az OpenSSH 9.0 óta a kliens alapértelmezés szerint SFTP-t használ, és a disztribúciók saját ütemtervük szerint fogadják el vagy portolják vissza ezt a viselkedést. A verziószöveg megmondja, mit szándékozik a kliens, de a gyártói build eltérhet az upstreamtől, ezért ellenőrizze a ténylegesen futtatott klienst: ssh -V.
A két protokoll különbözőképpen oldja fel a neveket. A régi SCP megkéri a távoli felhasználói héjat az útvonal kiterjesztésére, így a helyettesítő karaktereket és a tildéket az a héj a saját szabályai szerint kezeli. Az SFTP ehelyett fájlátviteli műveleteket ad ki, így a helyettesítő karaktert vagy a kliens terjeszti ki, vagy egyáltalán nem terjeszti ki. Mindkettő SSH-n belül ugyanarra a gépre utazik, ezért viselkedhet egy gazdagép másképp két kliens alatt.
A scp -v kiírja a kért alrendszert, és a sftp alrendszer-sor megerősíti, hogy a modern útvonal van használatban. A scp -O ott kényszeríti a régi protokollt, ahol támogatott és valóban szükséges, és magával hozza saját idézőjelszabályait. Ez nem VPN-beállítás, nem módja annak, hogy bármit engedélyezzen a kiszolgálón, és nem ok a gazdagépkulcs-ellenőrzés lazítására.
Tesztelje az útvonalat, mielőtt a szkript rá támaszkodna
Egy útvonalprobléma a lehető legrosszabb pillanatban bukkan fel, egy éjszakai automatizált feladatban, amikor senki sem figyel. Először egy kis fájllal és a feladat által használt pontos fiókkal bizonyítsa a célt, és tartsa a tesztparancsot a feladatdefiníció mellett. Ha a teszt másik fiókot vagy másik könyvtárat igényel, a feladatnak is szüksége lesz rá.
Ellenőrizze a kiszolgáló oldalát is. A grep -i subsystem /etc/ssh/sshd_config megmutatja, hogy be van-e állítva SFTP-alrendszer, és a sftp -b /dev/null [email protected] csak akkor lép ki sikeresen, ha az az alrendszer válaszol. Az a gazdagép, amely elfogadja az SSH-bejelentkezéseket, de nincs alrendszere, minden modern átvitelnél meghiúsul, miközben egy bejelentkezési tesztben teljesen egészségesnek tűnik.
Jegyezze fel a kliens verzióját, a használt protokollt és az abszolút távoli útvonalat a feladat megjegyzéseibe. Amikor a következő frissítés megváltoztat egy alapértelmezést, az a megjegyzés a különbség egy ötperces javítás és egy délutányi találgatás között.