MSB Support

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

28.11.2025 от admin 0

В этой статье разберём:

  • почему SSH-конфигурация на VPS критична для безопасности;
  • какие параметры sshd_config за что отвечают;
  • как выглядит практический безопасный конфиг для типичного VPS;
  • как применить его так, чтобы не отрезать себе доступ.

Все примеры ориентированы на Linux-VPS вроде Ubuntu/Debian с OpenSSH.

  1. Зачем вообще настраивать sshd_config

SSH-сервер (sshd) — главный вход на VPS. Если его оставить как есть:

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

В интернете такой сервер моментально начинают атаковать боты:

  • брутфорс логин/пароль;
  • попытки подобрать root/админа с простыми паролями;
  • сканирование на открытые возможности (X11, agent-forwarding и т.п.).

Цель настроек sshd_config:

  1. Свести поверхность атаки к минимуму.
  2. Оставить только один понятный и контролируемый способ входа — по SSH-ключам.
  3. Ограничить последствия ошибок (root-вход, слабые права на файлах и т.д.).
  1. Теория в двух словах: ключи vs пароли

Парольная аутентификация

Плюсы:

  • просто: ввёл пароль — вошёл.

Минусы:

  • пароли можно подбирать;
  • пользователи ставят слабые пароли;
  • пароли часто повторяются между сервисами;
  • нужен fail2ban/фильтрация логов, но это уже «пластырь», а не решение.

Аутентификация по SSH-ключам

Схема:

  1. На клиенте создаётся пара ключей:
    • приватный (id_ed25519, id_rsa) — хранится у пользователя;
    • публичный (id_ed25519.pub) — копируется на сервер.
  2. Сервер хранит публичный ключ в ~user/.ssh/authorized_keys.
  3. При подключении сервер проверяет, владеет ли клиент приватным ключом, соответствующим публичному.

Плюсы:

  • brute-force по паролю теряет смысл;
  • невозможно «подобрать» ключ простым перебором логин/пароль;
  • можно легко отозвать доступ, просто удалив строку из authorized_keys.

Поэтому классическая безопасная схема для VPS:

  • включены ключи (PubkeyAuthentication yes);
  • выключены пароли (PasswordAuthentication no);
  • ограничен или запрещён прямой root-доступ.
  1. Логика безопасного sshd_config

Грамотный конфиг решает четыре задачи:

  1. Сетевой доступ и протокол:
    • какой порт;
    • какие ключи хоста;
    • какой протокол SSH.
  2. Политика логина:
    • можно ли входить под root;
    • сколько попыток логина;
    • сколько времени даётся на аутентификацию.
  3. Методы аутентификации:
    • ключи включить;
    • пароли и «диалоговые» методы отключить.
  4. Остальные функции:
    • X11-форвардинг;
    • SFTP;
    • переменные окружения (локали).

Дальше разберём всё на конкретном примере.

  1. Готовый пример безопасного конфига sshd_config

Ниже — пример рабочего конфига, который подходит для типичного VPS в интернете.

Файл: /etc/ssh/sshd_config

# 1. Базовые настройки протокола и порта

Port 22
Protocol 2

# Ключи хоста (идентичность сервера для клиентов)
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# 2. Политика логина и безопасности

LoginGraceTime 30
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 10

# 3. Методы аутентификации

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# 4. Прочие функции SSH

X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*

# 5. SFTP-подсистема

Subsystem sftp internal-sftp

Дальше — подробное объяснение по блокам.

  1. Подробный разбор параметров

5.1. Сеть и протокол

Port 22

На каком порту слушает SSH-сервер.

  • 22 — стандартный порт.
  • Поменять можно, но это не защита, а лишь снижение шума в логах.
Protocol 2

Версия протокола SSH.

  • SSHv1 устарел и небезопасен.
  • В современных OpenSSH фактически всегда используется только протокол 2; эта строка закрепляет это явно.
HostKey ...

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Это ключи самого сервера (host keys).

  • Нужны, чтобы клиент мог проверить, что он подключается к «тому самому» серверу.
  • Типы:
    • rsa — старый, но массово поддерживаемый;
    • ecdsa — эллиптические кривые;
    • ed25519 — современный, быстрый и безопасный.
  • Клиент при подключении выбирает один из поддерживаемых типов.

5.2. Политика логина

LoginGraceTime 30

Время (в секундах), в течение которого после подключения клиент должен успешно аутентифицироваться.

  • После 30 секунд без успешного логина соединение рвётся.
  • Уменьшает количество «висящих» сессий от ботов.
PermitRootLogin no

Управляет логином под пользователем root.

Варианты:

  • yes — разрешён вход root по любому методу (пароль, ключи).
  • prohibit-password — root только по ключам.
  • no — вообще нельзя логиниться как root.

Для VPS из интернета безопаснее всего:

  • PermitRootLogin no
    Рабочая схема:
    • логин под обычным пользователем;
    • повышение привилегий через sudo.
StrictModes yes

Проверяет права и владельцев файлов, связанных с аутентификацией.

  • SSH проверяет:
    • права на домашний каталог;
    • права на ~/.ssh;
    • права и владельца authorized_keys.
  • При неправильных правах (слишком открыты, принадлежит не тому пользователю) ключи игнорируются.

Это защита от подмены ключей через ошибочные права.

MaxAuthTries 3

Максимальное количество попыток аутентификации за одно соединение.

  • Если кто-то пытается перебрать логин/ключи/пароли, за одну сессию получится всего 3 попытки.
  • Боты обычно полагаются на большое число попыток в одной сессии, это создаёт им дополнительные трудности.
MaxSessions 10

