U-SERVER
Безопасность серверов

Учётные записи, sudo и парольная политика в Linux

Как разделить привилегии в Linux, безопасно настроить sudo, PAM-политику паролей, сроки действия и блокировку учётных записей.

20 минут
абстрактная иллюстрация управления правами Linux-пользователей
Выдавайте доступ через персональные обычные учётные записи, ролевые группы и точные правила sudoers, а не через общий пароль root или общий административный аккаунт. Политику локальных паролей, их истории, срока действия и реакции на ошибки входа настраивают штатными средствами дистрибутива и PAM, сохраняя проверенный аварийный путь. Любое изменение проверяйте в отдельной сессии, не закрывая единственную работающую привилегированную сессию.

Не теряйте доступ во время изменений

До изменения sudoers, PAM, срока действия учётных записей или состояния root оставьте открытой текущую привилегированную сессию и подготовьте независимый способ восстановления: консоль гипервизора, BMC, физическую консоль или документированную аварийную учётную запись. Удалённый SSH-доступ, ключи и запрет входа root рассматриваются отдельно в статье «Безопасная настройка SSH: ключи, root и ограничение доступа».

1. Спланируйте роли и аварийный доступ

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

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

Пример матрицы ролей до создания учётных записей

РольУчётная запись и группаРазрешённые действияЧто не разрешать по умолчанию
Системный администраторПерсональная учётная запись, группа %sysadminОбслуживание ОС по утверждённому перечнюОбщий root-пароль и неограниченный доступ подрядчиков
Оператор приложенияПерсональная учётная запись, группа %app-opsСтатус, restart конкретной службы, просмотр её журналовРедактирование системных файлов, пакетный менеджер, произвольный shell от root
ПодрядчикОтдельная персональная учётная запись, группа %vendor-<service>Только команды для согласованной работы, желательно с датой отзываЧленство в общей группе администраторов
АвтоматизацияОтдельная служебная учётная записьОдна определённая операция или API-действиеИнтерактивный административный вход без обоснования
Аварийный доступОтдельная контролируемая учётная записьВосстановление управления по процедуреПовседневное использование

Инвентаризация перед настройкой прав доступа Linux

Сначала зафиксируйте действующее состояние. Это позволяет отличить запланированное ограничение от случайной блокировки и подготовить откат.

  1. 1
    Определите, кто и как администрирует сервер
    Запишите персональные, служебные и аварийные учётные записи, владельца каждой записи, требуемые команды, срок доступа и допустимые целевые учётные записи. Отдельно отметьте LDAP, Active Directory, SSSD, Kerberos и иные внешние источники идентичности: локальная PAM-политика может к ним не применяться.
  2. 2
    Проверьте текущего пользователя и его группы
    В текущей сессии выполните id. В выводе должны быть видны имя пользователя, UID, основная и дополнительные группы. Сохраните результат вместе с текущими правилами sudo: это исходная точка для отката.
  3. 3
    Проверьте действующие права sudo
    Выполните sudo -l от проверяемой учётной записи. Команда показывает разрешённые команды, целевые пользователи и применимые параметры. Если пароль sudo неизвестен или команда не выполняется, не меняйте политику из этой сессии: используйте уже проверенный привилегированный путь.
  4. 4
    Подготовьте независимый аварийный канал
    Убедитесь, что доступна консоль сервера или другой документированный способ восстановления. Если единственный путь — SSH, сначала подготовьте и проверьте резервный доступ по процедуре из статьи о настройке SSH. Не считайте открытое SSH-подключение аварийным каналом: оно может быть оборвано изменением PAM или учётной записи.
Показывает группы текущего пользователя и его фактические разрешения sudo. Выполняйте до и после изменения прав.
id && sudo -l
Вывод:
Ожидаемый результат: `id` выводит UID и группы, а `sudo -l` — список разрешённых команд либо сообщение, что пользователю не разрешён sudo.

2. Создайте персональные учётные записи и ролевые группы

Имена групп и способы создания пользователей различаются между дистрибутивами, но логика одинакова: создайте группу для роли, добавьте в неё только нужных людей и привяжите правило sudo к группе. В примере ниже %app-ops — группа операторов приложения, а <user> — реальная персональная учётная запись.

