SSH без пароля: аутентификация с помощью шифрованных ключей
Подключаться к серверу по SSH с паролем можно, но это не лучший вариант ни по безопасности, ни по удобству. Пароли подбирают брутфорсом, их повторно используют, они могут утекать или передаваться в мессенджерах. Аутентификация по ключам решает проблему иначе: у вас есть приватный ключ на вашем устройстве и публичный ключ на сервере. Сервер пускает только тех, кто способен доказать владение приватным ключом, при этом сам приватный ключ никогда не передаётся по сети.
Это особенно полезно, если вы администрируете несколько серверов, используете автоматические деплои, запускаете бэкапы или работаете в команде. Современные SSH-клиенты (OpenSSH в Linux/macOS, OpenSSH в Windows, PuTTY и др.) поддерживают ключи. Если инфраструктура построена на VPS, настройка ключей — один из первых шагов по укреплению безопасности. То же относится к выделенным серверам, а для простых веб-проектов часто выбирают хостинг, где SSH используется для администрирования и деплоя.
1) Как работают SSH-ключи (по делу)
Пара ключей состоит из приватного (только у вас) и публичного (на сервере). При подключении сервер отправляет “вызов”, а клиент подписывает его приватным ключом. Сервер проверяет подпись по публичному ключу из authorized_keys. Если всё совпало — вход разрешён. В результате пароль аккаунта не нужен, и большинство автоматических атак по подбору пароля теряют смысл, особенно если вы отключите PasswordAuthentication.
Приватный ключ обязательно защищайте passphrase. Это не противоречит идее “без пароля”: passphrase защищает файл ключа локально. Вы можете ввести passphrase один раз и хранить разблокированный ключ в ssh-agent, чтобы дальше подключаться без повторного ввода. Если злоумышленник украдёт файл приватного ключа, без passphrase использовать его будет существенно сложнее.
2) Генерация ключа (Linux/macOS/Windows OpenSSH)
В большинстве случаев рекомендуются ключи ed25519: современный алгоритм, короткий ключ, высокая безопасность. RSA иногда нужен для совместимости со старыми системами, но как “стартовый выбор” ed25519 обычно лучше. Генерируйте ключи на своём компьютере, не на сервере.
ssh-keygen -t ed25519 -a 64 -C "name@company"
Команда создаст два файла: приватный (например, ~/.ssh/id_ed25519) и публичный (например, ~/.ssh/id_ed25519.pub). Параметр -a увеличивает сложность derivation и помогает защититься, если ключ украдут. После генерации проверьте права: каталог ~/.ssh должен быть 700, приватный ключ — 600. Это важно, потому что sshd может игнорировать ключи при “слишком открытых” правах.
3) Установка публичного ключа на сервер
Самый простой способ — ssh-copy-id. Он автоматически добавит ваш публичный ключ в ~/.ssh/authorized_keys нужного пользователя и выставит корректные права.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip
Если ssh-copy-id нет, сделайте вручную: создайте ~/.ssh, вставьте публичный ключ в authorized_keys (одна строка = один ключ), выставьте права. Важно: в authorized_keys добавляется только публичный ключ, приватный туда не копируют.
mkdir -p ~/.ssh chmod 700 ~/.ssh nano ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
Затем протестируйте подключение с указанием ключа:
ssh -i ~/.ssh/id_ed25519 user@server-ip
Если всё настроено, сервер не попросит пароль пользователя. Возможен запрос passphrase локально (если ключ защищён и не загружен в агент).
4) ssh-agent: удобство без постоянного ввода
ssh-agent хранит разблокированные ключи в памяти, поэтому вы не вводите passphrase каждый раз. В Linux/macOS это стандартная практика, в Windows можно использовать службу OpenSSH Authentication Agent. Сценарий простой: запустили агент, добавили ключ, затем подключаетесь сколько угодно раз.
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
Помните про риск: если ваша сессия на компьютере доступна постороннему, а ключ загружен в агент, он сможет инициировать SSH-подключения. Поэтому используйте блокировку экрана, шифрование диска и разумные политики доступа.
5) Усиление безопасности сервера: отключаем пароли
Когда ключи работают, вы можете отключить вход по паролю и резко снизить “шум” атак. Публичные SSH-сервера постоянно сканируют и пытаются подобрать пароли. Если PasswordAuthentication выключен, большинство таких попыток становится бесполезным. Делайте это только после того, как проверили ключи и имеете резервный доступ (консоль у провайдера или другой канал).
В /etc/ssh/sshd_config установите примерно так:
PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no
После изменений перезапустите sshd:
sudo systemctl restart sshd
Дополнительные меры: запретить root-вход (PermitRootLogin no), создать отдельного админа и работать через sudo, ограничить доступ по IP или через VPN, а также добавить защиту от перебора (rate limit, fail2ban). Перенос порта SSH может снизить количество “мусорных” попыток, но это не замена настоящей безопасности.
6) Типовые ошибки и быстрая диагностика
Если сервер продолжает спрашивать пароль, проверьте: добавлен ли ключ именно тому пользователю, под которым вы входите; правильные ли права у ~/.ssh и authorized_keys; предлагает ли клиент правильный ключ. Очень часто проблема именно в правах или в том, что ключ добавили в чужой home.
Если видите “Permission denied (publickey)”, включите подробный режим:
ssh -vvv user@server-ip
На сервере проверьте логи аутентификации (например, /var/log/auth.log или journalctl). Сообщения типа “bad ownership or modes” почти всегда прямо указывают на ошибку. Также убедитесь, что вы не пытаетесь использовать ключ, который не соответствует публичному на сервере.
Если у вас много серверов и несколько ключей, используйте файл ~/.ssh/config. Он позволяет задать алиасы хостов, пользователя, путь к ключу и порт. Это уменьшает ошибки, ускоряет подключение и упрощает ротацию ключей.
Если вы работаете с Windows, можно использовать PuTTY или встроенный клиент OpenSSH. PuTTY традиционно использует формат PPK, поэтому ключи приходится конвертировать, либо проще перейти на Windows OpenSSH и держать единый формат ключей для всех систем. Унификация сильно упрощает поддержку, особенно в команде.
По алгоритмам: ed25519 — хороший выбор по умолчанию, но иногда из-за совместимости или требований безопасности просят RSA (например, 3072 или 4096 бит). Если используете RSA, избегайте устаревших настроек и убедитесь, что сервер и клиент поддерживают современные подписи. Практичный подход — основной ed25519 плюс резервный RSA для старых хостов.
Для автоматизации лучше разделять ключи по назначению: один ключ для администраторов-людей, другой — для деплоя, бэкапов или мониторинга. Так вы сможете отзывать доступ точечно и быстрее понимать, какой процесс использует какой ключ.
Можно ограничивать права ключа прямо в authorized_keys. Опции from="..." ограничивают IP-адреса, с которых разрешён вход, а command="..." принудительно запускает конкретную команду. Это идеально для бэкап-аккаунтов: разрешить только rsync и запретить интерактивную оболочку. Ограничения уменьшают ущерб даже при компрометации ключа.
Относитесь к ключам как к инвентарю: регулярно просматривайте authorized_keys, удаляйте устаревшие записи и ротируйте ключи при замене устройств или подозрении на утечку. Добавляйте понятные комментарии (имя, устройство, дата), чтобы через полгода не гадать, чей это ключ.
Если у вас много проектов и серверов, заведите стандарт именования ключей и аккуратный ~/.ssh/config. Это снижает риск случайно подключиться не к тому хосту и выполнить команды в неправильном окружении — такие ошибки встречаются чаще, чем взломы.
Дополнительно можно включить двухфакторную аутентификацию через PAM, но чаще практичный минимум — ключи + ограничение по IP/VPN + регулярные обновления. Главное — сделать безопасность удобной, иначе люди начнут искать обходные пути.
Хорошая практика — хранить резервный доступ: например, отдельный «break-glass» ключ, который лежит в защищённом хранилище и используется только при авариях. Такой ключ не должен быть на рабочих ноутбуках и не должен применяться в автоматизации. Это помогает восстановить доступ, если основная станция потеряна или ключи пришлось отозвать.
И ещё: не копируйте приватные ключи по почте и не храните их в репозиториях. Используйте менеджер секретов или зашифрованный диск, а для передачи доступа добавляйте только публичные ключи на сервер. Это простое правило закрывает множество реальных инцидентов.
Чек-лист и рекомендации для команды
Перед тем как отключать пароли, пройдите чек-лист: (1) проверьте вход по ключу минимум с двух устройств, (2) убедитесь, что приватный ключ защищён passphrase, (3) используйте ssh-agent для удобства, (4) отключите root-login и работайте через sudo, (5) ограничьте SSH доступ через firewall/VPN, (6) ведите список ключей: кто владелец, где используется, когда нужно удалить.
Для командной работы никогда не используйте один общий ключ. У каждого администратора должен быть свой ключ — так вы легко отзываете доступ, удаляя одну строку из authorized_keys. Для больших инфраструктур полезны централизованные процессы управления доступом и автоматизация конфигураций. Относитесь к ключам как к учётным данным: периодически проверяйте, ротируйте и удаляйте лишнее.