Безопасный SSH: аутентификация по ключу и отключение паролей

Кратко

Если вы открываете SSH-сервер в интернет, отключение аутентификации по паролю и переход на аутентификацию по ключам — обязательный шаг. В этой статье пошагово описано, как установить OpenSSH, сгенерировать ключи, перенести публичный ключ на сервер, отключить вход по паролю и дополнительно — усилить защиту, протестировать и восстановить доступ в экстренной ситуации.

Введение

SSH (Secure SHell) — это безопасный способ удалённого доступа к командной строке и файлам на сервере. Помимо доступа к shell, по SSH удобно передавать файлы, пробрасывать порты и монтировать удалённые диски. Но если вы открываете порт 22 наружу, попытки взлома паролей и автоматические брутфорс-атаки станут постоянными. Переход на аутентификацию по ключам резко снижает риск несанкционированного доступа.

Кому это нужно

Если вы форвардите порт 22 (или любой другой порт с SSH) наружу — эта инструкция для вас. Даже при «скрытом» сервере злоумышленники и сканеры всё равно проверяют открытые IP-адреса. Ключи дают два важнейших преимущества: а) защита от брутфорса паролей и б) возможность использовать защищённые ключи с паролем и аппаратные токены.

Основная идея аутентификации по ключам

Ключевая аутентификация базируется на криптографии с публичным ключом:

• Клиент генерирует пару ключей: приватный и публичный.
• Публичный ключ размещают на сервере в ~/.ssh/authorized_keys.
• При подключении сервер проверяет подпись, созданную приватным ключом, — без приватного ключа подделать подпись невозможно.

Коротко: публичный ключ безопасно хранится на сервере, приватный — только у клиента.

Раздел 1 Установка OpenSSH

Если SSH-сервер у вас уже работает, этот раздел можно пропустить. На большинстве дистрибутивов Linux установка сервера OpenSSH выполняется через менеджер пакетов. На Debian/Ubuntu это:

sudo apt-get update
sudo apt-get install openssh-server

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

sudo systemctl status ssh

На старых системах может использоваться команда service:

sudo service ssh status

Файл конфигурации демона — /etc/ssh/sshd_config. Для описания опций смотрите man sshd_config:

man sshd_config

Раздел 2 Генерация ключей

Создайте каталог .ssh в домашней папке, задайте права и сгенерируйте пару ключей. Современная рекомендация — использовать ed25519 (короче и безопаснее для типичных сценариев) или RSA 4096 бит, если требуется совместимость.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519
# или для совместимости
# ssh-keygen -t rsa -b 4096

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

Раздел 3 Перенос публичного ключа на сервер

Самый простой способ — команда ssh-copy-id (доступна на большинстве Unix-подобных систем):

ssh-copy-id username@host

Если ssh-copy-id недоступна, используйте безопасную передачу через SSH и перенаправление содержимого публичного ключа. Обратите внимание: в командной строке используйте одинарные кавычки, чтобы избежать конфликтов с JSON/Markdown при копировании:

cat ~/.ssh/id_ed25519.pub | ssh username@host 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

После выполнения команды вас попросят ввести пароль пользователя на целевом сервере. Если всё прошло успешно — публичный ключ окажется в ~/.ssh/authorized_keys на сервере.

Раздел 4 Отключение аутентификации по паролю

Чтобы полностью перейти на ключи, отредактируйте /etc/ssh/sshd_config на сервере и отключите PasswordAuthentication. Лучше также отключить разрешение входа под root и включить протокол 2.

Откройте файл в редакторе:

sudo nano /etc/ssh/sshd_config

Найдите и измените настройки:

Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

Сохраните изменения и перезапустите службу SSH. На современных системах:

sudo systemctl restart ssh

На других:

sudo service ssh restart

После перезапуска сервер примет только подключения по ключам — убедитесь, что у вас есть рабочая пара ключей и доступ к приватному ключу, иначе вы заблокируете себя.

Проверка и шаги на случай ошибок

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

Усиление безопасности SSH

Ниже — практические меры, которые дополняют переход на ключи:

• Ограничьте логин по пользователям: AllowUsers admin user1. Это предотвращает попытки входа за другими именами.
• Используйте файервол: откройте SSH только для нужных IP или сетей; на клиентских машинах — UFW/iptables.
• Перенесите порт SSH с 22 на другой нестандартный порт только как дополнение (не замена ключам).
• Включите двустороннюю аутентификацию с помощью аппаратных токенов (например, YubiKey) или FIDO2, если возможно.
• Установите fail2ban или аналог для ограничения попыток подключения и блокировки IP после ряда неудач.
• Регулярно проверяйте /var/log/auth.log (или systemd journal) на предмет подозрительных попыток.
• Используйте AllowGroups/AllowUsers и строгие права файлов ~/.ssh и ~/.ssh/authorized_keys.
• Для широких инфраструктур внедрите управление ключами (CA для SSH или централизованное хранение ключей).

