Безопасный SSH на Linux в 2026: ключи, MFA и минимальные права

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

Смена стандартного порта уменьшает количество автоматического шума в логах, но не устраняет ни одну ключевую угрозу. Сканер найдёт нестандартный порт, украденный ключ продолжит работать, а лишний sudo останется лишним sudo. Ниже — конфигурация, которую можно адаптировать для Ubuntu 24.04 LTS, Debian 12 и других актуальных дистрибутивов с OpenSSH.

Модель угроз для SSH

• перебор или утечка пароля;
• кража приватного ключа с компьютера администратора;
• забытый доступ бывшего сотрудника или подрядчика;
• прямой вход root без персонального аудита;
• ошибка firewall, открывающая SSH всему интернету;
• компрометация агента пересылки ключей;
• блокировка легитимного администратора после неудачного изменения.

Настройки нужно вводить поэтапно. Не отключайте пароль, пока не проверили вход по ключу в отдельной сессии. Не перезапускайте sshd до проверки конфигурации. На VPS полезно заранее убедиться, что у провайдера есть web-консоль или режим восстановления.

Создание ключа Ed25519

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_work
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub admin@example.com

Ed25519 — современный компактный алгоритм, подходящий для обычных административных ключей. Закройте приватный ключ длинной passphrase. Публичный файл с расширением .pub можно передавать серверу; приватный — нельзя загружать в почту, мессенджер, Git или панель хостинга.

Для критичных систем используйте аппаратный ключ FIDO2:

ssh-keygen -t ed25519-sk -O resident -O verify-required

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

Отдельный административный пользователь

sudo adduser admin
sudo usermod -aG sudo admin
sudo -l -U admin

Не используйте один общий аккаунт для команды. Персональные учётные записи позволяют отозвать конкретный доступ и понять, кто выполнял действие. В sudoers выдавайте только необходимые команды, используя visudo. Безусловное разрешение ALL=(ALL) NOPASSWD:ALL удобно, но фактически превращает аккаунт в root без дополнительного контроля.

Настройка через sshd_config.d

На современных системах удобнее создать отдельный drop-in, например /etc/ssh/sshd_config.d/60-hardening.conf, чем редактировать большой пакетный файл.

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowAgentForwarding no
AllowUsers admin deploy

AllowAgentForwarding no подходит, если пересылка агента действительно не нужна. Не копируйте параметр вслепую: CI/CD или bastion-сценарий может зависеть от него. Проверка перед применением обязательна:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|maxauthtries'

reload аккуратнее полного restart: существующие сессии обычно остаются активными. Всё равно держите резервное соединение, пока новый вход не проверен.

Ограничение SSH по сети

Лучший публичный SSH — тот, который доступен только из сети управления. Если у администратора стабильный IP, ограничьте источник через firewall. В остальных случаях используйте WireGuard, корпоративный VPN или bastion-host.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Адрес в примере зарезервирован для документации — замените его своей сетью. Перед включением UFW обязательно добавьте правило для текущего подключения и проверьте консоль восстановления.

MFA для административного доступа

MFA снижает риск использования украденного ключа. Возможные варианты: аппаратный FIDO2-ключ, PAM-модуль с одноразовыми кодами или централизованный identity provider через bastion. Не смешивайте несколько схем без тестов: неверное сочетание AuthenticationMethods способно заблокировать всех пользователей.

Для команды предпочтительнее централизованный доступ с жизненным циклом учётных записей, чем ручное копирование ключей на десятки серверов. Краткоживущие SSH-сертификаты ещё лучше: доступ автоматически истекает и не требует чистить каждый authorized_keys.

Защита от перебора

Fail2ban может блокировать повторяющиеся попытки, но остаётся дополнительной мерой. Основная защита — отсутствие парольного входа и сетевое ограничение. Слишком агрессивные правила fail2ban создают самоотказ и блокируют NAT-адрес офиса.

