Защита SSH на Linux VPS: полное руководство по настройке sshd_config

10 мин чтения·Matthieu|

Настрой безопасный SSH на Debian 12 или Ubuntu 24.04. Генерация ключей Ed25519, блокировка sshd_config, ProxyJump через бастион, усиление шифров и проверка через ssh-audit. Каждый шаг с верификацией.

SSH -- это входная дверь на твой сервер. Автоматизированные боты начинают долбить порт 22 через пару минут после запуска VPS. В этом руководстве разберём каждую настройку sshd_config, нужную для защиты SSH на Debian 12 (OpenSSH 9.2) и Ubuntu 24.04 (OpenSSH 9.6), с проверкой после каждого изменения, чтобы ты точно знал, что всё работает.

Предварительные требования

Тебе понадобится:

  • VPS с Debian 12 или Ubuntu 24.04 (свежий или уже настроенный)
  • Непривилегированный пользователь с доступом к sudo
  • Второй терминал или SSH-сессия, открытая на сервере (нужна для проверки изменений без риска залочить себя)

Это руководство -- часть серии Linux VPS Security: Threats, Layers, and Hardening Guide. После настройки SSH переходи к автоматической защите от брутфорса с .

Как сгенерировать безопасный SSH-ключ для VPS?

Генерируй ключ Ed25519 на локальной машине (ноутбук или рабочая станция, не сервер). Ed25519 создаёт 256-битный ключ, обеспечивающий 128 бит криптографической стойкости -- эквивалент RSA-3072, но с более быстрой генерацией и верификацией. Подписи детерминированные, то есть не зависят от генератора случайных чисел в момент подписания. Это исключает целый класс атак на реализацию, которым подвержен RSA.

ssh-keygen -t ed25519 -C "yourname@yourmachine"

Вывод будет примерно такой:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourname/.ssh/id_ed25519
Your public key has been saved in /home/yourname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xR5xGk3TOs4mEfW8sBv7g7LkE2PLxYae2TqfGxpfM3Q yourname@yourmachine

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

Ed25519 vs RSA: какой ключ выбрать?

Ed25519 RSA-4096
Размер ключа 256 бит 4096 бит
Криптостойкость ~128 бит ~140 бит
Генерация ключа Мгновенно 1-5 секунд
Верификация подписи Быстрее Медленнее
Размер файла приватного ключа 464 байт ~3.3 КБ
Зависимость от ГСЧ при подписи Нет (детерминированный) Да
Совместимость OpenSSH 6.5+ (2014) Универсальная

Используй Ed25519, если только тебе не нужно подключаться к системам с OpenSSH старше 6.5, что в 2026 году маловероятно.

Копирование публичного ключа на сервер

С локальной машины:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Если ssh-copy-id недоступен (бывает на некоторых macOS), скопируй вручную:

cat ~/.ssh/id_ed25519.pub | ssh youruser@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Проверка: Залогинься из нового терминала с аутентификацией по ключу:

ssh -i ~/.ssh/id_ed25519 youruser@your-server-ip

Если получил шелл без ввода пароля сервера (только парольную фразу ключа) -- аутентификация по ключу работает.

Директива Include: что нужно знать