Создаёт группу роли, добавляет в неё пользователя и проверяет членство. Если группа уже существует, `groupadd` завершится ошибкой — сначала проверьте её через `getent group app-ops`.
sudo groupadd app-ops
sudo usermod -aG app-ops <user>
id <user>
Вывод:
В выводе `id <user>` должна появиться группа `app-ops`. Новая группа обычно начинает действовать в новой пользовательской сессии.

Локальные и внешние учётные записи

Команда usermod управляет локальными записями из файловой базы ОС. Для пользователей LDAP, Active Directory, SSSD или Kerberos членство и срок действия могут управляться каталогом или его правилами. Проверяйте источник записи через getent passwd <user> и сопровождайте доступ в той системе, которая является источником истины.

3. Настройте ограниченные правила sudo

Правило sudo должно отвечать на три вопроса: кто запускает команду, от имени кого и какую именно команду с какими аргументами. Разрешение ALL для команды или целевого пользователя почти всегда шире, чем требуется. В sudoers имя группы начинается с %; путь к команде указывают абсолютный.

Версии sudo и конфигурация дистрибутива

Синтаксис sudoers, обработка #include и #includedir, порядок файлов, допустимые имена файлов, требования к правам, журналирование и журналирование ввода-вывода определяются установленной версией sudo и политикой дистрибутива. Для точной проверки используйте документацию поставщика ОС и справочные страницы sudoers(5), visudo(8) и sudo(8). Обычно каталог sudoers.d подключён из основного файла, но это нужно подтвердить на конкретном хосте.
/etc/sudoers.d/app-ops
# Операторы приложения могут посмотреть статус без запуска pager
# и перезапустить только одну службу.
# Команды запускаются от root; пароль пользователя sudo требуется.
%app-ops ALL = (root) /usr/bin/systemctl --no-pager status <service>.service, \
                 /usr/bin/systemctl restart <service>.service

Замените <service> конкретным именем службы до сохранения файла. Такое правило не должно становиться шаблоном для произвольных служб: запись вида /usr/bin/systemctl * может позволить запускать или менять другие сервисы. Если операция требует параметров, сопоставьте их с синтаксисом sudoers: отсутствие спецификации аргументов обычно означает, что допустимы любые аргументы; пустая строка аргументов "" означает, что аргументы запрещены.

Команды, которые часто дают фактический root-доступ

Не разрешайте без отдельной оценки редакторы, оболочки и интерпретаторы (vi, vim, nano, less с shell-escape, bash, sh, python, perl, ruby), универсальные файловые менеджеры, пакетные менеджеры, systemctl без ограничения имени службы, sudoedit для чувствительных путей, архиваторы с выполнением внешних команд и средства загрузки или записи файлов в системные каталоги. Многие из них умеют открыть shell, выполнить произвольную программу, изменить конфигурацию запуска или подменить исполняемый файл.

Даже точный путь к безопасной на вид программе не гарантирует ограничение привилегий. Оцените, читает ли команда конфигурацию из доступного пользователю места, запускает ли дочерние процессы, принимает ли произвольные пути или может ли изменить единицу systemd. Если требуется регулярно выполнять сложную привилегированную операцию, безопаснее подготовить отдельный root-owned скрипт с фиксированной логикой и разрешить только его.

/usr/local/sbin/restart-application
#!/bin/sh
# Скрипт должен принадлежать root и не быть доступным для записи группе операторов.
exec /usr/bin/systemctl restart <service>.service
/etc/sudoers.d/app-ops
# Разрешён только подготовленный скрипт без пользовательских аргументов.
%app-ops ALL = (root) /usr/local/sbin/restart-application ""

Проверьте не только sudoers

Ограниченный sudo-скрипт сохраняет смысл только если пользователь не может изменить сам скрипт, его каталог, подключаемые им файлы конфигурации и исполняемые зависимости, влияющие на результат. Права файлов, setuid, capabilities и иные процессные механизмы требуют отдельного разбора и не заменяются правилом sudo.

Когда допустим NOPASSWD

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

/etc/sudoers.d/automation-<account>
# Только для документированной автоматизации; команда и её аргументы фиксированы.
<account> ALL = (root) NOPASSWD: /usr/local/sbin/<approved-task> ""