journalctl -u ssh --since today
lastb -ai
last -ai
ss -tnp | grep ':22'

Аудит ключей и доступов

Проводите регулярную ревизию файлов authorized_keys, групп sudo и активных пользователей. Для каждого ключа полезно указывать комментарий с владельцем и назначением. Ключи CI/CD отделяйте от человеческих и ограничивайте через from=, command= и запрет forwarding, если сценарий это допускает.

getent group sudo
sudo find /home /root -path '*/.ssh/authorized_keys' -type f -ls
sudo journalctl -u ssh --since '7 days ago'

Что делать при потере или компрометации ключа

1. удалить публичный ключ из всех authorized_keys;
2. проверить историю входов и команды sudo;
3. сменить токены и секреты, доступные аккаунту;
4. проверить новые пользователи, cron, systemd units и сетевые правила;
5. при подозрении на root-компрометацию пересоздать сервер из доверенного образа;
6. выпустить новый ключ и задокументировать инцидент.

Проверочный чеклист

• вход по новому ключу проверен;
• парольная аутентификация отключена;
• root не входит напрямую;
• список AllowUsers актуален;
• SSH ограничен VPN или разрешёнными сетями;
• есть MFA для критичных узлов;
• логи уходят в централизованное хранилище;
• доступ можно восстановить через консоль провайдера.

Клиентская конфигурация и проверка отпечатка

Защита SSH начинается и на рабочей станции. Не отключайте проверку host key через StrictHostKeyChecking no: это открывает путь атаке посредника. При первом подключении сравните отпечаток ключа сервера с данными из доверенного канала или консоли провайдера. Если ключ неожиданно изменился, сначала выясните причину — переустановка сервера, смена IP или реальная подмена.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -F example.com
ssh-keygen -R example.com

В пользовательском ~/.ssh/config задайте отдельные identity-файлы и запретите случайную отправку всех ключей агентом:

Host production
    HostName 203.0.113.20
    User admin
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes
    ForwardAgent no

SSH-сертификаты для команды

Когда серверов и администраторов много, ручное управление authorized_keys плохо масштабируется. OpenSSH поддерживает сертификаты: доверенный центр подписывает пользовательский ключ на короткий срок и указывает principals. Сервер доверяет CA, а не хранит каждый пользовательский ключ. Это упрощает онбординг, отзыв доступа и аудит.

Центр подписи должен быть изолирован, а выдача сертификата — привязана к корпоративной идентификации и MFA. Не храните CA private key на обычном bastion или CI runner. Для маленького проекта сертификаты могут быть избыточны; персональные ключи и регулярная ревизия остаются нормальным вариантом.

Безопасный доступ автоматизации

CI/CD не должен использовать человеческий ключ администратора. Создайте отдельного пользователя deploy, ограничьте его sudo и источник подключения. Если задача сводится к одной операции, примените forced command в authorized_keys. Не разрешайте shell, forwarding и PTY без необходимости.

Секрет deployment храните в защищённом хранилище CI, регулярно ротируйте и не выводите в лог. Ещё лучше использовать краткоживущий сертификат или агент развёртывания с pull-моделью, чтобы постоянного входящего SSH-доступа из CI не было.

Контроль изменений

Конфигурацию sshd и firewall храните в Ansible или другом репозитории инфраструктуры. Изменение проходит review, проверку синтаксиса и поэтапное применение. Автоматический тест должен подтвердить новый вход до закрытия старой сессии. Такой процесс защищает не только от атаки, но и от обычной административной ошибки.

FAQ

Нужно ли менять порт 22?

Можно снизить шум, но это не заменяет ключи, MFA и firewall.

Безопасно ли хранить ключ в ssh-agent?

Да при защищённом рабочем месте, но пересылку агента включайте только осознанно. Для критичных систем лучше аппаратный ключ.

Можно ли отключить пароль сразу?

Только после успешной проверки ключевого входа в отдельной сессии и наличия аварийной консоли.