Безопасная настройка SSH: ключи, root и ограничение доступа

Подготовьте аварийный доступ и отдельную учётную запись

Подготовьте персональную непривилегированную учётную запись, которая уже может выполнить нужные административные действия через sudo. Запрет прямого root-входа не отменяет защиту привилегированных учётных записей: пользователь с широким sudo фактически остаётся высокопривилегированным. Создание пользователей, групп и точная настройка sudo рассмотрены в статье «Учётные записи, sudo и парольная политика в Linux».

• Оставьте текущую работающую SSH-сессию открытой до конца изменения.
• Проверьте независимый канал восстановления: локальную консоль, консоль виртуальной машины, KVM-over-IP или BMC. Для физического сервера доступ к BMC требует отдельной защиты; см. «Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления».
• Зафиксируйте, каким пользователем, с какого адреса и каким ключом будет выполняться новый вход.
• Сохраните копию текущей конфигурации SSH вне редактируемого файла.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-hardening

Создайте Ed25519-ключ с парольной фразой

Для нового ключа SSH обычно выбирают Ed25519: современный OpenSSH поддерживает этот тип, а ключ получается компактным. Однако старый OpenSSH, режим FIPS или криптографическая политика ОС могут запретить Ed25519. В таком случае не включайте устаревшие алгоритмы ради совместимости без оценки: уточните допустимый тип по политике платформы и документации установленной версии.

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_server_admin -C "admin@example"
ssh-keygen -lf ~/.ssh/id_ed25519_server_admin.pub
ssh-copy-id -i ~/.ssh/id_ed25519_server_admin.pub admin@server.example

Не передавайте закрытый ключ на сервер, в чат или в репозиторий. Открытый ключ не является секретом и должен появиться на сервере одной строкой в authorized_keys нужного пользователя.

Проверьте вход по ключу в новой сессии

ssh -i ~/.ssh/id_ed25519_server_admin -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@server.example

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

sudo -v && sudo -l

Какие директивы отвечают за вход в SSH

Для полного запрета root-входа выбирайте PermitRootLogin no. Значение PermitRootLogin prohibit-password подходит только тогда, когда организация сознательно разрешает root-аутентификацию по ключу или другому непарольному методу; это не запрет root-входа. Не заменяйте одну директиву другой: PasswordAuthentication no не запрещает root по ключу, а PubkeyAuthentication yes не отключает пароль.

Внесите минимальные ограничения в sshd_config

Размещайте локальные изменения в отдельном drop-in-файле, если его подключает конфигурация вашего пакета, либо меняйте основной sshd_config. Порядок файлов и правило «первое полученное значение» для части параметров могут влиять на результат, поэтому не создавайте дублирующие противоречивые настройки.

# Шаблон: адаптируйте пользователей, группы и совместимость.
# Применяйте только после успешного входа admin по ключу.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
# Требовать именно аутентификацию по открытому ключу.
# Для MFA замените значение комбинацией из соответствующего раздела ниже.
AuthenticationMethods publickey

# Пример allowlist: оставьте только реально нужные записи.
AllowUsers admin deploy
# Альтернатива для ролевой модели: AllowGroups ssh-admins

# Запрет встроенных перенаправлений, если они не требуются.
AllowTcpForwarding no
AllowAgentForwarding no
X11Forwarding no
PermitTunnel no
GatewayPorts no

# Пределы соединения и аутентификации.
LoginGraceTime 60
MaxAuthTries 4
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2

# Только в версиях OpenSSH с поддержкой ChannelTimeout:
# ChannelTimeout session=15m

Ограничьте список пользователей и групп

AllowUsers и AllowGroups создают allowlist: войти смогут только перечисленные пользователи или члены указанных групп при соблюдении остальных условий. DenyUsers и DenyGroups запрещают отдельные учётные записи или группы. OpenSSH обрабатывает эти классы в порядке DenyUsers, AllowUsers, DenyGroups, AllowGroups; запрет имеет приоритет над разрешением своего типа. Имена допускают шаблоны, а в поддерживаемых версиях — форму USER@HOST для ограничения по источнику.

# Разрешить вход только двум локальным учётным записям
AllowUsers admin deploy

# Или разрешить членов административной группы
# AllowGroups ssh-admins

# Явно запретить скомпрометированную или более не используемую учётную запись
DenyUsers former-admin

Не смешивайте без необходимости AllowUsers и AllowGroups: итог зависит от членства в группах и перечня разрешений. После добавления AllowUsers служебная учётная запись для резервного копирования, автоматизации или SFTP может перестать входить. Такие директивы уменьшают круг SSH-пользователей, но не заменяют удаление ненужных аккаунтов, корректный sudo и сетевую политику.