Прежде чем редактировать sshd_config, учти: и Debian 12, и Ubuntu 24.04 идут с Include /etc/ssh/sshd_config.d/*.conf в начале /etc/ssh/sshd_config. OpenSSH использует первое найденное значение для большинства директив. Любой файл .conf в sshd_config.d/ имеет приоритет над настройками в основном файле.

Посмотри, что уже настроено:

ls -la /etc/ssh/sshd_config.d/

На Ubuntu 24.04 обычно найдёшь 50-cloud-init.conf, если cloud-init активен. Прочитай все существующие файлы перед внесением изменений:

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Мы будем хранить настройки в одном файле, который загружается первым:

sudo touch /etc/ssh/sshd_config.d/00-hardening.conf
sudo chmod 600 /etc/ssh/sshd_config.d/00-hardening.conf

Префикс 00- гарантирует, что файл будет прочитан раньше остальных конфигов. chmod 600 ограничивает доступ только для root, поскольку этот файл управляет тем, кто может заходить на сервер.

Все изменения sshd_config в этом руководстве вносятся в /etc/ssh/sshd_config.d/00-hardening.conf, если не указано иное.

Как отключить аутентификацию по паролю в SSH?

Отключение парольной аутентификации оставляет только вход по ключу. Брутфорс-атаки становятся бессмысленными, потому что пароля для подбора нет.

Открой файл настройки:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Добавь:

PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication заменяет устаревший ChallengeResponseAuthentication в OpenSSH 9.x. Отключи оба, чтобы перекрыть все пути входа по паролю.

Перед перезапуском sshd всегда проверяй конфиг и не закрывай текущую сессию.

sudo sshd -t

Если вывода нет -- конфиг валидный. Ошибки выведутся в терминал.

Теперь перезапусти sshd:

sudo systemctl restart sshd

Проверка из второго терминала (не закрывай текущую сессию):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@your-server-ip

Должно появиться:

youruser@your-server-ip: Permission denied (publickey).

Это подтверждает, что парольная аутентификация отключена. Обрати внимание: написано (publickey) как единственный разрешённый метод. Именно это нам нужно.

Теперь проверь, что вход по ключу работает, из того же второго терминала:

ssh youruser@your-server-ip

Если оба теста пройдены -- парольная аутентификация отключена, вход по ключу работает. Если вход по ключу не работает, вернись в первую (открытую) сессию и поправь конфиг, пока не залочился.

Как отключить вход по SSH для root на Ubuntu и Debian?

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

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

PermitRootLogin no

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверка из второго терминала:

ssh root@your-server-ip

Ожидаемый вывод:

root@your-server-ip: Permission denied (publickey).

Проверь, что настройка применилась, через sshd -T (заглавная T выводит текущий конфиг):

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Как ограничить SSH-доступ определёнными пользователями и группами?

AllowUsers и AllowGroups ограничивают вход по SSH явным списком. Все, кто не в списке, получат отказ, даже если у них валидные ключи. Это страховка от случайного деплоя ключей или новых пользователей, созданных пакетами.

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

AllowUsers youruser

Замени youruser на реальное имя пользователя. Для нескольких пользователей:

AllowUsers youruser deployer

Альтернативный вариант -- доступ по группам (удобнее для команд):

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

Затем в конфиге:

AllowGroups sshusers

Порядок обработки

OpenSSH проверяет доступ в таком порядке: DenyUsers, AllowUsers, DenyGroups, AllowGroups. Deny на любом этапе блокирует пользователя. Если используешь AllowUsers -- войти смогут только перечисленные пользователи. Если AllowGroups -- только участники указанных групп. Можно комбинировать, но AllowUsers проверяется первой.

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверка из второго терминала:

ssh youruser@your-server-ip

Убедись, что твой пользователь может залогиниться. Затем проверь, что пользователь не из списка будет отклонён:

sudo sshd -T | grep -i allowusers

allowusers youruser

Какие ограничения SSH-сессий стоит установить?

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

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

Что делает каждая настройка:

Директива Значение Эффект
MaxAuthTries 3 Отключает после 3 неудачных попыток аутентификации на соединение
LoginGraceTime 20 20 секунд на аутентификацию, потом разрыв
MaxStartups 10:30:60 После 10 неаутентифицированных подключений случайно сбрасывает 30% новых. При 60 сбрасывает все.
MaxSessions 3 Максимум 3 мультиплексированные сессии на подключение
ClientAliveInterval 300 Отправляет keepalive-пакет каждые 300 секунд (5 минут)
ClientAliveCountMax 2 Отключает после 2 пропущенных keepalive-ответов

Формула ClientAliveInterval: реальный таймаут простоя = ClientAliveInterval x ClientAliveCountMax. С этими значениями: 300 x 2 = 600 секунд = 10 минут. Простаивающая сессия будет разорвана через 10 минут без ответа.

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверка:

sudo sshd -T | grep -E "maxauthtries|logingracetime|maxstartups|maxsessions|clientaliveinterval|clientalivecountmax"

maxauthtries 3
logingracetime 20
maxstartups 10:30:60
maxsessions 3
clientaliveinterval 300
clientalivecountmax 2

Отключение ненужных функций перенаправления

Функции перенаправления (forwarding) расширяют поверхность атаки SSH. Отключи всё, что активно не используешь.

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверка:

sudo sshd -T | grep -E "allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel"

allowagentforwarding no
allowtcpforwarding no
x11forwarding no
permittunnel no

Почему стоит отключить SSH agent forwarding?

Agent forwarding (перенаправление агента) позволяет удалённому серверу использовать твои локальные SSH-ключи для аутентификации на других серверах. Звучит удобно для переключения между машинами. Проблема: любой с root-доступом на этом удалённом сервере может перехватить сокет агента и использовать твои ключи.

Сценарий атаки:

  1. Ты включаешь agent forwarding и подключаешься к Серверу A.
  2. OpenSSH создаёт сокет в /tmp/ssh-XXXX/agent.YYYY на Сервере A.
  3. Атакующий с root-доступом на Сервере A читает переменную окружения SSH_AUTH_SOCK из твоей сессии.
  4. Атакующий подключается через этот сокет: SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
  5. Сервер B видит валидную аутентификацию с твоим ключом. Атакующий внутри.

Атакующий не трогал твой приватный ключ. Ему нужен был только root на промежуточном сервере, пока твоя сессия была активна.

Используй ProxyJump (следующий раздел). Он даёт тот же multi-hop доступ без раскрытия сокета агента на промежуточных серверах.

Как настроить SSH ProxyJump для доступа через бастион?

ProxyJump (прокси-прыжок) направляет SSH-соединение через jump host (бастион) без agent forwarding. Твои ключи никогда не покидают локальную машину. Соединение зашифровано end-to-end: бастион видит только зашифрованный транзитный трафик.

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

ssh -J jumpuser@bastion.example.com targetuser@10.0.1.50

Флаг -J говорит SSH сначала подключиться к бастиону, затем пробросить туннель к целевому серверу. Можно объединить несколько прыжков через запятую:

ssh -J jump1@bastion1,jump2@bastion2 targetuser@10.0.1.50

Настройка в SSH config

Для регулярного использования добавь записи в ~/.ssh/config на локальной машине:

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal-app
    HostName 10.0.1.50
    User appuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host internal-db
    HostName 10.0.2.100
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

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

ssh internal-app

SSH выполнит проброс через бастион автоматически.

Защита бастион-сервера

На бастион-хосте ограничь возможности jump-пользователей. Добавь в sshd_config бастиона:

Match User jumpuser
    PermitTTY no
    X11Forwarding no
    PermitTunnel no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes

Это разрешает TCP forwarding (нужен для ProxyJump), но запрещает jump-пользователю получать шелл, запускать команды или использовать X11. Если бастион скомпрометирован, атакующий получит аккаунт, который может только пробрасывать соединения, без доступа к шеллу.

Какие SSH-шифры и алгоритмы обмена ключами безопасны?

Стандартные списки шифров в OpenSSH содержат алгоритмы, оставленные для обратной совместимости. Удаление слабых уменьшает поверхность атаки. Эти рекомендации нацелены на OpenSSH 9.2+ (Debian 12) и 9.6+ (Ubuntu 24.04).

Сначала перегенерируй хост-ключи, оставив только Ed25519, и удали DSA и ECDSA:

sudo rm -f /etc/ssh/ssh_host_*key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

RSA-ключ оставляем для клиентов без поддержки Ed25519 (редкость, но спасёт от блокировки).

Далее удали слабые модули Diffie-Hellman (группы меньше 3072 бит):

sudo awk '$5 >= 3071' /etc/ssh/moduli > /tmp/moduli.safe
sudo mv /tmp/moduli.safe /etc/ssh/moduli
sudo chown root:root /etc/ssh/moduli
sudo chmod 644 /etc/ssh/moduli

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
Категория Алгоритмы Примечания
Обмен ключами sntrup761x25519, curve25519, DH group16/18 sntrup761 -- постквантовый гибрид. curve25519 -- текущий стандарт.
Шифры ChaCha20-Poly1305, AES-256-GCM, AES-128-GCM, AES-CTR ChaCha20 первым: быстрее программно без AES-NI. GCM -- аутентифицированное шифрование.
MAC HMAC-SHA2 ETM, UMAC-128 ETM Только ETM (Encrypt-then-MAC). Режимы без ETM слабее.
Хост-ключи Ed25519, RSA (SHA-2) Без DSA (сломан). Без ECDSA (вопросы доверия к кривым NIST).

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверь из второго терминала, что подключение работает. Если твой SSH-клиент не поддерживает ни один из указанных алгоритмов (очень старый клиент), появится ошибка "no matching cipher". В таком случае обнови клиент или временно верни нужный алгоритм.

Настройка баннера входа

Скрой информацию о версии SSH и покажи юридическое предупреждение:

sudo nano /etc/ssh/banner.txt

Authorized access only. All activity is monitored and logged.

Текст короткий. Длинные баннеры с системной информацией помогают атакующим определить твою ОС.

Добавь в /etc/ssh/sshd_config.d/00-hardening.conf:

Banner /etc/ssh/banner.txt
DebianBanner no

DebianBanner no убирает строку версии Debian/Ubuntu из баннера SSH-протокола. Раскрытие версии помогает атакующим нацеливаться на известные уязвимости конкретной сборки OpenSSH.

Проверь и перезапусти:

sudo sshd -t && sudo systemctl restart sshd

Проверка с локальной машины:

ssh -v youruser@your-server-ip 2>&1 | grep "banner"

Полный эталонный конфиг sshd_config

Вот полный /etc/ssh/sshd_config.d/00-hardening.conf со всеми настройками из этого руководства:

# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Access control
AllowUsers youruser

# Session limits
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Forwarding restrictions
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Cryptography
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

# Banner
Banner /etc/ssh/banner.txt
DebianBanner no

# Logging
LogLevel VERBOSE

LogLevel VERBOSE записывает дополнительные данные, включая отпечатки ключей, использованных при аутентификации. Полезно для аудита: кто вошёл и с каким ключом.

После записи файла всегда проверяй перед перезапуском:

sudo sshd -t && sudo systemctl restart sshd

Посмотри полный действующий конфиг:

sudo sshd -T

Это выводит все активные настройки, включая значения по умолчанию. Отфильтруй через grep для проверки конкретных значений:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

permitrootlogin no
passwordauthentication no
allowusers youruser

Как проверить настройку SSH с помощью ssh-audit?

ssh-audit сканирует сервер и оценивает каждый алгоритм как good, warning или fail. Запусти после настройки, чтобы убедиться, что всё проходит.

Установи на локальной машине или отдельном сервере (не на целевом):

pip3 install ssh-audit

Или через apt на Debian/Ubuntu:

sudo apt update && sudo apt install -y ssh-audit

Просканируй сервер:

ssh-audit your-server-ip

С настройками из этого руководства записей [fail] быть не должно. Вывод начинается с обнаруженной версии OpenSSH, затем идут категории алгоритмов:

# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4
...

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
...

Если видишь записи [fail], проверь, что 00-hardening.conf загружен (помни порядок Include) и что другие файлы в sshd_config.d/ не перезаписывают твои настройки.

В ssh-audit также есть встроенные руководства по защите:

ssh-audit --list-hardening-guides

Устранение неполадок

Потерял доступ

Если не можешь зайти по SSH после изменения конфига:

  1. Используй веб-консоль VPS-провайдера (KVM/VNC) для прямого входа.
  2. Исправь /etc/ssh/sshd_config.d/00-hardening.conf.
  3. Запусти sshd -t для валидации.
  4. Перезапусти: systemctl restart sshd.

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

sshd не запускается после изменения конфига

sudo sshd -t

Выводит точную строку и файл с ошибкой. Типичные проблемы:

  • Опечатка в имени алгоритма (пробелы в списках через запятую запрещены)
  • Дублирующиеся директивы в разных файлах (проверь sshd_config.d/ и основной sshd_config)
  • AllowUsers с несуществующим именем пользователя (sshd запустится, но никто не сможет войти)

Отказ в подключении после усиления шифров

Твой локальный SSH-клиент может не поддерживать настроенные шифры. Проверь, какие шифры поддерживает клиент:

ssh -Q cipher

Сравни со списком сервера. Верни нужный шифр или обнови клиент.

Проверка SSH-логов

sudo journalctl -u sshd -f

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

Проверка, какой файл задаёт директиву

sudo sshd -T | grep passwordauthentication

Если значение не совпадает с тем, что ты задал, другой файл в sshd_config.d/ перезаписывает твой. Файлы загружаются в алфавитном порядке. Наш 00-hardening.conf загружается первым, поэтому выигрывает для большинства директив. Но проверь cloud-init или другие инструменты управления, которые могут записывать свои конфиги.

Чек-лист проверки

Пройди после завершения всех шагов по защите:

  1. Парольная аутентификация отключена: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server возвращает "Permission denied"
  2. Вход root отключён: ssh root@server возвращает "Permission denied"
  3. Аутентификация по ключу работает: ssh youruser@server даёт шелл
  4. AllowUsers активен: sudo sshd -T | grep allowusers показывает твоего пользователя
  5. Ограничения сессий установлены: sudo sshd -T | grep maxauthtries показывает 3
  6. Перенаправление отключено: sudo sshd -T | grep allowagentforwarding показывает no
  7. Только стойкие шифры: ssh-audit server-ip без записей [fail]
  8. Логи работают: sudo journalctl -u sshd -n 20 показывает свежие записи аутентификации

После защиты SSH настрой для автоматической блокировки IP-адресов с неудачными попытками аутентификации. Для сетевого контроля доступа к SSH смотри .

Copyright 2026 Virtua.Cloud. Vse prava zashchishcheny.

Готовы попробовать?

Разверните свой сервер за секунды. Linux, Windows или FreeBSD.

Смотреть тарифы VPS