scp преко SFTP-а: писање удаљених путања које се заиста решавају
Савремени scp преноси преко SFTP-а, па се проширење тилде и џокер знаци понашају другачије. Пишите експлицитне серверске путање и свесно бирајте протокол.
Команда scp која је годинама радила у скрипти може да не успе на савременом клијенту са грешком путање која нема никакве везе са тунелом. VPN је пренео бајтове; клијент је од сервера затражио име које сервер није могао да реши. Савремени OpenSSH scp подразумевано преноси преко SFTP-а, а SFTP не врши проширење у стилу љуске као стари протокол. Праћење команде од сопственог налога ка споља показује где се путања заиста тумачи.
Почните од налога, затим од директоријума у који може да пише
Двотачка раздваја два именска простора, и само лева страна припада машини на којој куцате. Све после ње решава сервер, под налогом којим сте се аутентификовали, унутар оног погледа на датотечни систем који тај налог има. Потврдите обоје пре састављања команде, јер путања која је исправна за администратора није аутоматски исправна за корисника преноса. Та разлика је извор већине грешака са дозволама које изгледају као мрежни кварови.
Питајте сервер за његов сопствени поглед: ssh [email protected] pwd и ssh [email protected] ls -ld /srv/archive. Ако друга команда пријави одбијену дозволу, тунел је у реду и путања је неупотребљива за тај налог. Исправите власништво или изаберите друго одредиште уместо да проширујете дозволе како би пренос могао да се настави.
Ограничена SFTP конфигурација може да представи chroot као корен датотечног система. Унутар тог погледа апсолутна путања је апсолутна унутар chroot-а, што није исто место које администратор види на хосту.
Именујте обе стране двотачке експлицитно
Отпремање треба да наведе удаљено име датотеке уместо да претпостави да ће локално основно име бити прихватљиво на другој страни.
scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csvПреузимање треба да наведе локално одредиште из потпуно истог разлога. Два именска простора су независна, а скрипта која претпоставља да се поклапају пуца први пут када удаљено стабло користи другачији распоред.
scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csvИзбегавајте ~otheruser у скрипти која се одржава. Проширење матичног директоријума другог налога је била функција удаљене љуске, а SFTP сервер можда не имплементира проширење које то емулира. Напишите апсолутну путању коју налог заиста може да отвори и ставите локалне путање са размацима под наводнике уместо да копирате слојеве наводника написане за љуску на серверу.
Знајте који протокол ваш scp заиста користи
Од OpenSSH 9.0 клијент подразумевано користи SFTP, а дистрибуције то понашање прихватају или преносе уназад по сопственом распореду. Низ верзије говори шта клијент намерава, али градња добављача може да се разликује од upstream-а, зато проверите клијент који заиста покрећете: ssh -V.
Два протокола различито решавају имена. Стари SCP тражи од удаљене корисничке љуске да прошири путању, па џокер знаке и тилде обрађује та љуска по својим правилима. SFTP уместо тога издаје операције преноса датотека, па џокер знак или проширује клијент или се уопште не проширује. Оба путују унутар SSH-а до исте машине, због чега се један хост може понашати другачије под два клијента.
scp -v исписује подсистем који захтева, а ред подсистема sftp потврђује да се користи савремена путања. scp -O намеће стари протокол тамо где је подржан и заиста потребан, и са собом враћа сопствена правила наводника. То није VPN опција, није начин да се нешто омогући на серверу и није разлог да се олабави провера кључа хоста.
Тестирајте путању пре него што се скрипта на њу ослони
Проблем са путањом се појави у најгорем могућем тренутку, у аутоматизованом послу ноћу без икога да гледа. Прво докажите одредиште малом датотеком и тачним налогом који посао користи, и држите ту тест команду уз дефиницију посла. Ако тесту треба други налог или други директоријум, требаће и послу.
Проверите и серверску страну. grep -i subsystem /etc/ssh/sshd_config показује да ли је SFTP подсистем конфигурисан, а sftp -b /dev/null [email protected] завршава успешно само када тај подсистем одговори. Хост који прихвата SSH пријаве али нема подсистем пада на сваком савременом преносу док у тесту пријаве изгледа потпуно здраво.
Забележите верзију клијента, протокол који се користи и апсолутну удаљену путању у белешке посла. Када следеће ажурирање промени подразумевано, та белешка је разлика између петоминутне поправке и поподнева нагађања.