Server Warden
РУКОВОДСТВО ПО БЕЗОПАСНОСТИ СЕРВЕРОВ

Опубликовано 8 сентября 2026 г.

Усиление защиты SSH: лучшие практики против brute-force атак

Усиление защиты SSH означает ограничение того, как ваш сервер принимает удалённые подключения, чтобы автоматизированные скрипты для перебора паролей и боты для credential-stuffing не смогли попасть внутрь, даже если будут пытаться годами. Основные шаги: перейти на аутентификацию по ключу, отключить вход под root и вход по паролю, ограничить, какие учётные записи и сети могут подключаться, и дополнить sshd файрволом и инструментом предотвращения вторжений вроде fail2ban. Это руководство последовательно разбирает каждый шаг с конкретными строками конфигурации.

В этом руководстве

Почему SSH — главная цель на новом сервере Переход на аутентификацию по ключу Отключение входа под root по SSH Стоит ли менять стандартный порт SSH? Ограничение круга подключающихся Усиление sshd_config: полный чек-лист Современные шифры, обмен ключами и MAC Ограничение частоты попыток входа с fail2ban SSH за файрволом Часто задаваемые вопросы

Быстрый результат: сделайте это в ближайшие 10 минут

  • Сгенерируйте пару ключей Ed25519 на своей рабочей станции и скопируйте публичный ключ в файл authorized_keys на сервере.
  • Убедитесь, что можете войти по ключу во втором окне терминала, прежде чем менять что-либо ещё.
  • Установите PermitRootLogin no и PasswordAuthentication no в /etc/ssh/sshd_config.
  • Выполните sudo sshd -t, чтобы проверить конфигурацию, затем sudo systemctl reload sshd.
  • Держите исходную сессию открытой, пока не убедитесь, что новый вход работает, чтобы не заблокировать себе доступ.

Почему SSH — главная цель на новом сервере

Любой доступный из интернета Linux-сервер с открытым SSH на порту 22 начнёт получать автоматизированные попытки входа в течение нескольких минут после появления в сети. Атаки на учётные данные остаются одним из главных способов получения первоначального доступа: отчёт Verizon 2025 Data Breach Investigations Report показал, что украденные учётные данные фигурировали примерно в 32% всех утечек и использовались как исходный вектор доступа примерно в 22% утечек, а злоупотребление учётными данными — доминирующая тактика за базовыми атаками на веб-приложения. Для малого или среднего бизнеса, управляющего собственным VPS, это выражается в постоянном потоке неудачных попыток входа по SSH от ботнетов, сканирующих всё адресное пространство IPv4 в поисках слабых или стандартных учётных данных.

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

Переход на аутентификацию по ключу

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

Сгенерируйте пару ключей с использованием современного алгоритма. Ed25519 — рекомендуемый вариант по умолчанию для новых ключей: он использует 256-битный ключ, чтобы достичь уровня безопасности, сопоставимого с 3072-битным ключом RSA, быстро вычисляется, а его подписи детерминированы, что устраняет целый класс ошибок повторного использования nonce, которые затрагивали некоторые реализации RSA и ECDSA. Если нужна совместимость со старыми системами, предшествующими OpenSSH 6.5 (примерно до 2014 года), используйте RSA с длиной 4096 бит. Никогда не генерируйте и не принимайте 1024- или 2048-битный ключ RSA для чего-либо, доступного из интернета, сегодня.

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

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

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

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

Отключение входа под root по SSH

Root никогда не должен иметь возможность заходить напрямую по SSH, потому что это устраняет журнал аудита о том, какая именно учётная запись выполнила действие, и даёт атакующему, угадавшему или укравшему одни учётные данные, немедленный полный контроль. Установите PermitRootLogin no в sshd_config и используйте sudo из именованной учётной записи.

PermitRootLogin no

Если у вас есть автоматизация, которая сейчас зависит от входа под root, создайте отдельную сервисную учётную запись с ограниченным входом только по ключу и выдайте ей ровно те привилегии sudo, которые нужны, через /etc/sudoers.d/, вместо того чтобы восстанавливать доступ root.

