OpenSSH 10.6: что будет с прямым копированием scp между серверами

В OpenSSH 10.6 флаг scp -R ещё работает, но выдаёт предупреждение об устаревании. Его игнорирование объявлено для будущего выпуска без названной даты. Для владельца серверной автоматизации это повод проверить маршрут копирования и учётные данные: успешная передача файла сегодня не доказывает, что скрипт готов к будущему поведению.

Предупреждение уже есть, отключение ещё не объявлено состоявшимся

OpenSSH 10.6/10.6p1 выпущен 6 октября 2026 года. В разделе Future deprecation notice разработчики сообщают, что -R продолжит действовать с предупреждением в stderr. В будущем опция будет игнорироваться, оставляя обычное копирование через узел, на котором запущен scp. Не нужно превращать это заявление в новость об уже удалённом флаге.

Справка scp различает обычный путь между удалёнными узлами через локальный и режим -R: соединение с исходным узлом и запуск scp там. Во втором случае исходный узел должен иметь возможность авторизоваться на получателе без запроса пароля. Заглавная -R не означает рекурсивное копирование: для него используется строчная -r.

Три узла, которые надо подписать на схеме

Обозначим источник как S, получатель как D, а узел запуска задания как L. Это условные обозначения, не реальные имена серверов. Под L может пониматься рабочая станция или машина автоматизации. Слово «локальный» здесь относится к запуску scp, а не обязательно к ноутбуку администратора.

Таблица описывает смысл объявленного изменения и вопросы к инфраструктуре. Она не доказывает реальную сетевую топологию читателя. Прокси, ограничения соединений и поставки инструментов нужно учитывать по фактической настройке задания.

Почему код завершения и пустой stderr — разные условия

Автоматизация иногда принимает любое сообщение в stderr за неудачу, даже если файл доставлен. В другом проекте предупреждения вообще теряются в журнале. Оба варианта требуют проверки: в первом новая диагностика может запустить ненужный повтор, во втором команда не заметит приближающееся изменение поведения.

Наш совет — отдельно определить успех операции, обработку диагностических сообщений и основание для повторного запуска. Сравнивайте результат с ожидаемым файлом и согласованным местом назначения. Не скрывайте все сообщения ради красивого журнала: это уберёт наблюдаемость, но не зависимость скрипта.

Перенос маршрута может изменить требования к узлу запуска

В учебном примере задание запускается на небольшой машине автоматизации, которая раньше лишь инициировала прямую передачу. Если данные начнут идти через неё, надо проверить её сетевые ограничения и участие в обработке потока. Нельзя заранее обещать ни прежнюю скорость, ни определённую нагрузку без наблюдений.

Разберите также расположение полномочий. Наличие доступа у S к D не подтверждает доступ L к D, и наоборот. Не переносите ключи между узлами автоматически только ради восстановления старого сценария. Сначала согласуйте необходимый доступ, его владельца и применимость выбранного маршрута.

Как подготовить существующие задания

1. Найдите задания, которые действительно используют заглавную -R.
2. Определите S, D и L для каждого задания.
3. Уточните поставку клиента и применимые изменения у поддерживающего её поставщика.
4. Проверьте обработку предупреждений и повторов.
5. На разрешённых тестовых данных подтвердите обычный маршрут и его доступы.
6. Зафиксируйте результат, ограничения и план изменения автоматизации.

Номер upstream-выпуска не заменяет сведений о поддержке системного пакета. Не требуется вручную заменять рабочий SSH скачанной сборкой ради соответствия заголовку новости. Решение об обновлении учитывает поддерживаемую поставку и последующие исправления.

В сопровождении серверов заведите карту заданий копирования. Для переноса данных заранее согласуйте допустимый маршрут, а при автоматизации процессов опишите успех и повтор операции. SSH и scp в рамках этого материала не запускались, ключи не читались и файлы между серверами не передавались.