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, але не має підсистеми, зазнає невдачі при кожному сучасному передаванні, хоча в тесті входу виглядає цілком здоровим.

Запишіть версію клієнта, використовуваний протокол і абсолютний віддалений шлях у нотатках завдання. Коли наступне оновлення змінить типове значення, ця нотатка стане різницею між п'ятихвилинним виправленням і днем здогадів.