Когда аутентификация по ключам не подходит

• Временно гостевой доступ с паролями (например, на публичных серверах с динамическими пользователями) — в таких случаях используйте временные пароли и автоматическую ротацию.
• Если вам необходима совместимость с устаревшими системами, которые не поддерживают ed25519 или FIDO, используйте RSA 4096.

Риски и методы их уменьшения

Управление ключами и жизненный цикл

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

Ролевые чек-листы

Администратор (владелец сервера)

• Установить OpenSSH и проверить версию.
• Настроить /etc/ssh/sshd_config: Protocol 2, PermitRootLogin no, PasswordAuthentication no.
• Настроить файервол и fail2ban.
• Обеспечить резервный доступ (консоль провайдера или KVM) на случай потери доступа.

Разработчик (пользователь с shell-доступом)

• Сгенерировать ключи и установить фразу-пароль.
• Передать публичный ключ через ssh-copy-id или безопасный канал.
• Проверить подключение по ключу до изменения конфигурации сервера.

Аудитор

• Проверить список активных ключей в ~/.ssh/authorized_keys и права доступа.
• Просмотреть логи попыток авторизации.

SOP для выдачи доступа новому пользователю

1. Получить запрос и обоснование доступа.
2. Попросить пользователя сгенерировать ключ: ssh-keygen -t ed25519.
3. Получить публичный ключ по защищённому каналу (не по email в открытом виде).
4. Добавить публичный ключ в ~/.ssh/authorized_keys с комментарием и отметить дату.
5. Прописать запись в реестре выданных ключей.
6. Проверить подключение и подтвердить права доступа.

Инцидентный план при компрометации ключа

1. Немедленно удалить соответствующий публичный ключ из ~/.ssh/authorized_keys.
2. Провести аудит логов (auth.log/journalctl) на предмет посторонних команд и сессий.
3. Если есть подозрение на создание бэкап-ключей на сервере — сменить все пароли, закрыть соединения, восстановить из надёжного бэкапа.
4. Переиздать ключи и уведомить затронутых пользователей.
5. Провести форензик-расследование и обновить правила выдачи ключей.

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

• После изменений подключение возможно только по ключу.
• Нет работающих подключений с паролем.
• Журнал авторизаций не показывает успешных входов с паролями после отключения.
• Права и проверки каталога ~/.ssh установлены корректно.

Тесты и примеры сценариев

• Тест 1: Попытка подключения с другого клиента без приватного ключа — должна быть отклонена.
• Тест 2: Подключение с приватным ключом, но без фразы-пароля (ключ не зашифрован) — подключение успешно.
• Тест 3: Подключение с зашифрованным приватным ключом — клиент должен запросить фразу-пароль.
• Тест 4: После удаления публичного ключа вход тем же приватным ключом — отклонён.

Совместимость и миграция

• ed25519 — рекомендуется по умолчанию, но не поддерживается в очень старых клиентах. RSA 4096 — хорошая совместимая альтернатива.
• При миграции на аппаратные токены учитывайте поддержку FIDO2 в OpenSSH и на клиентах.
• Перед массовым отключением паролей тестируйте на нескольких средах (тест/стейдж/прод).

Краткий глоссарий

• Публичный ключ — часть пары, которую можно безопасно разместить на сервере.
• Приватный ключ — секретная часть пары, должна храниться только у владельца.
• sshd_config — файл конфигурации демона OpenSSH.
• Authorized_keys — файл на сервере со списком доверенных публичных ключей.

Итог

Переход на аутентификацию по ключам и отключение паролей — один из самых эффективных способов повысить безопасность SSH. Важны не только базовые шаги (генерация ключей, перенос, отключение PasswordAuthentication), но и сопутствующие меры: управление ключами, мониторинг, ограничение доступа и подготовленный план на случай инцидента.

Примечания

• Если у вас есть вопросы по конкретным сценариям (YubiKey, централизованное CA для SSH, Windows-клиенты), опишите среду — добавлю конкретные команды и рекомендации.
• Изображения в статье служат иллюстрацией шагов: установка OpenSSH, генерация ключей и фрагмент конфигурации sshd_config.

Image credit: Shutterstock