Skip to content
EN

Как защитить SSH сервер (hardening)

Коротко:

SSH brute-force — #1 атака на Linux-серверах. Базовый hardening за 30 мин блокирует 99% атак: отключить password auth (только keys), сменить порт с 22, AllowUsers whitelist, fail2ban для brute-force, MFA через TOTP опционально. Всегда держите 2 терминал открытым при правках sshd_config на случай errors.

Ниже: пошаговая инструкция, рабочие примеры, типичные ошибки, FAQ.

Проверить безопасность сайта →

Пошаговая настройка

  1. Сгенерируйте SSH-ключ на клиенте: ssh-keygen -t ed25519 -a 100
  2. Скопируйте pubkey на сервер: ssh-copy-id user@host
  3. Проверьте вход по ключу ДО выключения password auth
  4. В /etc/ssh/sshd_config: PasswordAuthentication no, PubkeyAuthentication yes, PermitRootLogin prohibit-password
  5. Добавьте AllowUsers admin deploy (whitelist users)
  6. Опционально: смените порт (Port 2222) — security-through-obscurity, 90% атак на порт 22
  7. sshd -t проверить config, systemctl reload sshd
  8. Установите fail2ban: apt install fail2ban (дефолтный sshd jail уже настроен)

Рабочие примеры

СценарийКонфиг
Базовый /etc/ssh/sshd_configPort 2222 PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes AllowUsers admin ClientAliveInterval 300 ClientAliveCountMax 2 MaxAuthTries 3
Генерация ed25519 keyssh-keygen -t ed25519 -a 100 -C "admin@example.com"
Fail2ban sshd jail[sshd] enabled = true maxretry = 3 bantime = 3600 findtime = 600
TOTP MFA (pam_google_authenticator)apt install libpam-google-authenticator\ngoogle-authenticator # run as user\n# Then edit /etc/pam.d/sshd + sshd_config: ChallengeResponseAuthentication yes
UFW + SSH rate-limitufw limit 2222/tcp # 6 connections per 30 sec

Типичные ошибки

  • Закрыли password auth без проверки ключей сначала — locked out
  • Сменили порт но не обновили firewall/UFW — connection refused
  • PermitRootLogin yes в 2026 — anti-pattern. Используйте sudo user
  • AllowUsers с typo в username — ничего не работает
  • MaxAuthTries слишком высокий (6+) — облегчает bruteforce

Как защитить SSH сервер — краткий ответ

Чтобы эффективно защитить SSH сервер, необходимо выполнить несколько ключевых действий: изменить стандартный порт SSH на нестандартный (например, 2222), отключить вход с паролем, используя ключи SSH, и ограничить доступ по IP-адресам. Также рекомендуется настроить двухфакторную аутентификацию и регулярно обновлять программное обеспечение. Эти меры значительно снизят вероятность несанкционированного доступа к серверу.

Изменение порта SSH и отключение входа по паролю

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

sudo nano /etc/ssh/sshd_config

Найдите строку Port 22 и измените её на, например, Port 2222. После этого сохраните изменения и перезапустите SSH-сервис:

sudo systemctl restart sshd

Следующим шагом является отключение входа по паролю. Найдите строку PasswordAuthentication yes и измените её на:

PasswordAuthentication no

Это позволит использовать только ключи SSH для аутентификации, что значительно повышает безопасность. Не забудьте предварительно настроить ключи SSH для вашего пользователя.

Ограничение доступа и двухфакторная аутентификация

Для дальнейшего повышения безопасности SSH сервера рекомендуется ограничить доступ к нему только с определённых IP-адресов. Это можно сделать с помощью правила в файле конфигурации /etc/hosts.allow. Например, чтобы разрешить доступ только с IP-адреса 192.168.1.100, добавьте следующую строку:

sshd: 192.168.1.100

Или используйте /etc/hosts.deny для блокировки всех остальных:

sshd: ALL

Также стоит рассмотреть возможность настройки двухфакторной аутентификации (2FA) для SSH. Это можно сделать с помощью пакета Google Authenticator. Установите его:

sudo apt-get install libpam-google-authenticator

Затем откройте файл конфигурации PAM:

sudo nano /etc/pam.d/sshd

И добавьте следующую строку в начало файла:

auth required pam_google_authenticator.so

После этого настройте Google Authenticator для вашего пользователя, выполнив команду:

google-authenticator

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

sudo systemctl restart sshd

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

Как защитить SSH сервер — TL;DR