Не используйте NOPASSWD: ALL. Он превращает компрометацию обычной сессии этой учётной записи в немедленный привилегированный доступ. Парольная аутентификация sudo также не заменяет MFA, ограничение сети, защиту SSH-ключей и управление секретами.

4. Вносите изменения через visudo и проверяйте их во второй сессии

visudo редактирует и проверяет файл политики sudo, предотвращая часть ошибок параллельного редактирования и синтаксиса. Для локальных дополнений используйте отдельный файл в подключённом sudoers.d, а не меняйте поставляемый основной файл без необходимости. Имя файла делайте простым: некоторые реализации игнорируют файлы с точкой или символами, не допускаемыми их правилами.

Безопасная настройка sudoers

  1. 1
    Откройте отдельный файл через visudo
    Из рабочей привилегированной сессии выполните sudo visudo -f /etc/sudoers.d/<role>. Добавьте одно минимальное правило с реальными абсолютными путями к командам. Не закрывайте эту сессию.
  2. 2
    Проверьте синтаксис до применения
    Сохраните файл. При корректном синтаксисе visudo должен сохранить его без сообщения об ошибке; при ошибке редактор предложит вернуться к исправлению. Затем явно проверьте файл командой sudo visudo -c -f /etc/sudoers.d/<role>.
  3. 3
    Проверьте владельца и режим файла
    Выполните sudo ls -l /etc/sudoers.d/<role>. Файл должен принадлежать root и не быть доступным для записи группе или другим пользователям. Если sudo сообщает, что файл игнорируется из-за режима, исправьте владельца и права по документации вашей ОС.
  4. 4
    Откройте вторую сессию проверяемого пользователя
    В новой сессии выполните sudo -l, затем запустите ровно разрешённую команду и одну заведомо неразрешённую. Ожидаемый результат: первая выполняется в разрешённых пределах, вторая получает отказ.
  5. 5
    Сохраните правило и условия его пересмотра
    Зафиксируйте владельца группы, назначение, разрешённые команды, дату выдачи и дату пересмотра или отзыва доступа. Для расследования действий и длительного хранения событий используйте отдельную процедуру из статьи «Аудит безопасности Linux: auditd, журналы входов и контроль действий».
Проверяет основной набор sudoers и отдельный файл. Запускайте после каждого изменения.
sudo visudo -c
sudo visudo -c -f /etc/sudoers.d/<role>
Вывод:
Ожидаемый результат: сообщения вида `parsed OK`. При синтаксической ошибке не пытайтесь исправлять её из непривилегированной сессии; вернитесь к ещё работающей аварийной или административной сессии и откатите файл через `visudo`.

Проблема

sudo permission denied или «user is not in the sudoers file»

Возможные причины

  • Пользователь не состоит в нужной группе или работает в старой сессии.
  • Файл в `sudoers.d` не подключён, имеет неподходящее имя, владельца или права.
  • Правило не совпадает с фактическим путём команды, аргументами, хостом или целевым пользователем.
  • Другая совпадающая запись, её теги, порядок правил или параметры `Defaults` изменяют итоговое разрешение.

Решение

Проверьте id <user> и getent group <group>, затем откройте новую сессию пользователя. От имени этого пользователя выполните sudo -l и просмотрите все совпадающие разрешения и ограничения. Из привилегированной сессии проверьте sudo visudo -c, подключение sudoers.d, владельца и режим файла. Сверьте абсолютный путь через command -v <command>, фактические аргументы, целевого пользователя, теги и применимые параметры Defaults с документацией установленной версии sudo.

Как избежать

Создавайте одно правило на роль или задачу, редактируйте его только через `visudo` и всегда тестируйте в новой сессии до закрытия старой.

Проблема

sudoers syntax error

Возможные причины

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

Решение

Не редактируйте файл обычным редактором из-под непривилегированного пользователя. Откройте его через visudo -f /etc/sudoers.d/<role>, исправьте строку, затем выполните visudo -c -f /etc/sudoers.d/<role>. Если основной sudoers уже повреждён, используйте сохранённую привилегированную сессию или консольный аварийный путь.

Как избежать

Используйте маленькие независимые файлы в `sudoers.d`, проверяйте каждый файл до теста и не смешивайте в одном изменении новые правила sudo с изменениями PAM.

