Как настроить SSH‑сервер с аутентификацией по ключам и отключить пароли

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

Если вы пробрасываете порт 22 через роутер или у вас сервер доступен в интернете, вам нужна защита от автоматизированных переборов паролей и ботнетов. Даже для домашнего медиасервера или личного VPS стоит отказаться от аутентификации по паролю в пользу ключей.

Важно: если вы отключаете пароли, обязательно убедитесь, что у вас есть рабочая пара ключей и способ доступа в случае ошибки (консоль хоста, панель провайдера, второй пользователь с доступом и т. п.).

Как это работает — коротко

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

Однострочное определение терминов:

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

План действий (обзор)

1. Установить OpenSSH‑сервер на хосте.
2. Сгенерировать пару ключей на клиенте.
3. Скопировать публичный ключ на сервер в ~/.ssh/authorized_keys.
4. Отключить аутентификацию по паролю в /etc/ssh/sshd_config.
5. Дополнительное усиление: брандмауэр, fail2ban, запрет root, ограничение пользователей.

1. Установка OpenSSH на Ubuntu/Debian

Если у вас уже есть SSH‑сервер, переходите к разделу генерации ключей.

Используйте пакетный менеджер:

sudo apt-get install openssh-server

После установки конфигурационный файл находится по пути:

/etc/ssh/sshd_config

Запустите справку, чтобы увидеть параметры:

man sshd_config

ALT описывает изображение: “Терминал установки OpenSSH на Ubuntu”.

Совет: на современных системах перезапуск производится через systemd:

sudo systemctl restart sshd

(На некоторых дистрибутивах служба называется ssh, тогда systemctl restart ssh.)

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

Создайте директорию и задайте права:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Рекомендуемые варианты ключей:

• ed25519 — современный, компактный и быстрый вариант.
• rsa 4096 — совместим с очень старыми системами.

Примеры команд:

ssh-keygen -t ed25519 -C "your_email@example.com"
# или, если нужен RSA:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Пояснение: вас попросят указать путь для сохранения (по умолчанию ~/.ssh/id_ed25519 или id_rsa) и ввести passphrase. Passphrase защищает приватный ключ на диске — используйте устойчивую фразу, но такую, которую вы помните.

ALT описывает изображение: “Процесс генерации SSH ключей в терминале macOS или Linux”.

Совет по удобству: используйте ssh‑agent и ssh‑add, чтобы не вводить passphrase каждый раз:

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

На macOS и некоторых Linux‑средах можно настроить хранение ключа в системе‑хранилище, но учитывайте угрозы локального компромета.

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

Самый простой способ при наличии ssh‑copy‑id:

ssh-copy-id username@host

Если ssh‑copy‑id недоступен, можно скопировать вручную:

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

Проверьте права на сервере:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
# ожидаемые права: ~/.ssh — 700, authorized_keys — 600

После этого попробуйте подключиться по ключу:

ssh username@host

Если всё в порядке, аутентификация выполнится без запроса пароля для аккаунта (при наличии passphrase вас попросят расшифровать приватный ключ, если ssh‑agent не активирован).

4. Отключение аутентификации по паролю и базовое усиление SSH

Откройте конфигурационный файл SSH:

sudo nano /etc/ssh/sshd_config

Найдите и убедитесь в следующих настройках (приведите строки в таком виде):

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
# (опция) AllowUsers alice bob
AuthorizedKeysFile %h/.ssh/authorized_keys

Если вы используете Ubuntu с systemd, перезапустите:

sudo systemctl restart sshd

На старых системах может быть команда:

sudo restart ssh

Проверьте статус службы:

sudo systemctl status sshd
# и логи аутентификации
sudo journalctl -u sshd --no-pager -n 200
# либо
sudo tail -n 200 /var/log/auth.log

ALT описывает изображение: “Фрагмент содержимого конфигурационного файла /etc/ssh/sshd_config”.

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

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

1. Смена порта слушания SSH (не панацея, но уменьшает количество автоматических сканов):

# В /etc/ssh/sshd_config
Port 2222

После изменения порта откройте его в брандмауэре и перезапустите sshd.

2. Ограничение по пользователям и IP: AllowUsers или firewall rules.

3. fail2ban — блокирует IP после нескольких неудачных попыток.

sudo apt-get install fail2ban
# и настройте /etc/fail2ban/jail.local

4. Брандмауэр UFW:

