Защита SSH-сервера: настройка sshd_config для безопасного доступа

sshd настройка по умолчанию: где ломается доступ

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

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

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

Третья проблема — один общий шаблон на десятки серверов. Файл копируют между машинами, потом правят точечно под конкретную задачу, и через полгода фактическая конфигурация расходится: где-то снова разрешён вход по паролю, где-то открыт вход суперпользователю. Разбираем, как это закрывается.

Что даёт выверенная конфигурация сервера доступа

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

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

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

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

Сравнение подходов: настройка sshd по ключам и по паролю

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

Дешёвый в настройке вариант обычно дороже в эксплуатации: ключи нужно выдавать, отзывать при уходе сотрудника и ротировать. Корпоративный каталог учётных записей снимает эту рутину, но связывает сервер с внешним источником и заставляет заранее решить, что делать при его недоступности.

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

Этапы внедрения: от аудита конфигурации до передачи

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

1. Аудит текущей конфигурации. Снимаем рабочие файлы настройки со всех серверов, фиксируем учётные записи, разрешённые методы входа и то, кто с каких адресов реально подключается. Сводим в один документ расхождения между машинами — обычно они и есть источник лишних прав.
2. Схема доступа по ролям. Разводим администраторов, дежурных и сервисные учётные записи: кому вход по ключу, кому только с определённых адресов, какие группы ограничены набором команд. Схема становится основой конфигурации, а не наоборот.
3. Тестовый контур. Копируем текущие настройки на отдельные машины и обкатываем правила там, включая проверку входа новых ролей.
4. Поэтапная правка. Включаем изменения блоками: сначала ключи, затем отказ от паролей, затем ограничения для служебных записей. Новое подключение проверяем в отдельной сессии, текущую держим открытой до подтверждения.
5. Обратный откат. Перед каждым шагом сохраняем рабочую копию конфигурации и держим готовый сценарий возврата: восстановить файл и перезапустить службу одним действием.
6. Контроль на боевых серверах. Раскатываем группами с паузой, чтобы отказ проявился на части парка, а не на всех сразу.
7. Передача документации. Отдаём итоговые конфигурации, регламент выдачи и отзыва ключей, порядок действий при уходе сотрудника и памятку для дежурного.

Что остаётся у вас после работ: конфигурации и регламенты

Настроенный доступ бесполезен, если сопровождать его может только автор правки. Поэтому вместе с работами передаём комплект, по которому ваш инженер воспроизводит конфигурацию с нуля, а новый человек вводится в доступ без переписки в чатах и поиска «того самого» скрипта. Ниже — что именно остаётся у вас.

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

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

Кейс: как закрыли подбор паролей на парке серверов

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

Что показал аудит

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

Что сделали и что получилось

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

Доля серверов с единым шаблоном — 100% вместо двух третей. Неуспешные попытки входа упали на два порядка, успешные входы с чужих адресов прекратились. Время отзыва доступа сократилось с двух дней до 15 минут, разбор инцидентов входа — с недели до получаса: журналы сопоставимы, потому что узлы настроены одинаково.

Чем отличается вход по ключам от входа по паролю

Пароль проверяет сам сервер: sshd сверяет введённое значение с хешем в системной базе и пускает любого, кто его знает. Ключ — это асимметричная пара, где на сервере в authorized_keys лежит только открытая часть, а закрытая не покидает рабочую машину инженера и не передаётся по сети. Перехваченный пароль можно ввести повторно с чужого адреса, а подделать подпись без закрытого ключа нельзя.

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

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

Технические сомнения перед правкой конфигурации

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

Автоматизация встанет, если поменять правила входа. Как избежать простоя?

Ключи и адреса, с которых ходят сборочные и обменные системы, переносим в явные исключения до правок. Правило проверяем на одном узле, затем раскатываем по парку, сохраняя резервный вход до подтверждения. Общие и наследуемые учётные записи не сносим вслепую: переводим на отдельные ключи с ограничением по адресу, а где запись нужна по регламенту — сужаем до одной разрешённой команды.

Подрядчику нужен доступ на время работ — как выдать и закрыть?

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

Если после правки доступ пропал — как вернуться?

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

Обсудим вашу конфигурацию доступа и план работ

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

На разборе пройдём по каждому пункту и зафиксируем, где реальный риск, а где осознанное исключение, которое нужно сохранить.

• Перечень серверов и ролей: сколько машин, какие группы администраторов и сервисов подключаются, есть ли промежуточный узел для входа во внутреннюю сеть.
• Текущий sshd_config с типовых узлов — по нему видно расхождения между средами и «наследство» от прошлых настроек.
• Требования к доступу: кому и откуда нужен вход, какие системы ходят по ключам автоматически, где пароль остаётся вынужденным исключением.
• Схема аутентификации: где хранятся ключи, используются ли аппаратные носители, сертификаты или срок жизни ключей ограничен.
• Внешние требования: правила аудита, журналирование входов, изоляция сети, доступ для подрядчиков и его срок.
• Окна изменений: когда допустимо менять конфигурацию и перезапускать службу и кто подтверждает проверку после правок.

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