Копирование файлов по SSH без ввода пароля

Кратко

Эта статья показывает, как безопасно копировать файлы между компьютерами по SSH без ввода пароля, используя пары ключей и scp. Приведены команды, шаблоны, проверочные списки для ролей и рекомендации по повышению безопасности.

Быстрые ссылки

• Копирование файлов по SSH
• SSH и SCP без паролей
• Соображения безопасности

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

Подход работает на Linux и macOS при включённом SSH. На Windows удобно использовать WSL или Cygwin, а также встроенный OpenSSH в современных версиях Windows 10/11.

Основная идея

Краткое определение: scp — утилита для защищённого копирования файлов поверх протокола SSH. Она копирует файлы и каталоги между локальной машиной и удалённым сервером или между двумя удалёнными серверами.

Формат команды

Общий формат:

scp [опции] исходный_файл назначение

При указании удалённого файла синтаксис выглядит так:

пользователь@сервер:путь/до/файла

Сервер может быть доменным именем или IP-адресом. После двоеточия идёт путь к файлу или каталогу на удалённой машине.

Пример загрузки файла на удалённый сервер с указанием нестандартного порта:

scp -P 40050 Desktop/url.txt yatri@192.168.1.50:~/Desktop/url.txt

Примечание: флаг для порта — это заглавная буква P. Если порт не указан, используется 22.

Скачать файл с удалённого сервера

Чтобы сделать обратное, скопировать файл с удалённой машины на локальную, меняют местами источник и назначение:

scp -P 40050 yatri@192.168.1.50:~/Desktop/url.txt ~/Desktop/url.txt

Копирование каталогов

Для рекурсивного копирования каталога используйте опцию -r:

scp -r папка/ yatri@192.168.1.50:~/backup/папка/

Флаги можно комбинировать в одном наборе, например:

scp -Pr файл yatri@сервер:~/путь/

Важно: автодополнение путей через табуляцию может не работать для путей на удалённом сервере. Часто удобно иметь второй терминал с открытой SSH-сессией для проверки путей.

SSH и SCP без пароля: пары ключей

Чтобы избавиться от запроса пароля, используют пару ключей: приватный ключ хранится на клиенте и должен оставаться в безопасности, публичный ключ помещается на сервер. При корректной настройке аутентификация по ключу заменяет ввод пароля.

Генерация ключей

На локальной машине запустите генератор ключей:

ssh-keygen -t rsa

По умолчанию пары ключей сохранятся в директории ~/.ssh/ с именами id_rsa для приватного ключа и id_rsa.pub для публичного. При запросе места сохранения можно нажать Enter, чтобы принять значение по умолчанию. При запросе фразы-пароля можно ввести её либо оставить пустой; рекомендовано задавать надёжную фразу-пароль для повышения безопасности.

Современная рекомендация: вместо rsa можно использовать ed25519 для более коротких и современных ключей, например ssh-keygen -t ed25519. Однако некоторые старые серверы могут не поддерживать ed25519.

Копирование публичного ключа на сервер

Самый простой способ скопировать публичный ключ на сервер — использовать утилиту ssh-copy-id либо scp. Пример с scp:

scp ~/.ssh/id_rsa.pub yatri@192.168.1.50:~/

Затем на сервере надо включить содержимое id_rsa.pub в файл авторизованных ключей. Традиционное местоположение — ~/.ssh/authorized_keys. В старой документации встречается authorized_keys2, но современный стандарт использует authorized_keys.

На сервере:

mkdir -p ~/.ssh
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
rm ~/id_rsa.pub

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

Повышение безопасности при использовании ключей

• Всегда храните приватные ключи с правами 600 и директорий ~/.ssh с правами 700.
• Используйте фразу-пароль для приватного ключа и ssh-agent для кэширования расшифрованного ключа в течение сессии.
• По возможности используйте ed25519 вместо rsa при поддержке сервером.
• Храните приватные ключи в зашифрованном контейнере, если рабочая машина используется не только вами.

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

Комбинирование ключа и пароля

Можно задать фразу-пароль для приватного ключа. Тогда при первом использовании ключа в сессии требуется ввод фразы-пароля, последующие соединения станут возможны без ввода до закрытия сессии, если используется ssh-agent.

Когда это не работает: распространённые причины