sudo ufw allow 22/tcp
# или, если порт 2222
sudo ufw allow 2222/tcp
sudo ufw enable

5. Отключите пересылку пароля для root:

PermitRootLogin no

6. Мониторинг и логирование: следите за /var/log/auth.log и оповещениями fail2ban.

7. Используйте аппаратные ключи (FIDO, YubiKey) для максимальной защиты приватного ключа, если нужна высокая степень надёжности.

Технические сценарии и когда это НЕ подходит

Контрпример: если у вас много временных пользователей, которым нужен мгновенный доступ по паролю (например, публичная учебная система), отключение паролей потребует дополнительной системы управления ключами и может усложнить процессы.

Когда ключи неудобны:

• Удалённый доступ через устройства, которыми вы не управляете (интернет‑кафе), где вы не можете безопасно хранить приватный ключ.
• Сценарии массового provisioning без системы управления конфигурацией — там нужны централизованные решения (Ansible, Vault, LDAP/SSSD).

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

• Двухфакторная аутентификация PAM + пароль.
• Централизованная авторизация через Kerberos/LDAP.

Проверки, тесты и критерии приёмки

Критерии приёмки для успешной настройки:

• Установлен SSH сервер и доступен локально.
• Публичный ключ присутствует в ~/.ssh/authorized_keys и имеет права 600.
• Сервер принимает вход по ключу и отвергает вход по паролю.
• Логи не содержат ошибок при перезапуске sshd.

Тесты:

• Попытка входа с рабочего клиента: ssh username@host (ожидается успешный вход по ключу).
• Попытка входа с другого клиента без ключа: ожидание отказа.
• Проверка журнала: sudo tail -n 50 /var/log/auth.log на предмет отказов.

Инцидентный план: что делать, если вы потеряли доступ

1. Попробуйте панель управления хоста или консоль провайдера (VPS панель часто даёт доступ даже при некорректном sshd_config).
2. Если есть физический доступ — загрузитесь в single‑user mode или live‑CD и восстановите /etc/ssh/sshd_config и authorized_keys.
3. Если у вас есть второй пользователь на сервере с sudo — войдите через него и исправьте конфигурацию.
4. В крайнем случае — восстановление из бэкапа конфигурации.

Чек-листы по ролям

Администратор (перед развёртыванием):

• Проверить совместимость OpenSSH на клиенте и сервере.
• Создать и протестировать ключи на тестовом хосте.
• Настроить брандмауэр и fail2ban.
• Обновить документацию доступа и сохранить резервные ключи.

Домашний пользователь:

• Сгенерировать ed25519 ключ и добавить на сервер.
• Включить ssh‑agent для удобства.
• Отключить PasswordAuthentication только после теста.

DevOps / автоматизация:

• Интегрировать процесс в Ansible/Terraform, хранить секреты в Vault.
• Автоматически разворачивать ключи через защищённый канал.

Краткая шпаргалка команд

# Создать директорию и права
mkdir -p ~/.ssh && chmod 700 ~/.ssh

# Генерация ключа
ssh-keygen -t ed25519 -C "you@domain"

# Копирование ключа
ssh-copy-id username@host
# или вручную
cat ~/.ssh/id_ed25519.pub | ssh username@host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

# Перезапуск службы
sudo systemctl restart sshd
# проверка статуса
sudo systemctl status sshd

# Диагностика соединения
ssh -vvv username@host
sudo tail -n 200 /var/log/auth.log

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

• Если сервер старый и не поддерживает ed25519, используйте rsa 4096.
• OpenSSH 7.8+ полноценно поддерживает современные ключи и крипртонастройки; проверьте версии перед сменой формата.

1‑строчный глоссарий

• Public key: открытая часть ключа, размещаемая на сервере.
• Private key: файл, хранящийся только у клиента, даёт доступ.
• Passphrase: пароль для защиты приватного ключа.
• authorized_keys: файл на сервере со списком доверенных публичных ключей.

Итог и призыв к действию

Аутентификация по ключам — простой и эффективный способ защитить SSH‑доступ. Начните с генерации пары ключей и тестовой копии публичного ключа на сервере. Отключайте пароли только после проверки работоспособности ключей и наличия резервного плана на случай ошибки.

Напишите в комментариях, для чего вы используете SSH: удалённая оболочка, безопасный FTP (SFTP), проксирование портов или что‑то ещё.

Image credit: Shutterstock