Чек-лист харденинга SSH: как настроить вход и проверить результат
Чек-лист харденинга SSH помогает убрать лишние способы входа на VPS. Харденингом называют настройку защиты сервера. Безопасная настройка sshd_config сводится к тому, чтобы оставить один проверенный способ входа и уметь вернуть доступ, если что-то пойдёт не так.
Примеры рассчитаны на Ubuntu 24.04 LTS с OpenSSH из репозитория ОС. Параметры для другой ОС и требования аудита лучше заранее уточнить.
Какие параметры sshd_config важнее всего для аудита?
Основные параметры: PermitRootLogin для входа под root, PasswordAuthentication и KbdInteractiveAuthentication для способов проверки пользователя, AllowUsers или AllowGroups для ограничения круга пользователей. При многофакторной аутентификации важен AuthenticationMethods, который задаёт обязательные способы подтверждения входа. Результат настройки проверяют реальными попытками разрешённого и запрещённого входа.
Что именно нужно защитить
Безопасная настройка sshd_config начинается со списка тех, кому нужен SSH: владельца VPS, коллег, программы резервного копирования.
Пароль могут подобрать, ключ могут украсть, а доступ бывшего сотрудника иногда остаётся действующим месяцами. Вход только по ключам исключает подбор пароля. Украденный ключ нужно отозвать, а лишние учётные записи закрыть. Второй фактор, например одноразовый код, снижает риск входа с украденным ключом. Отдельная угроза – потеря журналов: если записи о входах хранятся только на самом сервере, злоумышленник с правами root может их изменить, и восстановить картину будет нечем.
Ошибка в настройках может закрыть вход самому администратору. До изменений проверьте, что консоль провайдера даёт доступ к файлам с правами администратора. В команде при необходимости назначьте ответственного за эту проверку.
Какие настройки сервер действительно использует
В чек-лист аудита SSH внесите версии ОС и OpenSSH, исходные настройки. Их покажут команды на сервере:
cat /etc/os-release
sudo /usr/sbin/sshd -V
sudo /usr/sbin/sshd -T
В Ubuntu файл /etc/ssh/sshd_config подключает через Include файлы из /etc/ssh/sshd_config.d/. Обычно действует первое прочитанное значение, а порядок чтения определяется именами файлов. Поэтому правка в конце основного файла может не сработать. Подробности есть в документации Ubuntu.
Блоки Match задают исключения для пользователей и адресов. Параметр -C учитывает их для конкретного подключения:
sudo /usr/sbin/sshd -T \
-C user=admin,addr=198.51.100.10,host=client.example
sudo ss -ltnp
Подставьте своего пользователя, IP и имя клиента. Если Match содержит условия на адрес и порт сервера, укажите их через laddr и lport. Вывод -T показывает то, что записано в файлах на диске. Уже открытые сеансы продолжают работать по прежним настройкам, поэтому проверять изменения нужно новым подключением. Слушающие порты покажет команда ss, а её вывод стоит сверить с правилами межсетевого экрана на VPS и в панели провайдера.
Кому принадлежат учётные записи и ключи
Составьте список всех учётных записей, которые могут войти и выполнять команды. Отдельно отметьте тех, кто может выполнять команды от имени администратора через sudo. В authorized_keys хранятся разрешённые открытые ключи. У каждого должен быть известен владелец, потому что подпись рядом с ключом ещё не подтверждает его личность. Отключение входа по паролю SSH лучше делать только после того, как этот список собран.
Личные аккаунты помогают различать администраторов в журнале. Программе резервного копирования выделите отдельный ключ. Параметр command= в authorized_keys ограничивает его заданной командой, а restrict отключает дополнительные возможности, включая туннели. После настройки по справке OpenSSH убедитесь, что копирование работает.
При плановой замене ключа сначала проверьте новый, затем удалите старый со всех серверов. Удаление ключа не завершает открытые сеансы, поэтому при краже их придётся проверить отдельно.
Как отключить вход по паролю и не потерять доступ?
Сначала войдите по ключу под отдельным пользователем с sudo в новом SSH-сеансе и оставьте старое подключение открытым. До применения изменений проверьте конфигурацию, доступ через консоль провайдера и порядок отката. После применения повторите вход. Если используется многофакторная аутентификация, проверьте также работу второго фактора.
Какие способы входа оставить
Следующий пример разрешает вход только по ключам. Вместо admin укажите имя пользователя, под которым вы уже проверили вход и sudo:
# Вход только по ключу; без второго фактора через PAM
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers admin
В AllowUsers включите всех нужных пользователей и служебные аккаунты. Если удобнее управлять группой, вместо списка имён можно использовать AllowGroups. MFA и allowlist для SSH работают вместе: список ограничивает круг пользователей, второй фактор защищает от украденного ключа.
Параметр PermitRootLogin со значением no запрещает прямой вход под root. Значение prohibit-password сохраняет вход root по ключу.
Для ключа и одноразового кода через PAM, систему аутентификации Linux, нужны другие значения. Прежние значения замените следующими, а UsePAM добавьте, если его ещё нет:
UsePAM yes
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam
Такая многофакторная аутентификация (MFA) работает лишь с заранее настроенным PAM-модулем. Сам keyboard-interactive может запрашивать обычный пароль. Поэтому одного PasswordAuthentication no недостаточно для запрета всех способов парольного входа.Как применить изменения и вернуться назад
До правок проверьте вход по ключу в новом соединении. На своём компьютере выполните команду со своим логином и адресом VPS:
ssh -o ControlPath=none -o PreferredAuthentications=publickey \
admin@SERVER
Команда создаёт новое соединение и допускает только вход по ключу. Для MFA через PAM укажите в PreferredAuthentications publickey,keyboard-interactive. В новом сеансе проверьте sudo. Старый оставьте открытым.
В этом примере меняется только новый файл /etc/ssh/sshd_config.d/00-local-access.conf. Это имя и имя с окончанием .disabled должны быть свободны. Сохраните вывод -T до правок. После них убедитесь, что нужные значения действуют для каждого условия Match.
Сначала выясните, как запущен SSH. Команда systemctl is-enabled ssh.socket покажет, включена ли активация через сокет. В Ubuntu она включена по умолчанию с версии 22.10. sshd не работает постоянно, а поднимается на каждое входящее соединение и читает конфигурацию заново, поэтому reload не нужен, достаточно открыть новый сеанс. Если сокет отключён и работает постоянная служба, изменения применяет reload:
systemctl is-enabled ssh.socket
sudo /usr/sbin/sshd -t && sudo systemctl reload ssh.service
Проверка -t при успехе ничего не печатает. При ошибке команда после && не выполнится. Запрет root login и остальные ограничения проверяют попытками входа: повторите вход по ключу, проверку sudo и попытки запрещённого входа.
Для отката в старом сеансе или консоли переименуйте файл, после этого он не попадает под маску *.conf.
sudo mv /etc/ssh/sshd_config.d/00-local-access.conf \
/etc/ssh/sshd_config.d/00-local-access.conf.disabled
sudo /usr/sbin/sshd -t
Этот откат относится только к новому файлу. PAM, межсетевой экран и порт меняйте отдельно, с собственными командами возврата. Старый сеанс закройте лишь после всех проверок.
Что делать с туннелями и алгоритмами
Безопасность SSH на VPS зависит и от возможностей после входа. Например, SSH-туннель передаёт трафик другой программы через зашифрованное соединение.
AllowTcpForwarding управляет TCP-туннелями. X11Forwarding разрешает вывод окон серверных программ на компьютер пользователя. AllowAgentForwarding даёт доступ через сервер к агенту с ключами на компьютере пользователя. Ненужные возможности стоит отключить. При этом пользователь с командной оболочкой может обойти запрет туннелей собственной программой пересылки трафика.
В поддерживаемой версии OpenSSH начните с настроек по умолчанию. Перед изменением списка шифров нужна проверка клиентов. Обновления лучше устанавливать регулярно.
MaxAuthTries ограничивает попытки входа в одном соединении. При слишком низком значении клиент может не успеть предложить подходящий ключ. ClientAliveInterval задаёт интервал проверки связи с клиентом. Пауза в наборе команд сама по себе не приводит к отключению.
Достаточно ли Fail2ban и нестандартного порта?
Нет, этих мер мало.
1. На другом порту обычно меньше автоматических попыток входа, но сканирование всё равно его найдёт.
2. Блокировка адресов за неудачные входы сдерживает перебор, однако украденный рабочий ключ пройдёт проверку с первой попытки.
3. Нужны контроль ключей и пользователей, ограничения доступа, обновления и журналы, а второй фактор выбирают с учётом рисков.
Как ограничить сеть и сохранить события входа
Межсетевой экран может принимать SSH только с адресов администраторов. Проверьте вход из разрешённой и посторонней сети, включая IPv6, если он используется.
Fail2ban временно блокирует адреса после серии неудачных входов. После установки убедитесь, что он читает журнал SSH и применяет блокировки. Тестовые попытки входа тоже могут привести к блокировке вашего IP.
Журнал должен содержать успешные входы, отказы и административные действия через sudo. Недавние записи в Ubuntu можно посмотреть так:
sudo journalctl -u ssh.service --since "30 minutes ago"
sudo journalctl SYSLOG_IDENTIFIER=sudo --since "30 minutes ago"
Злоумышленник с правами root может изменить локальный журнал. Копия на отдельном сервере поможет восстановить события. Убедитесь, что записи действительно туда попадают, время на обеих машинах синхронизировано по NTP, а журналы хранятся столько, сколько требует ваш аудит. Администраторам VPS не нужны права удаления этой копии.
Как подтвердить результат проверки
Отчёт содержит версии ОС и OpenSSH, список подключённых файлов, перечень пользователей и ключей, настройки до и после правок. К сравнению файлов до и после правок (diff) добавьте причины изменений. Приватные ключи и секреты второго фактора в отчёт входить не должны. Собранные файлы и результаты тестов и есть audit evidence, которое запросит аудитор.
В таблице ниже указаны ожидаемые результаты. Каждый сценарий нужно проверить на своём сервере:
Администратор из AllowUsers с верным ключом: вход и работа sudo
Тот же пользователь только с паролем: отказ во входе
Root с верным ключом: отказ во входе
Пользователь вне AllowUsers с верным ключом: отказ во входе
Подключение из запрещённой сети при настроенном межсетевом экране: блокировка межсетевым экраном
Возврат прежней конфигурации: новый вход по прежним правилам
Для проверки парольного входа выполните на своём компьютере:
ssh -o ControlPath=none -o PubkeyAuthentication=no \
-o PreferredAuthentications=password,keyboard-interactive \
admin@SERVER
Этот тест отключает ключи. Пользователя вне AllowUsers проверяйте с верным ключом, иначе причина отказа останется неясной. При MFA нужны попытки с верным, неверным и пропущенным кодом.
Рядом с результатом укажите дату, своё имя, адрес клиента и запись в журнале. Сетевую блокировку можно подтвердить ростом счётчика нужного правила межсетевого экрана. После обновлений и изменений в команде повторите проверку доступа.
Хороший результат выглядит просто: разрешённый пользователь входит, запрещённые сценарии получают отказ, а откат проверен заранее и не зависит от того, работает ли SSH. Чек-лист харденинга SSH храните вместе с инструкцией восстановления доступа. У каждого исключения должны быть причина, владелец и дата пересмотра. Так следующий администратор сможет отличить рабочую необходимость от забытой временной настройки.


