Стоит ли менять стандартный порт SSH?

Перенос SSH с порта 22 не делает сервер более защищённым от целенаправленного атакующего, но заметно снижает объём шума от оппортунистических сканеров, работающих по всему интернету, в ваших логах. Относитесь к этому как к небольшому эксплуатационному удобству, а не мере безопасности, и никогда не позволяйте этому заменять аутентификацию по ключу, правила файрвола или fail2ban.

Если вы всё же меняете порт, выберите значение выше 1024, обновите соответствующее правило файрвола и чётко задокументируйте новый порт для остальной команды, поскольку забытый нестандартный порт — частая причина ненужных обращений в поддержку.

Port 2222

Ограничение круга подключающихся

Ограничение доступа по SSH конкретными учётными записями, группами и исходными сетями ещё больше сокращает поверхность атаки, потому что атакующий с украденным ключом от не той учётной записи или соединением из не той сети отклоняется ещё до попытки аутентификации. Используйте AllowUsers или AllowGroups, чтобы точно назвать, кому разрешён доступ:

AllowUsers deploy admin
AllowGroups ssh-users

Если ваша команда подключается из известного диапазона IP офиса, через VPN или через bastion-хост, добавьте это ограничение и в файрвол (см. раздел о файрволах ниже). Это делает украденный или утёкший ключ бесполезным для атакующего, подключающегося из неопознанной сети.

Усиление sshd_config: полный чек-лист

Помимо аутентификации и контроля доступа, ряд дополнительных директив sshd_config закрывает уловки с перенаправлением портов, ужесточает тайм-ауты и сокращает объём информации, которую может получить неаутентифицированное соединение. Эти настройки соответствуют рекомендациям CIS Benchmark по усилению защиты SSH в Linux и являются безопасными значениями по умолчанию для большинства рабочих нагрузок на VPS:

Protocol 2
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 4
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
GatewayPorts no
PermitTunnel no
PermitEmptyPasswords no
IgnoreRhosts yes
HostbasedAuthentication no
PrintMotd no
LogLevel VERBOSE

LoginGraceTime ограничивает, как долго может оставаться открытым неаутентифицированное соединение, а MaxAuthTries ограничивает количество попыток аутентификации в рамках одного соединения — обе настройки сокращают окно возможностей для скриптовой атаки. ClientAliveInterval и ClientAliveCountMax вместе автоматически отключают неактивные или зависшие сессии. Отключение перенаправления X11, TCP и агента закрывает техники туннелирования, которые редко нужны на production-сервере и иногда используются для продвижения глубже в сеть. LogLevel VERBOSE гарантирует, что отпечаток ключа регистрируется при каждой попытке входа, что ценно, если когда-нибудь понадобится расследовать взлом (см. наше руководство по обнаружению взлома сервера и реагированию на него).

После редактирования /etc/ssh/sshd_config всегда проверяйте синтаксис перед перезагрузкой:

sudo sshd -t
sudo systemctl reload sshd

Хотите, чтобы кто-то ещё проверил вашу конфигурацию SSH?

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

Получить бесплатную проверку сервера Поговорить с инженером по безопасности

Современные шифры, обмен ключами и MAC

Ограничение sshd современными наборами шифров и алгоритмами обмена ключами закрывает устаревшую криптографию, которая либо слаба, либо признана нежелательной, не нарушая при этом совместимость с клиентами последних нескольких лет. Рекомендации Mozilla по OpenSSH, широко используемые как базовый уровень для усиленных конфигураций, предлагают следующее для текущих версий OpenSSH:

