SSH-ключи и 2FA
SSH — главный вход на сервер. Через него работают администраторы, выгружаются данные, деплоятся приложения. И именно SSH — главная цель атакующих: боты круглосуточно подбирают пароли, сканируют порты, пытаются взломать доступ. Если у вас слабый пароль и стандартный порт — сервер взломают в течение недели.
Хорошая новость: защитить SSH просто и эффективно. SSH-ключи, отключение паролей, смена порта, 2FA — всё это базовые меры, которые закрывают 99% атак. В этой статье — разбор безопасного доступа к серверу по SSH. Если нужно настроить безопасный доступ по SSH — поможем.
Зачем защищать SSH
SSH открыт в интернет, чтобы вы могли подключаться к серверу. Но это значит, что он доступен всем, включая атакующих.
Брутфорс
Боты подбирают пароли круглосуточно. Слабый пароль взламывается за часы. В логах — десятки тысяч попыток в день.
Уязвимости SSH
В самом SSH и его окружении периодически находят уязвимости. Регулярные обновления обязательны.
Слабые учётные записи
Дефолтные логины root/admin, простые пароли, забытые учётные записи — всё это путь для взлома.
Компрометация ключей
Если ключ утёк — атакующий получает доступ. Нужны защита ключей и их ротация.
SSH-ключи
SSH-ключи — это пара: приватный и публичный ключ. Публичный кладётся на сервер, приватный остаётся у вас. Подобрать приватный ключ невозможно — это математически сложная задача.
Типы ключей
- RSA: классический, но требует больших ключей для безопасности;
- Ed25519: современный, компактный, быстрый, безопасный — оптимальный выбор;
- ECDSA: вариант на эллиптических кривых, но с некоторыми вопросами безопасности;
- DSA: устаревший, не использовать.
Преимущества ключей перед паролями
- Не подобрать: Ed25519 — 256 бит энтропии, брутфорс невозможен;
- Нет передачи по сети: пароль передаётся, ключ — нет;
- Удобно: можно настроить беспарольный вход с ключом (без потери безопасности);
- Автоматизация: скрипты, CI/CD, деплой — всё через ключи;
- Управление: можно отозвать ключ, не меняя пароли у всех.
Что нужно помнить
- Приватный ключ — секрет: не передавать, не хранить в git, не оставлять без пароля;
- Резервные ключи: всегда иметь второй ключ на случай потери основного;
- Ротация: менять ключи при смене сотрудников;
- Разные ключи: отдельный ключ для каждого сервера или группы серверов.
Настройка ключей
1. Генерация ключа
На клиентской машине:
ssh-keygen -t ed25519 -C "user@example.com"- -t ed25519: тип ключа;
- -C: комментарий (обычно email);
- Пароль: спросит пароль для защиты ключа — рекомендуется установить;
- Файлы: приватный ~/.ssh/id_ed25519, публичный ~/.ssh/id_ed25519.pub.
2. Копирование публичного ключа на сервер
Самый простой способ:
ssh-copy-id user@serverИли вручную:
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"3. Проверка входа по ключу
ssh user@serverЕсли система не запросила пароль от пользователя (только от ключа, если он был установлен при генерации) — ключ работает.
4. Права на файлы
- ~/.ssh: 700;
- ~/.ssh/authorized_keys: 600;
- Приватный ключ: 600.
Если права неверные — SSH откажется использовать ключ.
💡 Важно
Перед отключением паролей убедитесь, что вход по ключу работает. Иначе потеряете доступ к серверу.
Отключение паролей
После настройки ключей пароли можно отключить. Это закрывает возможность брутфорса.
Правки в /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM noДополнительные настройки
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 20- PermitRootLogin no: запрет прямого входа под root;
- MaxAuthTries: максимум попыток аутентификации;
- LoginGraceTime: время на аутентификацию.
Перезапуск SSH
systemctl restart sshdПеред перезапуском оставьте текущую сессию открытой — если что-то пойдёт не так, сможете исправить.
Смена порта
По умолчанию SSH слушает порт 22. Боты сканируют его постоянно. Смена порта не делает SSH неуязвимым, но снижает количество автоматических атак в разы.
Правки в /etc/ssh/sshd_config
Port 22022Порядок действий
- Выберите порт: от 1024 до 65535, не занятый другими сервисами;
- Правка конфига: указать новый порт;
- Открыть в файрволе: добавить правило для нового порта;
- Проверить: подключиться на новый порт из другой сессии;
- Перезапустить SSH: если проверка прошла успешно;
- Закрыть старый порт: только после успешного переключения.
Подключение на новом порту
ssh -p 22022 user@server💡 Важно
Перед сменой порта убедитесь, что новый порт открыт в файрволе. Иначе после перезапуска SSH вы потеряете доступ.
Двухфакторная аутентификация
2FA добавляет второй фактор: даже если кто-то получит ваш ключ — войти без одноразового кода не сможет.
Установка
На сервере:
apt install libpam-google-authenticator
google-authenticatorУтилита задаст несколько вопросов, сгенерирует секретный ключ и QR-код. Сканируйте QR-код в приложении Google Authenticator или Яндекс.Ключ.
Настройка PAM
В файле /etc/pam.d/sshd:
auth required pam_google_authenticator.soНастройка SSH
В /etc/ssh/sshd_config:
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactiveТеперь при подключении SSH запросит и ключ, и одноразовый код.
Что важно
- Сохраните резервные коды: они показываются один раз, пригодятся при потере телефона;
- Не блокируйте себя: проверяйте в отдельной сессии;
- Для админов: обязательно, для остальных — по возможности.
Аппаратные ключи
Аппаратные ключи — это физические устройства для 2FA. Устройство нельзя скопировать, оно всегда с вами.
YubiKey
- Поддержка: FIDO2, U2F, OTP, PIV;
- Работа с SSH: через FIDO2 или GPG;
- Плюсы: невозможно фишинговать, не зависит от телефона;
- Минусы: цена, потеря устройства требует запасного ключа;
- Рекомендация: два ключа — основной и резервный.
Настройка
ssh-keygen -t ed25519-sk -C "user@example.com"- -sk: security key (FIDO2);
- Требует: OpenSSH 8.2+, YubiKey 5 или аналог;
- При подключении: нужно нажать на кнопку на ключе.
Когда использовать
- Для администраторов: максимальный уровень защиты;
- Для критичных серверов: финтех, медицина, госсектор;
- Для удалённых сотрудников: меньше риска, чем с телефоном.
Ошибки
Отключили пароли без ключа
Забыли добавить ключ, отключили пароли — потеряли доступ. Проверяйте в отдельной сессии.
Неверные права на файлы
SSH отказывается использовать ключ из-за неверных прав. .ssh — 700, authorized_keys — 600.
Один ключ на всё
Один ключ для всех серверов и сотрудников. Утечка — компрометация всей инфраструктуры.
Ключ без пароля
Приватный ключ не защищён паролем. Украли ноутбук — получили доступ к серверам.
Не сменили порт
Стандартный порт 22 — цель ботов. Смена порта не панацея, но снижает нагрузку.
Нет 2FA
Даже с ключами 2FA добавляет уровень защиты. Особенно для администраторов.
Root разрешён
PermitRootLogin yes — прямой доступ под root. Запретить обязательно.
Забыли про ротацию
Ключи бывших сотрудников остаются рабочими. При уходе — удалять из authorized_keys.
Чек-лист защиты SSH
Ключи
- Ed25519 вместо RSA
- Пароль на приватный ключ
- Отдельный ключ на каждого
- Резервный ключ
- Права 600 на ключ
Конфигурация
- PasswordAuthentication no
- PermitRootLogin no
- MaxAuthTries 3
- Нестандартный порт
- LoginGraceTime 20
2FA и контроль
- 2FA для администраторов
- Аппаратные ключи для критичных
- Fail2ban на SSH
- Логирование входов
- Мониторинг аномалий
Процессы
- Учёт ключей сотрудников
- Удаление при уходе
- Регулярная ротация
- Документированные доступы
- Регулярный аудит
Наши рекомендации
Что вы получаете, заказывая настройку SSH у нас
- SSH-ключи — Ed25519 с паролем
- Отключение паролей — защита от брутфорса
- Смену порта — снижение автоматических атак
- 2FA — для администраторов
- Fail2ban — блокировка атакующих
- Мониторинг — логирование входов
📌 Итоговый вывод
SSH-ключи и 2FA — это базовая защита доступа к серверу.
Что нужно знать:
- Зачем — SSH главная цель атакующих, без защиты сервер взломают
- SSH-ключи — Ed25519, пароль на приватный ключ
- Настройка — ssh-keygen, ssh-copy-id, права 600
- Отключение паролей — PasswordAuthentication no
- Смена порта — снижает автоматические атаки
- 2FA — Google Authenticator или Яндекс.Ключ
- Аппаратные ключи — YubiKey для критичных систем
- Ошибки — нет ключа, нет прав, root разрешён, нет 2FA
Также рекомендуем: 152-ФЗ для серверов, аудит безопасности, Fail2ban, файрвол на сервере, с чего начать защиту, настройка безопасности.