Когда вы арендуете новый сервер, первой же инженерной задачей становится базовое укрепление периметра. Нужно убрать SSH со стандартного 22-го порта, жестко заблокировать авторизацию по паролям, оставить строго авторизацию по ключам Ed25519 и заблокировать прямой вход для учетной записи root. Девять из десяти мануалов в интернете до сих пор предлагают один и тот же устаревший алгоритм: открыть файловым редактором главный конфигурационный файл /etc/ssh/sshd_config, пролистать пару сотен строк полотна и начать вручную менять параметры.
Забудьте про этот подход. Лезть руками в дефолтный системный файл операционки — это откровенно плохой тон и залог проблем при будущем обслуживании сервера. В современных дистрибутивах Linux (включая Debian) по умолчанию реализована модульная структура конфигурации. Вместо редактирования монолитного файла все свои настройки мы выносим в отдельные, изолированные файлы внутри специального каталога. Давайте разберем, как устроен этот механизм и почему он бережет время и нервы при эксплуатации сервисов.
В чем подвох прямого редактирования sshd_config?
Когда на сервере накатываются системные обновления (например, через apt upgrade), менеджер пакетов периодически обновляет и сам демон OpenSSH. Если разработчики дистрибутива изменили дефолтные параметры безопасности или обновили синтаксис, система попытается обновить конфигурационный файл. Увидев, что вы переписали sshd_config вручную, менеджер пакетов замрет и спросит: затереть ваши правки или оставить старый файл? Если обновления идут в автоматическом режиме или через скрипты, рядом просто создастся файл вида sshd_config.dpkg-dist, а логи замусорятся предупреждениями.
Модульный подход снимает эту головную боль. Главный файл sshd_config остается в первозданном виде — таким, каким его видит пакетный менеджер. Все ваши личные правила живут в отдельном каталоге, и при любом обновлении системы ваши настройки гарантированно сохранятся.
Механика работы директивы Include
Откройте файл /etc/ssh/sshd_config. В самом верху вы увидите следующую директиву:
Include /etc/ssh/sshd_config.d/*.confЭта строчка заставляет демон SSH при старте заходить в папку sshd_config.d/ и по порядку вычитывать содержимое всех файлов, имеющих расширение .conf. Здесь вступает в силу ключевое правило интерпретатора OpenSSH: если один и тот же параметр встречается в конфиге несколько раз, ядро берет самое первое найденное значение, а все последующие — игнорирует.
Так как строка Include прописана в самом начале главного файла, ваши кастомные параметры считываются первыми. Они сходу перекрывают любые дефолтные настройки, записанные ниже по тексту в основном файле. Нам именно это и требуется.
Практика: Собираем изолированный файл безопасности
Давайте с нуля создадим один чистый файл, где зафиксируем всю базовую защиту, не трогая системный sshd_config.
1. Создаем кастомный файл
Имя файла может быть любым понятным, но на конце обязательно должно стоять расширение .conf:
sudo nano /etc/ssh/sshd_config.d/security_hardening.conf2. Прописываем параметры защиты
Вносим только те строки, которые реально меняют поведение службы. Никакой лишней шелухи — строго рабочий набор:
# Перешиваем порт на нестандартный (выбираем любой свободный)
Port 2222
# Запрещаем прямой вход под root (заходим только под обычным юзером)
PermitRootLogin no
# Полностью отключаем авторизацию по паролям
PasswordAuthentication no
# Включаем вход исключительно по SSH-ключам
PubkeyAuthentication yes
# Запрещаем учетки с пустыми паролями
PermitEmptyPasswords no
# Лимитируем параллельные неавторизованные подключения
MaxStartups 10:30:100Сохраняем файл и выходим из редактора.
Обязательный контроль: Проверка синтаксиса и тест
Запомните главное правило работы с сетевыми демонами: никогда не перезапускайте SSH сразу после внесения изменений. Если в конфиге затесалась хоть одна лишняя запятая, опечатка или невалидный символ, служба не сможет стартовать. Если вы при этом успеете закрыть текущий терминал — вы заблокируете себе доступ к серверу.
Шаг 1: Валидация встроенным тестером
Запускаем встроенную проверку синтаксиса OpenSSH с ключом -t (Test):
sudo sshd -tЕсли команда выполнилась молча и вернула чистую строку — синтаксис корректен. Если система вывела ошибки — возвращаемся в наш .conf файл и правим указанные строки.
Шаг 2: Безопасный рестарт
Только убедившись в отсутствии ошибок, отправляем службу в рестарт:
sudo systemctl restart sshПравило страховки: После выполнения команды systemctl restart ни в коем случае не закрывайте окно терминала, в котором работаете. Откройте вторую вкладку на своем компьютере и попробуйте подключиться к серверу по новому порту и с ключом. Если новое подключение успешно установилось — всё настроено идеально, теперь текущую сессию можно закрывать.
Заключение
Модульная настройка сервисов — это признак грамотного администрирования и порядка в системе. Ваш конфигурационный файл содержит всего десяток понятных строк, его легко закинуть в систему контроля версий или быстро скопировать на новый сервер при переезде, а сам дистрибутив обновляется штатно и без конфликтов в конфигах.