5. Настройте PAM-политику локальных паролей

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

Не переносите PAM-конфигурацию между семействами ОС

Порядок PAM-модулей, управляющие флаги, включаемые файлы и доступные параметры зависят от семейства ОС, версии Linux-PAM и штатной конфигурации. В Debian/Ubuntu часто используются общие файлы common-auth, common-account, common-password и common-session; в RHEL-совместимых системах стек обычно строится вокруг system-auth и password-auth, нередко управляемых authselect. Перед изменением найдите фактически подключённые файлы и прочитайте pam_pwquality(8), pam_pwhistory(8), pam_faillock(8), pam_unix(8) и документацию поставщика ОС.

Политика паролей PAM относится прежде всего к локальной парольной аутентификации. Она не заменяет защиту SSH-ключей, MFA, сегментацию сети или безопасное хранение реквизитов служебных учётных записей. Она также может не действовать на LDAP, Active Directory, SSSD, Kerberos и другие внешние провайдеры: их правила определяются соответствующим сервером каталога и стеком интеграции.

Настройка PAM password quality и истории локальных паролей

Сначала подтвердите, что соответствующие модули подключены штатным PAM-профилем дистрибутива. Один только конфигурационный файл не включает модуль.

  1. 1
    Определите, какой PAM-стек реально используется
    Проверьте файлы, на которые ссылаются конфигурация нужной службы входа и стек passwd. На Debian/Ubuntu обычно начинают с /etc/pam.d/common-password; на RHEL-совместимых системах — с /etc/pam.d/system-auth и /etc/pam.d/password-auth, учитывая управление через authselect. Убедитесь, что в итоговом стеке действительно присутствуют pam_pwquality и, если нужна история, pam_pwhistory. Сохраните копию текущей конфигурации.
  2. 2
    Настройте качество пароля штатным модулем
    Если подключён pam_pwquality, задайте поддерживаемые параметры в /etc/security/pwquality.conf или в каталоге pwquality.conf.d, если он предусмотрен выпуском ОС. Например, строки minlen = 14 и minclass = 3 показывают синтаксис минимальной длины и числа требуемых классов символов; это не универсальные рекомендуемые значения. Выберите значения по политике организации и проверьте по pam_pwquality(8), как дополнительные параметры и зачёт классов влияют на фактическую длину.
  3. 3
    Включите историю паролей поддерживаемым способом
    Подтвердите, что pam_pwhistory подключён штатным профилем перед модулем, устанавливающим новый пароль. Если установленная версия поддерживает /etc/security/pwhistory.conf, строка remember = 5 показывает синтаксис хранения пяти прежних хешей; выберите число по своей политике. В других выпусках параметр remember задают в строке pam_pwhistory.so. Не переносите строку между дистрибутивами и не используйте устаревший пример с remember у другого модуля без подтверждения документацией выпуска.
  4. 4
    Проверьте смену пароля как обычный пользователь
    Войдите в отдельной консольной или SSH-сессии под тестовой локальной учётной записью и выполните passwd без имени пользователя. Попробуйте пароль, который должен быть отклонён, затем допустимый пароль. После успешной смены попробуйте вернуть предыдущий пароль: при работающей истории он должен быть отклонён. Не выполняйте основной тест через административное passwd <test-user>: смена от root может подчиняться другим правилам, в том числе параметру enforce_for_root, если он поддерживается.
  5. 5
    Проверьте журналы и откат
    При неожиданном отказе проверьте журнал аутентификации вашей ОС и сообщения PAM. Верните сохранённую конфигурацию через консоль или оставленную административную сессию, затем выясните, какой модуль и на каком этапе отклонил операцию.

Что задаёт pwquality, а что pwhistory

pam_pwquality обычно оценивает новый пароль в момент его установки. pam_pwhistory предотвращает повторное использование сохранённых прежних паролей. Ни один из этих модулей сам по себе не устанавливает срок действия пароля и не блокирует пользователя после ошибок входа.

6. Установите срок действия пароля и учётной записи

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

