PermitRootLogin (вход root по SSH)
PermitRootLogin это директива SSH сервера OpenSSH (sshd_config), которая определяет, может ли учётная запись root входить по SSH и каким способом. Допустимы значения yes, prohibit-password, forced-commands-only и no, а по умолчанию в руководстве указано prohibit-password. Значение no стандартно для защиты: прямой удалённый вход root закрыт, а локальный root и sudo работают.
Какие значения принимает PermitRootLogin и что по умолчанию
В руководстве sshd_config сказано, что аргумент должен быть yes, prohibit-password, forced-commands-only или no, а значение по умолчанию prohibit-password. Старое написание without-password указано там как устаревший псевдоним. Дистрибутив или образ хостера может поставлять файл конфигурации с другим значением, поэтому встроенное значение по умолчанию не всегда совпадает с тем, что работает на вашем сервере.
yes: root может входить любым включённым способом, в том числе по паролю.prohibit-password: для root отключены вход по паролю и keyboard-interactive. В исходном коде OpenSSH (auth_root_allowedв auth.c) остаются только publickey, hostbased и gssapi-with-mic.forced-commands-only: вход по открытому ключу работает, только если у записи ключа есть параметрcommand; все остальные способы для root отключены.no: root получает отказ при любых учётных данных.
Директива управляет только входом через sshd. Она не удаляет и не блокирует учётную запись, а su, sudo и консоль провайдера остаются доступны.
Минимальная безопасная настройка и как её проверить
Задайте значение в том файле, который действительно побеждает (см. следующий раздел), и не закрывайте текущую сессию, пока не пройдёт вход в новой. Сначала убедитесь, что именной администратор с sudo уже работает в другом терминале. Затем:
# /etc/ssh/sshd_config
PermitRootLogin no
sudo sshd -t
sudo sshd -T | grep -i '^permitrootlogin '
sudo systemctl reload ssh # на некоторых дистрибутивах юнит называется sshd
ssh -l root your-server # из второго терминала: должен быть отказ
По руководству sshd(8), ключ -t проверяет корректность файла конфигурации, а -T выводит действующую конфигурацию. Если вы используете блоки Match, добавьте описание соединения, например -C user=root,addr=192.0.2.10,host=server, чтобы подходящие блоки применились перед выводом. Если sshd -T всё ещё показывает старое значение, его перекрывает более ранняя строка или подключённый файл; исправьте это до перезагрузки. Держите под рукой консоль провайдера или режим восстановления на случай, если учётная запись администратора окажется нерабочей.
Взаимодействие с другими настройками и типичные ошибки
По руководству, для каждого ключевого слова используется первое полученное значение. Строка PermitRootLogin, стоящая ниже Include, который уже задаёт её, или ниже более раннего дубликата, игнорируется. Директива разрешена и внутри блока Match, а если её задают несколько подходящих блоков, действует только первое вхождение. Подробнее в статье про sshd_config.
Списки пользователей это отдельный барьер. В исходном коде OpenSSH проверки AllowUsers и DenyUsers выполняются независимо от auth_root_allowed, поэтому root должен пройти обе. Отказ по этой директиве пишется в журнал как "ROOT LOGIN REFUSED FROM" с адресом и портом; по этой строке удобно искать. При forced-commands-only параметр command задаётся в записи ключа в authorized_keys у root, поэтому обычный ключ там root не пустит.
Самая частая ошибка: считать, что значение по умолчанию равно no. При prohibit-password любой ключ, оставшийся в authorized_keys у root, всё ещё даёт рабочий вход.
Место в усилении защиты SSH
Отключение входа root убирает имя учётной записи, которое гарантированно пробует каждый автоматический сканер, и заставляет проводить любые административные действия через именную запись и sudo, что оставляет след о том, кто что сделал. Это один из слоёв, а не полная защита. Сочетайте его с PasswordAuthentication no, ограничением числа попыток через MaxAuthTries и списком разрешённых пользователей.
Порядок действий по шагам описан в руководстве по усилению защиты SSH. Правила sudo для замещающей учётной записи держите узкими, как в материале пользователи, sudo и минимальные привилегии, а второй фактор добавьте по руководству по двухфакторной аутентификации SSH. Общую картину даёт статья вход под root, а первоисточники: руководство sshd_config и исходный код OpenSSH auth.c.
Связанные термины: Вход под root, sshd_config, sudoers, Минимальные привилегии, AllowUsers.
Часто задаваемые вопросы
Какое значение PermitRootLogin по умолчанию?
По руководству OpenSSH это prohibit-password: root не может войти по паролю, но может войти по открытому ключу. Дистрибутив может задавать другое значение, поэтому проверьте командой sudo sshd -T | grep -i permitrootlogin.
Чем prohibit-password отличается от without-password?
По поведению ничем. В руководстве without-password указан как устаревший псевдоним prohibit-password, поэтому в старых конфигурациях и выводе может встречаться это написание.
Нужно ли ставить PermitRootLogin no?
Почти на любом сервере да, когда именной администратор с sudo уже работает. forced-commands-only используйте, только если одной фиксированной задаче автоматизации действительно нужен root, и ограничьте её ключ параметром command.
Я поставил PermitRootLogin no, но root всё равно входит. Почему?
Скорее всего, побеждает другая строка. Используется первое полученное значение, поэтому проверьте подключённые файлы и более ранние дубликаты, а действующее значение смотрите через sshd -T (с -C, если есть блоки Match).
Мешает ли PermitRootLogin no пользоваться sudo или su?
Нет. Директива блокирует только вход root через sshd. После входа под обычным пользователем sudo и su работают как раньше, консоль провайдера тоже не затронута.
Хотите увидеть, в каком состоянии ваш сервер?
Запустите бесплатную read-only проверку сервера или откройте Security Lab и посмотрите цикл обнаружение, сдерживание, восстановление, проверка в действии.
Получить бесплатную проверку сервераОткрыть Security Lab