Чтобы защитить SSH сервер, необходимо выполнить несколько ключевых шагов: измените стандартный порт (22) на нестандартный, отключите вход по паролю, разрешите доступ только для определённых пользователей, используйте ключи SSH, активируйте двухфакторную аутентификацию и настройте Fail2Ban для защиты от brute-force атак. Эти меры значительно повысят безопасность вашего сервера.

Изменение стандартного порта SSH

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

Чтобы изменить порт, откройте файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Найдите строку, содержащую Port 22, и измените её на, например, Port 2222. После этого сохраните изменения и перезапустите SSH-сервис:

sudo systemctl restart sshd

Теперь ваш SSH сервер будет доступен по новому порту 2222. Не забудьте внести изменения в файлы конфигурации вашего брандмауэра, чтобы разрешить доступ к этому порту.

Настройка доступа по ключам и отключение паролей

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

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

ssh-keygen -t rsa -b 4096

После создания ключей скопируйте открытый ключ на сервер с помощью:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote_host

Замените user на ваше имя пользователя и remote_host на IP-адрес или доменное имя вашего сервера.

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

sudo nano /etc/ssh/sshd_config

Найдите строку PasswordAuthentication yes и измените её на PasswordAuthentication no. Сохраните изменения и перезапустите SSH-сервис:

sudo systemctl restart sshd

Теперь доступ к вашему серверу возможен только с использованием ключей SSH, что значительно затрудняет несанкционированный доступ.

ЗаголовкиCSP, HSTS, X-Frame-Options и др.
SSL/TLSШифрование и сертификат
КонфигурацияСерверные настройки и утечки
Оценка A-FОбщий балл безопасности

Почему нам доверяют

OWASP
рекомендации
15+
заголовков безопасности
<2с
результат
A–F
оценка безопасности

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

1

Введите URL сайта

2

Анализ заголовков безопасности

3

Получите оценку A–F

Что проверяет анализ безопасности?

Инструмент проверяет HTTP-заголовки безопасности, конфигурацию SSL/TLS, утечки серверной информации и защиту от распространённых атак (XSS, clickjacking, MIMEsniffing). Оценка от A до F показывает общий уровень защиты.

Анализ заголовков

Проверка Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy и других.

Проверка SSL

Версия TLS, срок сертификата, цепочка доверия, поддержка HSTS.

Обнаружение утечек

Поиск раскрытых серверных версий, debug-режимов, открытых конфигов и директорий.

Отчёт с рекомендациями

Детальный отчёт с объяснением каждой проблемы и конкретными шагами для исправления.

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

Специалисты по безопасности

аудит HTTP-заголовков

DevOps

проверка конфигурации

Разработчики

CSP и HSTS настройка

Аудиторы

соответствие стандартам

Частые ошибки

Нет Content-Security-PolicyCSP — главная защита от XSS. Без него инъекция скриптов значительно проще.
Нет заголовка HSTSБез HSTS возможна downgrade-атака с HTTPS на HTTP. Включите Strict-Transport-Security.
Server header раскрывает версиюServer: Apache/2.4.52 помогает атакующим подобрать эксплойт. Скройте версию.
X-Frame-Options не установленСайт можно встроить в iframe для clickjacking-атаки. Установите DENY или SAMEORIGIN.
Нет X-Content-Type-OptionsБез nosniff браузер может интерпретировать файлы неправильно (MIME sniffing).

Лучшие практики

Начните с базовых заголовковМинимум: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Займёт 5 минут.
Внедрите CSP постепенноНачните с Content-Security-Policy-Report-Only, мониторьте нарушения, затем включите.
Скройте серверные заголовкиУдалите Server, X-Powered-By, X-AspNet-Version из ответов.
Настройте Permissions-PolicyОграничьте доступ к камере, микрофону, геолокации — только то, что реально используется.
Проверяйте после каждого деплояЗаголовки безопасности могут быть перезаписаны при обновлении конфигурации сервера.

Получите больше с бесплатным аккаунтом

История security-проверок и мониторинг HTTP-заголовков безопасности.

Зарегистрироваться (FREE)

Больше по теме

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

ed25519 vs RSA?

ed25519 быстрее, более современный, короче (32 байта vs 2048+ бит). RSA нужен только для legacy clients (до 2014).

Смена порта — реальная защита?

Security-through-obscurity. Блокирует массовые boт scanners (90% сканируют только :22). Не защищает от targeted attack на ваш server.

Надо ли отключить root полностью?

Лучше <code>PermitRootLogin prohibit-password</code> (разрешить только по ключу) + sudo user. Полный no — требует console access для emergency.

Как проверить security?

<a href="/security">Enterno Security Scanner</a> + <code>ssh-audit</code> open-source tool. Plus audit auth.log для failed attempts.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.