Ограничьте доступ SSH по исходному адресу

Для точечного ограничения конкретного пользователя можно использовать адресную часть шаблона AllowUsers, например AllowUsers admin@192.0.2.0/24, если такой CIDR-синтаксис поддерживает установленная версия OpenSSH. Проверьте его на своей версии через тест эффективной конфигурации до reload. Вариант с шаблоном адреса также возможен, но менее точен. Это ограничение действует на уровне sshd после установления TCP-соединения и не заменяет firewall.

# Пример: учётная запись admin может войти только из административной подсети.
# Проверьте поддержку CIDR в документации и через sshd -T -C.
AllowUsers admin@192.0.2.0/24 deploy

Отключите forwarding и настройте лимиты

AllowTcpForwarding no запрещает встроенный проброс портов SSH, AllowAgentForwarding no — перенаправление агента SSH, X11Forwarding no — X11-forwarding, а PermitTunnel no — SSH-туннельные интерфейсы. GatewayPorts no ограничивает сокеты удалённого перенаправления адресами loopback; при уже заданном AllowTcpForwarding no это дополнительное ограничение не задействуется. Перед отключением проверьте, не использует ли эти возможности администратор, CI/CD, резервное копирование, SFTP-сценарий через bastion или прикладной туннель.

Защита SSH от перебора не сводится к MaxAuthTries: параметр ограничивает попытки в одном соединении, а не поток новых подключений. Для реагирования на повторяющиеся неудачные входы можно применять Fail2ban с осторожно подобранными порогами; см. «Fail2ban: защита SSH и веб-сервера от перебора паролей».

При необходимости потребуйте ключ и MFA

Многофакторная аутентификация для SSH — опциональный слой. Она требует настроенного и проверенного PAM-провайдера или другого поддерживаемого механизма: сама директива sshd не создаёт второй фактор. Не включайте требование MFA, пока не проверена аварийная процедура при недоступности устройства, TOTP или внешнего провайдера.

# Пример только для системы, где MFA через PAM уже настроена и проверена.
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive:pam

AuthenticationMethods publickey,keyboard-interactive:pam задаёт последовательность: сначала ключ, затем keyboard-interactive через PAM. Запись через запятую означает обязательную комбинацию методов; несколько альтернативных комбинаций указывают через пробел. Если оставить KbdInteractiveAuthentication no, требуемая комбинация не сработает. Конкретная интеграция, например PAM-модуль с TOTP, зависит от дистрибутива и выбранного провайдера.

Проверьте конфигурацию и примените её без потери доступа

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods|allowusers|allowgroups|denyusers|denygroups|allowtcpforwarding|allowagentforwarding|x11forwarding|permittunnel|gatewayports|logingracetime|maxauthtries|maxsessions|clientalive|channeltimeout'
sudo sshd -T -C user=admin,addr=192.0.2.10,host=client.example
sudo systemctl reload sshd

После reload посмотрите журнал службы и попытайтесь подключиться с ожидаемого адреса. В системах с systemd обычно помогает journalctl -u sshd или journalctl -u ssh; в Debian- и Ubuntu-подобных конфигурациях записи аутентификации нередко также попадают в /var/log/auth.log, в RHEL-подобных — в /var/log/secure. Это типичные пути, а не гарантия: конкретное журналирование определяет дистрибутив и его настройка.

Что не заменяет настройка SSH

• Смена порта SSH может уменьшить шум массового сканирования и записи в журнале, но не защищает от целевой атаки и не заменяет ключи, обновления или ограничение источников. При смене порта обновите клиентские конфигурации и сетевые правила, сохранив аварийный путь.
• Отключение root-входа не ограничивает пользователя, которому разрешён полный sudo, и не исправляет слишком широкие правила sudoers.
• AllowUsers и AllowGroups не удаляют учётные записи, не отзывают их ключи автоматически и не заменяют firewall.
• Запрет forwarding не изолирует shell-пользователя от сети и не является полноценным средством предотвращения туннелей.
• Локальное удаление строки из authorized_keys прекращает доступ по этому ключу только на данном хосте. При множестве серверов, SSH-сертификатах или подозрении на компрометацию нужен управляемый отзыв и ротация; см. «Управление секретами сервера: хранение, выдача, ротация и отзыв доступов».

Проверьте хост-ключ сервера и сопровождение ключей

Клиентский файл known_hosts и проверка отпечатка ключа хоста защищают от подключения к неожиданному серверу; это другая задача, чем аутентификация пользователя по ключу. При первом подключении сверяйте отпечаток ключа хоста по доверенному каналу. Не удаляйте запись known_hosts при сообщении об изменении ключа без проверки причины: это может скрыть подмену узла.

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