KexAlgorithms [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256

Curve25519 в целом предпочтительнее кривых NIST P для обмена ключами, а кривые NIST перечислены в основном для совместимости со старыми клиентами. Полностью избегайте шифров в режиме CBC и MAC на основе MD5 или SHA-1: у них есть известные слабости, и современным клиентам OpenSSH они практически не нужны. Проверить текущую конфигурацию на соответствие этим рекомендациям можно инструментом вроде ssh-audit, который отмечает любой слабый алгоритм, всё ещё включённый на вашем сервере.

Ограничение частоты попыток входа с fail2ban

Fail2ban отслеживает ваши логи аутентификации и автоматически банит IP-адреса, которые генерируют слишком много неудачных попыток входа за короткое окно, что останавливает распределённые brute-force попытки, которые иначе бесконечно долбились бы в систему, даже если случайно снова будет включён вход по паролю. Типичная конфигурация jail для sshd в /etc/fail2ban/jail.local выглядит так:

[sshd]
enabled = true
port = ssh
maxretry = 3
findtime = 10m
bantime = 1h
bantime.increment = true

findtime — это окно, в котором подсчитываются неудачные попытки, maxretry — сколько неудач в этом окне вызывают бан, а bantime — сколько длится бан. Включение bantime.increment приводит к тому, что повторные нарушители получают всё более длинные баны, что эффективно против ботнетов, повторяющих попытки с того же адреса после короткой паузы. Настройку jail, белые списки и интеграцию с другими службами мы разбираем в Руководстве по настройке Fail2ban.

SSH за файрволом

Правило файрвола, разрешающее SSH-трафик только из известных сетей, добавляет уровень защиты, который работает, даже если ключ или пароль каким-то образом оказались скомпрометированы, потому что соединение отклоняется на сетевом уровне ещё до того, как его обработает SSH. В Ubuntu или Debian ufw — самый простой способ обеспечить политику «запрещено по умолчанию», явно разрешив при этом SSH:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Если ваша команда подключается с фиксированного IP офиса или узла выхода VPN, ограничьте правило ещё сильнее с помощью ufw allow from <ip> to any port 22. Для большего контроля или при управлении несколькими серверами со сложными наборами правил стоит изучить nftables — современный преемник iptables. Мы напрямую сравниваем все три подхода, включая случаи, когда стоит выбрать nftables вместо ufw, в Файрвол в Linux: iptables vs nftables vs ufw.

Усиление защиты SSH — лишь часть более широкой картины безопасности сервера. Полную картину, включая установку обновлений, мониторинг и защиту от DDoS, вы найдёте в Чек-листе безопасности VPS: полное руководство. Если вам достался сервер, который никогда не проходил усиление защиты, наша статья 5 основ усиления защиты сервера — хорошая отправная точка перед тем, как переходить к деталям выше.

Часто задаваемые вопросы

Стоит ли менять стандартный порт SSH с 22?

Смена порта SSH не является реальной мерой безопасности, но она заметно сокращает объём автоматизированных сканирований в ваших логах. Используйте это как небольшое удобство в дополнение к аутентификации по ключу и файрволу, но никогда как замену им.

Достаточно ли одного отключения аутентификации по паролю?

Отключение аутентификации по паролю устраняет самую распространённую цель для brute-force атак, но это стоит сочетать с отключением входа под root, ограничением того, какие учётные записи могут подключаться по SSH, и ограничением частоты попыток подключения с помощью инструмента вроде fail2ban.

Какой тип SSH-ключа использовать в 2026 году?

Ed25519 — рекомендуемый вариант по умолчанию для новых SSH-ключей. Он обеспечивает высокую надёжность при значительно меньшем размере ключа по сравнению с RSA. Если нужна поддержка устаревших систем, не умеющих работать с Ed25519, используйте RSA с длиной 4096 бит, но никогда 1024 или 2048.

Заменяет ли fail2ban необходимость аутентификации по ключу?

Нет. Fail2ban замедляет и блокирует попытки brute-force, банив IP-адреса после повторных неудачных попыток, но лучше всего работает как второй уровень защиты за аутентификацией по ключу и правильно настроенным файрволом, а не как замена того или другого.

Как часто нужно менять SSH-ключи?

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

Можно ли использовать SSH-сертификаты вместо отдельных ключей?

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

В чём разница между LoginGraceTime и MaxAuthTries?

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

Не уверены, в каком состоянии ваш сервер?

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

Получить бесплатную проверку сервера Поговорить с инженером по безопасности