Работа с пользователями Linux — это управление идентичностью и полномочиями, а не только выполнение useradd. Нужно понимать, где хранится учётная запись, какие группы дают доступ к данным, как проверяется SSH и что останется после блокировки сотрудника.
Ниже — практический сценарий для локальных пользователей CentOS Stream 9/10 и совместимых систем семейства RHEL. Команды выполняет действующий администратор с sudo или root через доверенную консоль. Для учётных записей из AD/LDAP изменения делают в соответствующем каталоге, а не локальным usermod.
1. Почему инструкция для CentOS 6 требует обновления
CentOS Linux и CentOS Stream — разные ветви. CentOS Linux 7 завершил жизненный цикл 30 июня 2024 года; использовать инструкции для CentOS 6 как основу нового защищённого сервера нельзя. Актуальные даты опубликованы на сайте проекта CentOS. Сначала определите установленную систему и доступные инструменты:
cat /etc/os-release
rpm -q shadow-utils sudo openssh-server
getent passwd adminops
getent group wheelgetent обращается через NSS, поэтому способен показать запись из внешнего каталога, а не только /etc/passwd. Если имя уже существует, не создавайте одноимённого локального пользователя: это усложнит сопоставление прав. Выберите согласованное имя и зафиксируйте источник учётной записи.
Не закрывайте рабочую административную сессию, пока новый вход и sudo не проверены отдельно. Консоль виртуализации или физический доступ обеспечивают возврат при ошибке SSH-политики.
2. Как создать обычного пользователя с домашним каталогом
Для нового локального администратора в нашем примере используется имя adminops:
sudo useradd --create-home --shell /bin/bash --comment 'Local operations administrator' adminops
sudo passwd adminops
getent passwd adminops
id adminops
sudo stat -c '%U:%G %a %n' /home/adminopsПароль вводится интерактивно; он не должен попадать в командную строку, историю, статью или файл заявки. Проверьте фактический домашний каталог из getent, особенно если организация использует другой шаблон. Не копируйте чужой домашний каталог целиком: там могут быть ключи, токены и файлы с неправильным владельцем.
Запись в /etc/passwd содержит UID, GID, домашний каталог и shell, но не открытый пароль. Локальная проверка пароля использует защищённые данные /etc/shadow и PAM. Чтение shadow для обычного отчёта о пользователях не требуется.
3. Как предоставить sudo и не испортить список групп
Группа называется wheel, а не wheels. Для пользователя, которому действительно нужны полные административные права:
sudo usermod --append --groups wheel adminops
id adminops
sudo visudo -c
sudo -l -U adminops--append сохраняет прочие дополнительные группы. Вызов usermod -G wheel без добавления заменит их список и может лишить пользователя доступа к другим ресурсам. Политика wheel должна разрешать sudo в действующей конфигурации; проверка членства сама по себе не доказывает наличие прав.
Новый пользователь входит в новой сессии, затем выполняет sudo -v и sudo id -u: ожидаемый числовой результат последней команды — 0. Политика и способ проверки описаны в руководстве Red Hat по sudo.
Редактируйте sudoers только через visudo; после изменения проверяйте синтаксис. Ошибка в drop-in файле также способна нарушить повышение привилегий.
4. Как выдать ограниченные права вместо полного wheel
Если сотруднику требуется только посмотреть состояние определённого сервиса, полный root избыточен. Сначала выясните реальные пути программ командой command -v systemctl, затем откройте отдельный файл:
sudo visudo -f /etc/sudoers.d/app-observerПример правила для существующего сервиса app.service:
adminops ALL=(root) /usr/bin/systemctl --no-pager status app.serviceЭтот пример не подходит пользователю, уже имеющему полные права через wheel: широкое разрешение останется действовать. Для проверки ограниченной роли используйте отдельную учётную запись без других привилегий. Явное --no-pager уменьшает риск появления интерактивного просмотрщика с дополнительными действиями.
Убедитесь, что пользователь не может менять сам сервис, исполняемый им файл или разрешённую команду. Правило с рестартом службы может фактически дать выполнение произвольного кода, если разрешённому пользователю доступны на запись unit-файл или приложение. Ограничение проверяют по всей цепочке, а не по красивой строке sudoers.
5. Как подготовить вход по SSH-ключу
На административной рабочей станции создайте индивидуальную пару ключей:
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/adminops_server
ssh-copy-id -i ~/.ssh/adminops_server.pub adminops@server.example.netПервый вход допустим только после проверки отпечатка ключа сервера через независимый доверенный канал. Пользовательский ключ и host key — разные сущности. Приватный пользовательский ключ остаётся на рабочей станции и защищается парольной фразой; на сервер передаётся публичная часть. В средах с ограниченными криптографическими политиками выбранный алгоритм предварительно проверяют на совместимость.
ssh-copy-id требует действующего способа авторизации. Если его нет, администратор добавляет публичный ключ через консоль в authorized_keys нужного пользователя, сохраняя существующие записи. После проверьте права: .ssh обычно 700, authorized_keys 600, владелец — пользователь. На SELinux-системе проверьте метки и при необходимости восстановите штатный контекст именно этой области.
6. Как проверить SSH-политику до перезагрузки службы
Сначала выполните вход по ключу из второй сессии. После этого можно планировать ограничение других способов входа. Эффективная настройка зависит от Include и Match, поэтому поиска одной строки в sshd_config недостаточно:
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=adminops,host=workstation.example.net,addr=192.0.2.25Адрес 192.0.2.25 иллюстративный: подставьте настоящий адрес клиента и релевантные значения Match. В выводе проверьте pubkeyauthentication, passwordauthentication, kbdinteractiveauthentication, permitrootlogin и ограничения Allow/Deny. Настройки из OpenSSH следует сверять с установленной версией.
Отключение PasswordAuthentication не всегда отключает пароль через keyboard-interactive/PAM. При этом keyboard-interactive может использоваться для MFA, поэтому механическое выключение способно сломать нужную схему входа. Сначала согласуйте политику, затем проверьте синтаксис и выполните sudo systemctl reload sshd. Старую сессию закрывают только после повторной проверки нового входа.
7. Как диагностировать отказ доступа
Разделите отказ на этапы: соединение, проверка ключа сервера, аутентификация, открытие сессии и повышение привилегий. Клиентский подробный журнал помогает увидеть, какой ключ предлагается:
ssh -v -i ~/.ssh/adminops_server adminops@server.example.net
sudo journalctl -u sshd --since '15 minutes ago' --no-pager
sudo passwd -S adminops
sudo chage -l adminopsПароль может быть заблокирован или просрочен; запись может иметь срок действия; shell может запрещать вход. Внешний каталог и PAM дают собственные причины отказа. Не включайте root-login и не меняйте права на 777, чтобы «проверить, заработает ли».
Подробные журналы способны содержать имена, адреса и пути; перед передачей их приводят к минимально необходимому виду. Приватные ключи и содержимое shadow не нужны для обычной диагностики.
8. Что означает блокировка пользователя
Блокировка пароля и отзыв всех способов доступа — не одно действие. passwd -l блокирует пароль, но не является универсальным запретом ключевого SSH-входа. Для завершённого отзыва нужны политика учётной записи, ключи, sudo, внешние роли и уже работающие сессии.
sudo usermod --expiredate 1 adminops
sudo passwd --lock adminops
sudo gpasswd --delete adminops wheel
sudo loginctl user-status adminops
sudo pgrep -a -u adminopsСрок 1 — прошедшая дата относительно начала Unix-эпохи; это пример локального административного ограничения. Поведение входа подтверждают для используемого PAM/SSH. Выполняйте блок только при отзыве выбранной учётной записи, а не текущего единственного администратора. Удалите конкретный публичный ключ из разрешённых ключей, проверьте отдельные sudoers-правила и учётные данные интеграций.
Активные процессы могут продолжить работу. Их завершение согласуют с владельцем сервиса: бездумное убийство процессов способно остановить задачу или приложение. Отключение входа не отменяет уже украденный секрет другой системы.
9. Почему userdel не должен быть первым шагом
UID владеет файлами не только в домашнем каталоге. Перед удалением пользователя проверьте процессы, задания cron, службы, ACL и данные на подключённых файловых системах. Сохраните необходимые материалы и назначьте нового владельца.
id adminops
sudo crontab -u adminops -l
sudo find /srv -xdev -uid 1001 -printUID 1001 в примере нужно заменить фактическим значением из id; /srv — лишь одна согласованная область поиска, не полный аудит всех дисков. -xdev исключает переход на другие файловые системы. Не запускайте массовую смену владельца по совпавшему числу без проверки назначения файлов.
userdel -r может удалить домашний каталог и другие предусмотренные реализацией данные; это не инструмент безрисковой уборки. После удаления файлы с прежним UID способны достаться будущему пользователю, которому будет назначено то же число. Поэтому учёт ресурсов и порядок повторного использования UID имеют значение.
10. Как принять результат и вернуть доступ при ошибке
После выдачи прав нужны положительный и отрицательный тесты: выбранный пользователь входит, выполняет разрешённое действие и не получает полномочия другой роли. После отзыва — наоборот: новый вход и sudo не работают, старые сеансы обработаны, а сервисы продолжают выполнять свои задачи.
Зафиксируйте владельца учётной записи, источник идентичности, разрешённые группы, ключи, срок пересмотра и результат тестов. Доступ восстанавливают по сохранённой политике, а не через случайную выдачу полного wheel. Для отмены ошибочного истечения локальной записи применяется usermod --expiredate '' adminops; затем отдельно восстанавливают только согласованные методы входа и группы.
Для централизованных Linux-узлов лучше использовать каталог и управляемые политики, а локальную аварийную учётную запись держать под отдельным контролем. Настройка членства сервера в AD разобрана в инструкции по Samba и Winbind.
Параметры создания и отзыва сверяйте с руководствами useradd и usermod установленной версии shadow-utils.