• На сервере отключена аутентификация по ключам в конфигурации SSHD (опция PubkeyAuthentication no).
• Неправильные права на файлы или директорию ~/.ssh на сервере или на клиенте.
• Публичный ключ записан с ошибкой или в неправильном месте (не в authorized_keys).
• Вы используете другой пользовательский аккаунт на сервере, чем тот, для которого добавлен ключ.
• На сервере работает строгая политика, ограничивающая доступ по IP или требующая двухфакторной аутентификации.

Дополнительные меры безопасности и hardening

• Отключите вход под root по SSH, используйте sudo вместо этого.
• В файле authorized_keys можно для каждой строки ключа указывать опции ограничений, например no-port-forwarding,no-agent-forwarding,command=… или from=”ip1,ip2” для ограничения источников.
• При компрометации приватного ключа немедленно удалите соответствующий публичный ключ из authorized_keys на всех серверах.
• Используйте fail2ban или подобные механизмы для блокировки частых неудачных попыток входа.

Пример строки с ограничениями в authorized_keys:

no-port-forwarding,no-agent-forwarding,from="192.0.2.0/24" ssh-rsa AAAA... user@example

Когда лучше не использовать автоматическое подключение по ключу

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

Практические шаблоны и шпаргалка команд

Подсказки для частых задач:

• Скопировать файл на сервер с нестандартным портом:

scp -P 2222 localfile.txt user@host:/remote/path/

• Скопировать каталог рекурсивно:

scp -r projects/ user@host:/backup/projects/

• Скопировать файл с сервера на локальную машину:

scp user@host:/remote/path/file.txt ~/local/path/

• Сгенерировать ключ ed25519:

ssh-keygen -t ed25519

• Использовать ssh-agent и добавить ключ в агент:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

Роли и контрольные списки

Для администратора сервера:

• Убедиться, что в /etc/ssh/sshd_config разрешена аутентификация по ключам (PubkeyAuthentication yes).
• Проверить права на ~/.ssh и authorized_keys.
• Включить логирование и мониторинг попыток входа.

Для разработчика или оператора, пишущего скрипты:

• Генерировать отдельную пару ключей для каждого сервиса или машины.
• Использовать ssh-agent в CI/CI runner или безопасное хранилище секретов для приватных ключей.
• Добавлять ограничения в authorized_keys при необходимости.

Критерии приёмки

• После настройки scp не требует ввода пароля при подключении с конкретной машины.
• Права на файлы и директории настроены корректно: ~/.ssh 700, authorized_keys 600.
• На сервере ключ добавлен в authorized_keys и проходит проверку в логе SSH без ошибок.
• При компрометации приватного ключа соответствующий публичный ключ удалён с сервера.

Контрольный список распространённых ошибок и способы их решения

• Ошибка доступа denied publickey: проверить права и корректность содержимого authorized_keys.
• Постоянный запрос пароля: проверить, используется ли тот же пользователь и ключ находится в ~/.ssh.
• Автоматизированная задача не видит ключ: убедиться, что ssh-agent запущен в среде, где выполняется задача, или использовать ключ с фразой-паролем в защищённом хранилище.

Альтернативные подходы

• rsync по SSH для синхронизации с дельтой изменений, экономит трафик при крупных каталогах.
• sftp как интерактивный клиент или библиотека для приложений.
• Использование специализированных инструментов резервного копирования с встроенным управлением ключами и ротацией.

Заключение

Использование пар ключей SSH для scp делает передачу файлов удобной и безопасной при соблюдении правил обращения с приватными ключами. Это особенно полезно для скриптового резервного копирования и автоматизации. Внедряя ограничения в authorized_keys и комбинируя ключи с фразой-паролем и ssh-agent, можно получить баланс между удобством и безопасностью.

Фактические шаги для старта:

1. Сгенерировать пару ключей на клиенте: ssh-keygen -t rsa или ssh-keygen -t ed25519
2. Перенести публичный ключ на сервер и добавить в ~/.ssh/authorized_keys
3. Проверить права и попробовать подключиться вручную
4. Настроить автоматические задачи с использованием ключа или ssh-agent

Были ли у вас сценарии, где scp использовался в скриптах? Используете ли вы ключи вместо паролей на рабочем месте? Поделитесь опытом в комментариях.