Показывает для локального пользователя дату последней смены, минимальный и максимальный возраст пароля, предупреждение, неактивный период и дату истечения учётной записи.
sudo chage -l <user>
Вывод:
Ожидаемый результат: список параметров в понятной форме. Значение `never` означает, что соответствующий срок не установлен.
Задаёт максимальный и минимальный возраст пароля, период предупреждения и неактивный период после истечения. Подставьте согласованные значения вместо переменных и сначала проверьте их на тестовой учётной записи.
sudo chage -M <days> -m <min-days> -W <warn-days> -I <inactive-days> <user>
Устанавливает дату истечения учётной записи подрядчика. С наступлением этой даты вход через механизмы, проверяющие состояние учётной записи, должен быть запрещён; заранее проверьте требуемое поведение на вашей ОС.
sudo chage -E <YYYY-MM-DD> <contractor>

Сроки не равны отзыву всех способов доступа

Истечение пароля влияет прежде всего на парольный вход и обработку состояния учётной записи PAM. Оно не обязательно отзывает действующие сеансы, SSH-ключи, API-токены, доступ через внешнюю систему идентификации или уже выданные привилегии. При отзыве сотрудника или подрядчика удалите его из ролевых групп, отключите нужные способы входа, проверьте активные сессии и отзовите связанные секреты по отдельной процедуре.

Блокировка пароля, истечение и отключение: не смешивайте понятия

Семантика действий для локальной учётной записи требует проверки на конкретном дистрибутиве и PAM-стеке

СостояниеТипичное средствоЧто меняетсяЧего это само по себе не гарантирует
Блокировка пароляpasswd -l <user> или usermod -L <user>Парольный хеш в локальной базе помечается как заблокированныйОтзыв SSH-ключей, внешней аутентификации, действующих сессий и sudo-членства
Разблокировка пароляpasswd -u <user> или usermod -U <user>Снимается блокировка локального пароляСнятие блокировки PAM faillock или отмена истечения учётной записи
Истечение пароляchage -M <days>; для принудительной смены — chage -d 0 <user>Пароль требует смены или перестаёт быть пригодным согласно политикеОтключение всей учётной записи для всех методов входа
Истечение учётной записиchage -E <date>Учётная запись становится просроченной для проверок account-этапаЗавершение существующих сеансов и отзыв независимых учётных данных
Неактивный периодchage -I <days>После истечения пароля и заданного периода учётная запись может стать неактивнойЕдиное поведение для всех внешних провайдеров идентичности

Команды passwd -l и usermod -L обычно блокируют именно пароль, а не обязательно учётную запись как идентичность. Перед отключением пользователя проверьте chage -l <user>, членство в группах, разрешённые SSH-ключи, активные процессы и сессии. Для просмотра сеансов могут помочь loginctl list-sessions, who и w, но доступность и полнота вывода зависят от типа входа и используемого менеджера сеансов.

7. Настройте блокировку после неудачных входов через pam_faillock

Блокировка после нескольких ошибок уменьшает эффект Brute force, но не является полной защитой от распределённых попыток, password spraying или атак через другие точки входа. Слишком низкий порог позволяет злоумышленнику намеренно заблокировать легитимного пользователя, а слишком долгий срок блокировки создаёт риск простоя. Параметры политики блокировки учётных записей выбирают по журналам, типу пользователей и процедуре разблокировки.

В поддерживаемых реализациях Linux-PAM модуль pam_faillock включают в стек аутентификации так, чтобы он: проверял существующую блокировку до аутентификации (preauth), фиксировал неудачу (authfail) и сбрасывал счётчик после успешного входа (authsucc). Точный порядок строк и управляющие флаги критичны: неверная последовательность может не учитывать ошибки, не сбрасывать счётчики или блокировать больше пользователей, чем задумано.

Debian/Ubuntu и RHEL-совместимые системы

В RHEL-совместимых системах наличие и подключение pam_faillock часто управляются штатной схемой PAM, а изменения в файлах, генерируемых authselect, могут быть перезаписаны или запрещены. В Debian/Ubuntu доступность модуля и место его включения зависят от выпуска и пакетов; не заменяйте работающий стек примером из RHEL. Сначала проверьте man pam_faillock, man faillock, установленный пакет и действующие PAM-файлы.
/etc/security/faillock.conf
# Пример только для реализаций, где этот файл поддерживается.
# Значения должны быть выбраны по локальной политике и тесту.
deny = <failed-attempts>
fail_interval = <seconds>
unlock_time = <seconds>
# even_deny_root требует отдельного решения и проверенного консольного восстановления.

Фрагмент показывает назначение параметров, а не готовую универсальную конфигурацию: deny задаёт порог ошибок, fail_interval — интервал их учёта, unlock_time — длительность блокировки. В некоторых конфигурациях параметры задаются не в этом файле, а в строках PAM. Не включайте блокировку root или служебных учётных записей без отдельного теста: это способно лишить систему аварийного доступа либо остановить автоматизацию.

Проверка и обслуживание блокировки учётной записи Linux

  1. 1
    Выделите исключения до включения политики
    Составьте список служебных, аварийных и технических учётных записей. Для каждой определите, выполняет ли она интерактивный парольный вход. Не создавайте широкое исключение для всех системных пользователей: исключение должно быть минимальным и обоснованным.
  2. 2
    Настройте штатный PAM-профиль дистрибутива
    На RHEL-совместимой системе сначала проверьте, управляется ли профиль через authselect; на Debian/Ubuntu — какие common-* файлы подключаются. Используйте профиль или полный пример поставщика ОС: вызов preauth должен проверять блокировку до проверки пароля, authfail — выполняться только в ветви неудачной аутентификации, а authsucc — только после успешной аутентификации для сброса счётчика. Не вставляйте эти три строки как простой последовательный фрагмент: корректное ветвление зависит от управляющих флагов и переходов всего PAM-стека.
  3. 3
    Проверьте счётчик тестовой учётной записи
    Создайте или выберите тестовую локальную запись, выполните контролируемое число неверных входов через тот сервис, который должен быть защищён, и в привилегированной сессии выполните faillock --user <test-user>. Ожидаемый результат — запись о неудачных попытках или блокировке, если конкретная реализация ведёт такой учёт.
  4. 4
    Проверьте успешный вход и сброс счётчика
    Войдите с корректным паролем до достижения порога. Затем повторно проверьте faillock --user <test-user>. Если счётчик не сбрасывается, не вводите политику в эксплуатацию: проверьте, попадает ли успешная аутентификация в ветвь authsucc, и сверьте управляющие флаги с документацией PAM-стека.
  5. 5
    Проверьте разблокировку
    При поддержке команды выполните sudo faillock --user <test-user> --reset, затем снова проверьте состояние. Зафиксируйте, кто имеет право выполнять разблокировку, как подтверждается личность пользователя и где фиксируется причина.
Показывает записи неудачных входов для пользователя и сбрасывает счётчик в реализациях, использующих утилиту `faillock`. Если команда или параметр недоступны, не заменяйте их случайной альтернативой: проверьте документацию установленного PAM-пакета.
sudo faillock --user <user>
sudo faillock --user <user> --reset
Вывод:
Ожидаемый результат первой команды — сведения о неудачных попытках или отсутствие записей; второй — очистка счётчика без изменения пароля и срока действия учётной записи.

Проблема

Пользователь не входит после верного пароля

Возможные причины

  • Сработал `pam_faillock` или другой механизм блокировки.
  • Истёк пароль, учётная запись или наступил неактивный период.
  • Пароль локально заблокирован.
  • Правило PAM, служба входа или внешний провайдер идентичности применяют дополнительное ограничение.

Решение

Из независимой привилегированной сессии проверьте faillock --user <user>, chage -l <user>, состояние пароля через passwd -S <user> и записи журнала аутентификации. Сопоставьте время отказа с журналом и конкретной службой. Сбрасывайте только подтверждённую блокировку (faillock --reset), а не меняйте одновременно все параметры: это сохранит причину инцидента понятной.

Как избежать

Тестируйте порог, время разблокировки и успешный сброс на отдельной записи. Подготовьте процедуру идентификации пользователя перед разблокировкой и мониторьте повторяющиеся отказы.

8. Отдельно решайте вопрос с root

У локальной root-учётной записи могут быть раздельно настроены пароль, срок действия, PAM-блокировка и разрешение конкретного способа входа. Блокировка пароля root не равна отключению root как UID 0 и не обязательно запрещает консольные или иные механизмы, доступные в данной конфигурации. Напротив, жёсткое отключение root без проверенного аварийного пути может усложнить recovery-режим и восстановление после сбоя.

Не отключайте root по универсальной инструкции

Последствия passwd -l root, usermod -L root, изменения срока действия root или включения even_deny_root в faillock различаются для консоли, rescue-режима, cloud-образов, BMC-консоли и конкретного PAM-стека. Перед изменением прочитайте документацию своего дистрибутива по аварийному восстановлению, проверьте доступ через консоль и убедитесь, что хотя бы одна отдельная административная учётная запись с работающим sudo уже протестирована.

Контроль результата после настройки

  1. 1
    Проверьте права каждого типа пользователя
    Для администратора, оператора, подрядчика и служебной учётной записи выполните id и sudo -l. Сверьте вывод с матрицей ролей: лишних групп, команд и целевых пользователей быть не должно.
  2. 2
    Проверьте отрицательные сценарии
    Попробуйте для тестовой учётной записи команду, которой нет в sudoers, запуск разрешённой команды с неподходящим аргументом и попытку смены пароля, не проходящего политику. Отказы должны быть ожидаемыми и диагностируемыми.
  3. 3
    Проверьте жизненный цикл локальной учётной записи
    Используйте chage -l <user> и passwd -S <user> для проверки срока и состояния пароля. Для подрядчика отдельно проверьте дату истечения учётной записи и удаление из всех привилегированных групп после завершения работ.
  4. 4
    Проверьте faillock и журналы
    Просмотрите faillock --user <user> для тестовой записи и найдите связанные события в журнале аутентификации. Путь к файлу журнала или способ просмотра через journald зависит от дистрибутива и службы; ориентируйтесь на документацию ОС.
  5. 5
    Зафиксируйте откат и владельцев
    Сохраните одобренные правила sudo, резервную копию исходной PAM-конфигурации, процедуру аварийного доступа, владельцев групп и даты пересмотра доступа. Проверяйте эти данные при смене подрядчика, изменении службы и обновлении дистрибутива.

Журналы sudo помогают строить аудиторский след, но доступность параметров log_input и log_output, запись ввода-вывода и место хранения событий зависят от версии sudo и настроек ОС. Не включайте журналирование ввода-вывода без оценки объёма и риска попадания секретов в записи. Настройка длительного хранения, защиты и корреляции журналов раскрыта в статье «Аудит безопасности Linux: auditd, журналы входов и контроль действий».

Термины в статье

Brute force — атака, при которой систематически проверяют варианты пароля, ключа или иного секрета через сервис либо по данным для автономной проверки.
PAM — модульная подсистема Unix-подобных ОС, через которую совместимые службы применяют правила аутентификации, проверки учётной записи, смены паролей и управления сеансами.
Sudoers — конфигурационная политика sudo, определяющая, какие пользователи и группы могут запускать команды от имени других учётных записей.
Аудиторский след — упорядоченный по времени набор записей о действиях и изменениях, позволяющий установить, кто, когда, над чем и с каким результатом выполнил операцию, а также откуда поступил запрос.
Блокировка учётной записи — временное или административное запрещение входа для аккаунта, обычно после заданного числа неудачных попыток аутентификации.
Журнал аутентификации — набор записей о попытках подтверждения личности, их результатах и данных, необходимых для расследования и контроля доступа.
Парольная аутентификация — способ проверки личности, при котором пользователь подтверждает владение секретным паролем, передавая его или производное от него значение.
Политика блокировки учётных записей — набор параметров аутентификации, задающий порог неверных входов, длительность блокировки и период сброса счётчика.
Политика паролей — набор обязательных правил создания, хранения, смены и проверки паролей учётных записей в информационной системе.
Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Принцип наименьших привилегий — правило предоставления пользователю, службе или процессу только тех прав и на тот срок, которые необходимы для выполнения конкретной задачи.
Разделение обязанностей — принцип контроля, при котором несовместимые функции критического процесса разделяют так, чтобы один субъект не мог единолично выполнить их все.
Срок действия пароля — заданный политикой период использования пароля, после которого система требует его смены или прекращает аутентификацию с прежним значением.
Учётная запись root — привилегированная локальная учётная запись Unix-подобочной ОС с идентификатором UID 0, обладающая практически неограниченными системными правами.

Вопросы по теме

Все вопросы и ответы

Можно ли настроить sudo без пароля?

Да, но только как исключение для строго ограниченного правила. NOPASSWD может быть обоснован, когда автоматизация не может ответить на запрос пароля или когда требуется одна заранее спроектированная привилегированная операция. При этом нужно документировать риск, владельца правила и назначение доступа.

Для обычной работы администратора запрос пароля sudo предпочтительнее: он может уменьшить последствия оставленной разблокированной сессии. Однако это не полноценная защита, поскольку эффект зависит от настроек кэша отметки времени sudo. Запрос пароля не заменяет блокировку пользовательской сессии, MFA, сетевые ограничения, защиту SSH-ключей и управление секретами.

Нельзя выдавать NOPASSWD: ALL. Такое правило делает любую скомпрометированную пользовательскую сессию немедленным источником привилегированного доступа. Вместо этого разрешайте конкретную команду с абсолютным путём и, при необходимости, строго определёнными аргументами.

Почему sudo возвращает permission denied, хотя пользователь добавлен в группу?

Сначала убедитесь, что пользователь действительно состоит в нужной группе: проверьте id <user> и getent group <group>. После изменения групп пользователь может работать в старой сессии, поэтому нужно выйти и открыть новую сессию, а не проверять доступ в прежнем подключении.

От имени пользователя запустите sudo -l. Эта команда показывает итоговые разрешения, целевых пользователей и ограничения, которые реально применяются. Если ожидаемого правила нет, из привилегированной сессии проверьте синтаксис через sudo visudo -c, а для отдельного файла — sudo visudo -c -f /etc/sudoers.d/<role>.

Также убедитесь, что каталог sudoers.d подключён на данном хосте, имя файла допустимо для реализации sudo, а сам файл принадлежит root и недоступен для записи группе и другим пользователям. Сверьте абсолютный путь команды через command -v <command>, фактические аргументы, целевого пользователя, теги правила и параметры Defaults с документацией установленной версии sudo.

Что делать при ошибке sudoers syntax error?

При ошибке синтаксиса не редактируйте sudoers обычным редактором из непривилегированной сессии и не закрывайте действующую привилегированную сессию. Для отдельного правила используйте sudo visudo -f /etc/sudoers.d/<role>: этот инструмент проверяет синтаксис при сохранении и помогает избежать части ошибок параллельного редактирования.

Проверьте сообщение visudo: оно обычно указывает номер строки. Типовые причины — пропущенные двоеточие, обратный слеш продолжения, целевой пользователь или абсолютный путь к команде; также ошибкой бывает неверная запись аргументов, алиаса или комментария. После исправления выполните sudo visudo -c -f /etc/sudoers.d/<role>. Для проверки всего набора правил используйте sudo visudo -c.

Если повреждён основной sudoers и доступ через sudo утрачен, восстанавливайте конфигурацию из уже открытой привилегированной сессии либо через подготовленный независимый канал: консоль гипервизора, BMC, физическую консоль или документированную аварийную учётную запись.

Можно ли дать sudo на `systemctl *` для оператора?

Нет, такое правило обычно слишком широкое. Запись вида /usr/bin/systemctl * может позволить запускать или изменять другие службы, а не только согласованный сервис. Разрешайте конкретную команду с абсолютным путём, точным именем службы и нужными аргументами либо используйте отдельный root-owned скрипт с фиксированной логикой.

Действует ли локальная PAM-политика на пользователей LDAP или Active Directory?

Не всегда. Политика локальных паролей PAM прежде всего относится к локальной парольной аутентификации. Для LDAP, Active Directory, SSSD и Kerberos правила паролей, членство в группах и сроки действия могут задаваться каталогом или стеком интеграции. Проверьте источник учётной записи через getent passwd <user>.

Как не потерять доступ при изменении sudo или PAM?

Оставьте открытой текущую привилегированную сессию и заранее проверьте независимый путь восстановления: консоль гипервизора, BMC, физическую консоль или аварийную учётную запись. Изменения тестируйте во второй сессии проверяемого пользователя. Открытое SSH-подключение не считается аварийным каналом, так как PAM или учётная запись могут его затронуть.