Сколько логических сессий можно открыть внутри одного TCP-подключения.

  • Через один SSH-канал можно открыть несколько:
    • интерактивная оболочка;
    • выполнение команд;
    • форвардинг портов.
  • 10 — нормальный рабочий лимит, который предотвращает злоупотребления.

5.3. Методы аутентификации

PubkeyAuthentication yes

Разрешить вход по SSH-ключам.

  • Это основной безопасный метод входа.
  • Работает с файлами ~/.ssh/authorized_keys на сервере.
PasswordAuthentication no

Разрешать ли вход по паролю.

  • no — пароли полностью отключены.
  • Точка опоры для безопасности: брутфорс пароля становится бессмысленным.
KbdInteractiveAuthentication no

Keyboard-interactive аутентификация.

  • Позволяет делать «диалоговые» схемы: запрос/ответ, дополнительные вопросы и т.п.
  • Часто используется как «обход» отключённого PasswordAuthentication, поэтому для жёсткой политики её тоже отключают.
ChallengeResponseAuthentication no

Старый параметр, связанный с challenge-response схемами (OTP и т.п.).

  • Если не используются дополнительные сложные схемы аутентификации, безопаснее отключить, чтобы не было лишних путей входа.
UsePAM yes

Использовать PAM (Pluggable Authentication Modules).

  • Позволяет применять системные политики:
    • ограничения сессий;
    • настройки окружения;
    • общие правила входа.
  • При входе по ключам через PAM обычно проходят только сессионные вещи (MOTD, лимиты и т.п.).

5.4. Остальные функции

X11Forwarding no

Пересылка графического интерфейса (X11) по SSH.

  • yes позволяет запускать удалённые GUI-приложения, которые отображаются локально.
  • На VPS в интернете почти никогда не нужно и увеличивает поверхность атаки, поэтому разумно отключить.
PrintMotd no

Печатать ли MOTD (Message Of The Day) при входе.

  • При no sshd сам MOTD не печатает.
  • Часто MOTD всё равно выводится через PAM, так что эта опция в основном косметическая.
AcceptEnv LANG LC_*

Разрешает принимать от клиента некоторые переменные окружения.

  • В данном случае — локаль (LANG) и связанные переменные (LC_*).
  • Нужны для корректной работы с кодировкой и языком в терминале.
  • Разрешать все переменные окружения небезопасно, но локали — стандартное и разумное исключение.

5.5. SFTP

Subsystem sftp internal-sftp

Определяет подсистему SFTP.

Варианты:

  • Внешний бинарник: Subsystem sftp /usr/lib/openssh/sftp-server
  • Встроенный сервер: Subsystem sftp internal-sftp

internal-sftp:

  • встроен в сам sshd;
  • чуть проще и безопаснее (меньше внешних зависимостей);
  • удобен для ограничений, chroot и т.п.
  1. Пошаговая настройка на VPS без риска потерять доступ

Важно: прежде чем ужесточать конфиг, нужно убедиться, что:

  • есть рабочий SSH-ключ;
  • этот ключ добавлен пользователю, под которым будете входить.

Типичный безопасный сценарий:

  1. Создать обычного пользователя (если его нет). adduser myuser usermod -aG sudo myuser
  2. Создать на локальной машине ключ (если нет): ssh-keygen -t ed25519 Публичный ключ — в ~/.ssh/id_ed25519.pub.
  3. Скопировать публичный ключ на сервер: ssh-copy-id myuser@server_ip или вручную:
    • создать на сервере ~myuser/.ssh;
    • положить содержимое id_ed25519.pub в ~myuser/.ssh/authorized_keys;
    • выставить права: chmod 700 ~myuser/.ssh chmod 600 ~myuser/.ssh/authorized_keys chown -R myuser:myuser ~myuser/.ssh
  4. Проверить вход под новым пользователем: ssh myuser@server_ip Убедиться, что вход происходит по ключу (клиент не спрашивает пароль аккаунта).
  5. Только после этого редактировать /etc/ssh/sshd_config:
    • заменить содержимое на предложенный безопасный конфиг (с поправкой на нужный порт, если он иной);
    • сохранить файл.
  6. Проверить синтаксис конфига: sudo sshd -t Если ошибок нет, команда не выводит ничего.
  7. Перезапустить SSH-демон: sudo systemctl restart sshd # иногда ssh
  8. Не закрывая старую SSH-сессию, открыть новую из другого терминала и убедиться, что вход работает.

Только после этого безопасно завершать старые сессии.

  1. Типичные ошибки и как их избежать
  1. Включили PasswordAuthentication no, но не настроили ключи:
    • результат: сервер перестал пускать всех, кроме уже открытых сессий.
    • профилактика: сначала проверить вход по ключу отдельным пользователем, только потом отключать пароли.
  2. Запретили PermitRootLogin, но забыли про sudo:
    • пользователь не в группе sudo, и root недоступен.
    • профилактика: сразу usermod -aG sudo myuser и проверить sudo whoami.
  3. Неправильные права на ~/.ssh и authorized_keys:
    • из-за StrictModes yes SSH игнорирует ключи.
    • решение: chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R user:user ~/.ssh
  4. Изменили порт SSH, но забыли открыть его в файрволе:
    • сервер недоступен по новому порту.
    • профилактика: при смене порта сначала добавить правило в UFW/iptables, затем перезапускать sshd.

Такой конфиг и подход закрывают основные уязвимости, характерные для VPS, доступного из интернета: отключают пароли, минимизируют роль root, ограничивают методы аутентификации и убирают лишние функции вроде X11-форвардинга.

РубрикаSecurity Ubuntu

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *