Как усилить конфигурацию SSH-сервера

Файл sshd_config — это вся поза безопасности вашего SSH-сервера в одном текстовом файле, а на большинстве систем он поставляется в состоянии, оптимизированном под совместимость, а не под безопасность. Вход по паролю включён по умолчанию, root может войти, пока используется ключ, неактивные сессии никогда не завершаются, а алгоритмы, которые предлагает ваш сервер, — те, что решила установленная много лет назад версия OpenSSH. Усиление — это не копирование контрольного списка 2021 года: алгоритмы удаляются, значения по умолчанию меняются, и конфигурация, которая пять лет назад была образцовой, сегодня может быть слабой. В этой статье объясняется, что на самом деле делает каждое изменение, почему важен порядок ваших решений и как протестировать новую конфигурацию, не заперев себя снаружи. Свой файл можно проверить построчно в аудиторе конфигурации SSH-сервера, который сверяет его с эталоном от 2026-11-13 — полностью в вашем браузере.

Значения по умолчанию — отправная точка, а не поза безопасности

OpenSSH поставляется со значениями по умолчанию, выбранными так, чтобы свежая установка работала для как можно большего числа людей, — и именно поэтому они не являются позой безопасности. Текущие значения по умолчанию, задокументированные на странице руководства sshd_config, включают PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 секунд и ClientAliveInterval 0, что означает, что неактивные сессии никогда не завершаются. Ни одно из них не является ошибкой: каждое — осознанный выбор в пользу совместимости, и каждое — замечание в аудите усиления.

Практическое следствие таково: сервер, который никто никогда не усиливал, по-прежнему доступен перебором паролей, по-прежнему принимает вход root с украденным ключом и по-прежнему оставляет брошенные сессии открытыми бесконечно. Значения по умолчанию со временем меняются — то, что поставляет OpenSSH 10.6, не то, что поставлял OpenSSH 7, — поэтому «я никогда ничего не менял» — не нейтральное утверждение. Оно означает, что ваша поза безопасности — та, которую решила случайно установленная версия, а единственный способ это узнать — прочитать файл. Это первая задача аудита: сделать невидимые значения по умолчанию видимыми, потому что директива, отсутствующая в файле, всё равно действует.

Отключение паролей важнее смены порта — всегда

Самое эффективное изменение в sshd_config — это PasswordAuthentication no в сочетании с PubkeyAuthentication yes: с этого момента ни один пароль — угаданный, утёкший или выманенный фишингом — не сможет открыть сессию, потому что демон больше не принимает такой вид доказательства. Аутентификация по ключу меняет атаку с «угадать секрет, выбранный человеком» на «украсть файл закрытого ключа, который никогда не пересекает сеть», поэтому каждый эталон усиления, включая Mozilla, начинается именно здесь. Если из этой статьи нужно вынести что-то одно, пусть это будет оно: сгенерируйте пару ключей (см. набор ключей SSH и сопутствующую статью ключи SSH: объяснение), установите открытый ключ, убедитесь, что можете войти с ним, и только потом отключайте пароли.

Смена порта с 22 на какой-нибудь малоизвестный, напротив, — не усиление, а сокрытие. Она снижает шум в ваших журналах, потому что большинство сканеров всего интернета стучатся только в порт 22, но не останавливает ни одного атакующего, который потрудится просканировать: сканирование портов находит демон за секунды, а демон за ним ровно настолько силён, насколько сильна его конфигурация. Поэтому аудитор трактует порт, отличный от 22, только как информацию, а не как оцениваемое улучшение. Есть одна ловушка, о которой стоит знать, прежде чем щёлкнуть переключатель: в системах, использующих PAM, одного PasswordAuthentication no недостаточно — клавиатурно-интерактивная аутентификация всё ещё может позволить PAM принять пароль, поэтому стек PAM в /etc/pam.d/sshd тоже должен отклонять пароли. В рекомендациях Mozilla это сказано прямо, и это самая часто пропускаемая вторая половина изменения.

Вход root: что на самом деле разрешает prohibit-password

У PermitRootLogin четыре значения, и разница между ними — это разница между наличием следа аудита и его отсутствием. Значение по умолчанию, prohibit-password, разрешает вход root — просто не по паролю. Украденный ключ root всё равно проходит беспрепятственно, а как только сессия становится root, ничто в журналах не отличает одного администратора от другого. Современный профиль Mozilla устанавливает его в No, и это усиленный ответ: root вообще не должен быть учётной записью для входа. Входите как именованный пользователь и используйте sudo; тогда каждое привилегированное действие можно отнести к конкретному человеку.

Промежуточные значения существуют не просто так, и их стоит знать, а не бояться. forced-commands-only разрешает вход root только когда предъявленный ключ ограничен одной командой в authorized_keys — шаблон, который используют скрипты резервного копирования и мониторинга, — и это законный, осознанный выбор для автоматизации. Незаконно же значение yes, которое разрешает вход root по паролю и является ошибкой в любом аудите. Практическое правило: если человек входит как root, конфигурация неверна; если это скрипт, ограничьте ключ одной командой и напишите об этом в комментарии, иначе следующий человек, прочитавший файл, его «исправит».

Устаревание алгоритмов — движущаяся цель

У алгоритмов в вашей конфигурации есть срок годности, и он короче, чем вы думаете. OpenSSH 10.0, выпущенный 2025-04-09, полностью удалил поддержку DSA (ssh-dss), убрал Диффи–Хеллмана на конечном поле из обмена ключами сервера по умолчанию и сделал mlkem768x25519-sha256 — постквантовый гибрид — согласованием ключей по умолчанию. Конфигурация, скопированная из блога 2021 года, может до сих пор перечислять diffie-hellman-group1-sha1, 3des-cbc, arcfour или hmac-md5 — в современном аудите всё это ошибки, а некоторые из них установленный демон уже даже не поддерживает. Конфигурация не изменилась; изменился мир.

Поэтому эталон усиления должен нести дату, а перепроверка — часть работы, а не запоздалая мысль. Современный профиль Mozilla — обмен ключами curve25519, шифры chacha20-poly1305 и AES-GCM, MAC SHA-2 с шифрованием-перед-аутентификацией (EtM) — это эталон, но он старше постквантовых обменов ключами, которые OpenSSH 10.0 сделал значениями по умолчанию, поэтому аудит 2026 года принимает наряду с ними также mlkem768x25519-sha256 и sntrup761x25519-sha512. Привычка, которая держит вас в курсе, стоит дёшево: раз или два в год запускайте на сервере ssh -Q kex, ssh -Q cipher и ssh -Q mac, чтобы увидеть, что на самом деле предлагает установленная версия, сверьте это с актуальными рекомендациями Mozilla и прогоните аудитор по тому же файлу ещё раз. Чистый балл 2021 года — исторический документ, а не текущий.

Блоки Match и Include: два способа, которыми чистый аудит лжёт

Файл конфигурации — не плоский список настроек, а программа с условными ветвлениями, и две возможности могут сделать так, что файл, который читается как усиленный, ведёт себя так, будто это не так. Первая — блок Match: директивы внутри Match User, Match Group или Match Address применяются только при выполнении критериев, а страница руководства прямо говорит: если ключевое слово встречается в нескольких удовлетворённых блоках Match, применяется только первый экземпляр. Глобальный PasswordAuthentication no, за которым следует блок Match, тихо включающий пароли обратно для одной группы, — реальная конфигурация, и именно то, что построчное чтение пропускает. Находки внутри блока Match условны, никогда не глобальны, и честный аудит ограничивает их именно так.

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

Безопасное внедрение: проверьте, прежде чем закрыть дверь

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

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

Источники

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

Стоит ли менять порт SSH с 22?

Это снижает шум в журналах, потому что большинство автоматических сканеров проверяют только порт 22, — но это не усиление. Сканирование портов находит демон на любом порту за секунды, а демон ровно настолько силён, насколько сильна его конфигурация. Относитесь к нестандартному порту как к наведению порядка, а не как к замене отключения аутентификации по паролю, ограничения входа root и удаления слабых алгоритмов. Аудитор оценивает его только как информацию.

Я установил PasswordAuthentication no, но по-прежнему могу войти по паролю. Почему?

Почти всегда дело в PAM. В системах, где sshd использует PAM, клавиатурно-интерактивная аутентификация всё ещё может передавать проверку пароля в PAM даже после отключения PasswordAuthentication — в рекомендациях Mozilla прямо предупреждается, что «одного PasswordAuthentication no недостаточно» в такой конфигурации. Проверьте /etc/pam.d/sshd и убедитесь, что ни один модуль пароля (например, pam_unix.so или include password-auth) недостижим для sshd, а затем протестируйте новый вход, прежде чем закрывать текущую сессию.

Как часто нужно повторно проверять sshd_config?

Не реже раза в год и после каждого обновления OpenSSH. Алгоритмы удаляются по расписанию — OpenSSH 10.0 полностью отказался от DSA и изменил обмен ключами по умолчанию, — поэтому конфигурация, получившая чистый балл в 2021 году, может быть слабой в 2026-м, хотя ни одна строка не изменилась. Прогоните аудитор по тому же файлу ещё раз, проверьте дату эталона на странице и подтвердите установленную версию командами ssh -Q kex, ssh -Q cipher и ssh -Q mac.