Управление пользователями Linux: учётные записи, группы, SSH и sudo

Управление пользователем не заканчивается командой adduser. Администратор должен выдать доступ к конкретному ресурсу, проверить его от имени пользователя и уметь отозвать пароль, ключи и действующие сеансы. Ниже — практическая инструкция для Debian/Ubuntu с локальными учётными записями; для AD/LDAP отдельно учитывается источник идентичности.

1. Определите источник учётной записи

Как Linux принимает решение о доступе

Имя пользователя преобразуется через NSS в числовой UID; локальные записи находятся в passwd/group, парольные данные — в защищённом shadow. PAM участвует в аутентификации и проверке аккаунта, но конкретный сервис может иметь собственный маршрут. Ядро принимает решение о доступе к файлу по текущим UID/GID, supplementary groups, mode и ACL. Поэтому наличие имени в /etc/passwd не доказывает вход, а отключение пароля не отзывает все ключи и процессы.

В руководстве создаётся локальный labops на Debian/Ubuntu и ресурс /srv/avg-project. Нужны sudo, рабочая административная сессия и отдельный стенд. Если идентичности приходят из AD/LDAP/SSSD, не создавайте локальный дубликат с тем же именем: он может затенить каталог и нарушить ожидаемые UID/права. Все изменения групп и SSH проверяют в новом сеансе самого пользователя.

getent passwd labops
getent group avg-project
id labops
getent passwd 1001

getent использует настроенный NSS, а чтение одного passwd — только локальный файл. 1001 в последней строке учебный UID; не резервируйте его до проверки диапазонов. Ошибка no such user до создания ожидаема. Домашний каталог, shell и источник записи фиксируются в реестре доступа.

Сначала запросите пользователя через NSS, а не только grep /etc/passwd. getent учитывает подключённые источники, например SSSD. Локальный файл не показывает весь корпоративный каталог.

getent passwd alice
id alice
getent group project
getent passwd | head

Последняя команда выводит только начало доступного списка и не является полной инвентаризацией LDAP: перечисление в NSS может быть отключено. Для конкретного пользователя важнее прямой запрос имени. UID/GID — числовая идентичность прав файлов; переименование пользователя само по себе не изменяет принадлежность его файлов.

Если alice приходит из AD, не создавайте локальную одноимённую запись, чтобы «исправить вход». Это создаёт конфликт идентичности и зависит от порядка источников nsswitch.conf. Изменения корпоративных групп выполняют в их каталоге, локальные — локальными инструментами.

2. Создайте пользователя штатной утилитой

В примере labops — новая лабораторная учётная запись. До создания подтвердите её отсутствие через getent. В Debian/Ubuntu adduser обычно создаёт домашний каталог и предлагает интерактивный ввод пароля; useradd — инструмент более низкого уровня с другими значениями по умолчанию.

getent passwd labops
sudo adduser labops
id labops
getent passwd labops
sudo passwd -S labops
sudo chage -l labops

Не передавайте пароль в командной строке. Проверяйте home, shell и срок действия. Справка adduser описывает поведение конкретной версии. UID от 1000 характерен для многих установок, но не универсален; реальные диапазоны читают в конфигурации системы и каталога.

Для сервисной учётной записи выбирают системный режим и shell nologin, например sudo adduser --system --group --home /var/lib/avg-app --no-create-home avg-app. Такой пользователь не предназначен для входа администратора. Каталог приложения создаётся отдельно с нужными владельцем и правами; сервис не получает sudo автоматически.

Пошаговое создание и проверка локального аккаунта

На Debian sudo adduser labops запускает интерактивную процедуру: создаёт локальную запись, группу и home, копирует skeleton, запрашивает пароль и необязательные поля. Пароль вводят интерактивно, не помещают в параметр shell. После завершения проверьте:

getent passwd labops
id labops
sudo passwd -S labops
ls -ld /home/labops
sudo -u labops sh -c 'id; printf "%s\n" "$HOME"; pwd'

В passwd-строке поля разделены двоеточием: name, marker пароля, UID, primary GID, описание, home, shell. Значение x не является паролем. passwd -S показывает состояние, а не секрет. Вызов sudo -u проверяет выполнение под UID, но не полноценную SSH/PAM-аутентификацию: её подтверждают отдельно.

Для сервисного avg-app выберите system/nologin и отдельный каталог данных. Такой аккаунт может владеть файлами и запускаться systemd, хотя интерактивный вход запрещён. Shell nologin не ограничивает права процесса, запущенного root через service; изоляция сервиса и минимальные файловые права остаются необходимыми.

3. Добавьте группу без потери прежних членств

Пусть пользователь должен работать только с общим проектом. Создайте отдельную локальную группу, если такой ещё нет, и добавьте членство с -aG:

getent group avg-project
sudo groupadd avg-project
sudo usermod -aG avg-project labops
id labops
getent group avg-project

Команду groupadd пропускают, если группа уже существует. usermod -G без -a заменяет список дополнительных групп, поэтому может незаметно отозвать нужный доступ. Справка usermod объясняет этот режим.

В уже открытой сессии supplementary groups могут оставаться прежними. Проверьте id в новом входе пользователя, а не только id labops из административной сессии. Не добавляйте человека в docker ради доступа к одному контейнеру: обычная группа управления Docker часто даёт возможности, эквивалентные root. То же внимание требуется к группам дисков и привилегированным сокетам.

Primary group, supplementary groups и обновление сеанса

Primary GID записан в passwd, дополнительные членства — в group/NSS. usermod -aG добавляет дополнительную группу; usermod -G задаёт новый полный список. Для удаления одного членства gpasswd -d labops avg-project понятнее, чем пересобирать все группы вручную.

id labops
getent group avg-project
sudo usermod -aG avg-project labops
sudo -iu labops id

Последний вызов создаёт новый контекст, но реальный SSH-вход всё равно проверяют отдельно. Уже работающий процесс хранит свой список групп до нового запуска. newgrp меняет текущий group-context через новую оболочку и не является универсальным обновлением всех открытых сессий.

Не выдавайте docker, disk или доступ к привилегированному сокету как «обычную файловую группу». Участник такой группы может получить существенно больше прав, чем заявлено задачей. Если пользователю нужен только журнал сервиса, подберите read-only доступ к конкретному ресурсу вместо широкого административного членства.

4. Настройте общий каталог и подтвердите результат

Пример создаёт новый лабораторный ресурс /srv/avg-project; перед выполнением убедитесь, что путь не занят. setgid на каталоге задаёт наследование группы для новых объектов. Он не делает существующие вложенные файлы автоматически доступными всем.

sudo install -d -o root -g avg-project -m 2770 /srv/avg-project
ls -ld /srv/avg-project
sudo -u labops sh -c 'umask 007; touch /srv/avg-project/positive-test'
ls -l /srv/avg-project/positive-test
sudo -u nobody test -w /srv/avg-project

Последняя команда должна завершиться ненулевым кодом. Не превращайте его в «ошибку, которую нужно исправить»: это ожидаемый негативный тест. test проверяет права, touch — фактическую операцию. Для общего ресурса также согласуют umask, право удаления и требования приложения.

При необходимости default ACL используйте acl-пакет и изучайте маску эффективных прав:

getfacl -p /srv/avg-project
sudo setfacl -m d:u::rwx,d:g::rwx,d:o::--- /srv/avg-project
getfacl -p /srv/avg-project

ACL не отменяет необходимость execute на каждом родительском каталоге. Ошибка доступа при правильном ACL конечной папки может находиться выше по пути; для проверки используйте namei -l.

Почему setgid не решает все права совместной работы

2770 означает rwx для владельца/группы, отсутствие доступа others и setgid для наследования группы. Новые файлы при umask 007 обычно получают 660, каталоги — 770; приложение может задавать более узкий mode. Право удаления определяется writable/execute каталога, поэтому участник проекта способен удалить чужой файл даже при отсутствии записи в сам файл. Sticky bit нужен для иной модели общего каталога, где ограничивают удаление чужих объектов.

namei -l /srv/avg-project
sudo apt-get install acl
getfacl -p /srv/avg-project
sudo -u labops sh -c 'umask 007; mkdir /srv/avg-project/dir-test; touch /srv/avg-project/dir-test/file-test'
ls -ld /srv/avg-project/dir-test
ls -l /srv/avg-project/dir-test/file-test

ACL mask ограничивает эффективные права именованных пользователей/групп: строка rwx может давать только r-x после применения mask. getfacl показывает effective комментарий. Default ACL наследуется новым объектом, не исправляет автоматически существующий tree. Сохраняйте getfacl -R -p только нужного ресурса в закрытый backup до массовой правки; восстановление setfacl --restore применяется к проверенному набору путей.

5. Настройте SSH по публичному ключу

Ключ создают на управляемой станции пользователя. На сервер передают только .pub; приватный ключ не хранится в общей папке и не пересылается администратору. Для нового пользователя проверьте его фактический home через getent.

sudo install -d -o labops -g labops -m 700 /home/labops/.ssh
sudo install -o labops -g labops -m 600 ./labops.pub /home/labops/.ssh/authorized_keys
sudo sshd -t

Этот install подходит только новой учётной записи без существующего authorized_keys. Для действующего пользователя нельзя перезаписывать файл и потерять остальные ключи; выполняйте управляемое добавление с backup и проверкой fingerprint. Shell/home в примере соответствуют adduser labops; для другого пользователя пути берут из фактической записи.

Проверьте вход в отдельном сеансе, пользователя и ресурс. Пока новый доступ не подтверждён, сохраняйте административную сессию. Отключение PasswordAuthentication — изменение политики SSH всего затронутого scope; его выполняют после проверки всех разрешённых путей, а не ради создания одной записи.

Создайте ключ на клиенте и подтвердите новый вход

На управляемом Linux/macOS-клиенте:

ssh-keygen -t ed25519 -f "$HOME/.ssh/labops_ed25519" -C 'labops managed workstation'
ssh-keygen -lf "$HOME/.ssh/labops_ed25519.pub"

Passphrase выбирают по корпоративной политике; приватный файл остаётся у пользователя. На сервер передаётся только .pub. Перед установкой ключа сверяют fingerprint и фактический home из getent. Для уже существующего authorized_keys добавляйте новую строку через управляемую процедуру с backup, не перезаписывайте все ранее утверждённые ключи.

После установки из исходных команд раздела выполните с клиента:

ssh -i "$HOME/.ssh/labops_ed25519" -o IdentitiesOnly=yes labops@server-lab.example

server-lab.example — заменяемое имя стенда. Проверка host key выполняется через доверенный канал; первый неподтверждённый отпечаток нельзя объявить безопасным. В новом сеансе выполните id, проверьте project-файл и sudo -l. Ошибка publickey может быть неправильным пользователем, ключом, владельцем home, StrictModes, AuthorizedKeysFile или Match-политикой.

На сервере диагностируйте sudo sshd -t, sudo sshd -T и journalctl -u ssh --since '-10 minutes'. Для Match-блоков нужна проверка эффективной конфигурации с контекстом -C, соответствующим user/host/addr. Сам успешный sshd -t подтверждает синтаксис, а не разрешение конкретного пользователя.

6. Выдайте ограниченный sudo

Если labops должен только просматривать состояние и перезапускать конкретный лабораторный nginx, используйте отдельный файл sudoers и точные аргументы. Не выдавайте ALL ради одного действия. Исполняемый путь уточняется через command -v systemctl.

sudo visudo -f /etc/sudoers.d/avg-labops

labops ALL=(root) /usr/bin/systemctl --no-pager status nginx.service, /usr/bin/systemctl restart nginx.service

sudo chmod 440 /etc/sudoers.d/avg-labops
sudo visudo -cf /etc/sudoers
sudo -l -U labops

Используется --no-pager, чтобы не предоставить привилегированный интерактивный pager с возможностью shell escape. Пароль по умолчанию требуется; NOPASSWD не добавляется. Главное условие: пользователь не может изменять unit, drop-ins, запускаемые root-скрипты и конфигурации, которые позволяют исполнение кода. Иначе ограниченная команда restart может стать путём к повышению прав.

Документация sudoers описывает сопоставление команд и аргументов. Не делегируйте editor, shell, произвольный systemctl edit или утилиту с записью root-файлов под видом «ограниченного» доступа.

Почему «restart одного сервиса» может дать root

Sudoers сопоставляет путь и аргументы, но безопасная делегация зависит от объектов, которые команда использует. Если labops может изменить nginx.service, EnvironmentFile, root-скрипт ExecStart либо привилегированную конфигурацию, разрешённый restart исполнит изменённый код. До выдачи доступа проверьте unit и владельцев:

systemctl cat nginx.service
systemctl show nginx.service -p FragmentPath -p DropInPaths -p ExecStart
namei -l /etc/nginx/nginx.conf
sudo -l -U labops

Путь systemctl уточняют через command -v. Ограниченный status используют с --no-pager, чтобы не дать root-пейджер с shell escape. В sudoers не нужны wildcard *, произвольный editor или systemctl edit. Если задача только read-only, даже restart из приведённого учебного правила следует исключить.

Файл в sudoers.d принадлежит root и имеет 440. Проверка visudo -cf /etc/sudoers проверяет общий результат include, а не один фрагмент. Сохраните независимую root/sudo-сессию до проверки нового входа. NOPASSWD выбирается отдельно по необходимости автоматизации, а не добавляется во все инструкции.

7. Проверьте разрешённое и запрещённое действие

От имени labops выполните только просмотр статуса. Реальный restart проверяют на лабораторном сервисе в согласованное окно. Наличие правила sudo -l не доказывает, что нужная команда успешно работает.

sudo /usr/bin/systemctl --no-pager status nginx.service
sudo -l

Проверьте отсутствие разрешения на произвольный shell и управление другим unit. Для негативного теста достаточно анализа sudo -l либо проверки sudo -l /usr/bin/systemctl restart ssh.service — не запускайте неразрешённую команду в надежде, что она будет отклонена.

Права на файлы и sudo оценивают отдельно. Пользователь может не иметь sudo, но управлять привилегированным сокетом, cron-файлом или скриптом, запускаемым root. Поэтому аудит доступа включает владельцев unit/config/script и группы, а не только список sudoers.

Приёмочный тест доступа

Положительный файл: пользователь создаёт объект в /srv/avg-project. Негативный: nobody не может писать туда, labops не получает произвольный root shell и не управляет ssh.service. Для sudo негативный тест выполняйте запросом разрешения sudo -l /usr/bin/systemctl restart ssh.service, а не фактическим перезапуском системного SSH.

Проверяйте новое SSH-соединение, а не только sudo -u. Локальная password/PAM-политика может различать login и ssh; ключ может приниматься, даже когда пароль заблокирован. Список id из root-сессии показывает членство базы, а id в пользовательском процессе — эффективное членство текущего контекста.

Запишите ожидаемые и фактические exit codes. test -w с кодом 1 у запрещённого пользователя — успешная отрицательная проверка. При ошибке ищите уровень: путь и parent execute, group/ACL mask, источник NSS, auth SSH либо sudoers. chmod 777 скрывает проблему и расширяет доступ всем пользователям.

8. Управляйте сроками и блокировкой пароля

chage задаёт ограничения пароля и срок учётной записи, но его политика должна соответствовать корпоративным правилам. Не вводите бессмысленную частую ротацию без учёта MFA, компрометации и специфики сервисных учётных записей. Для локального пользователя состояние читают через passwd -S и chage -l.

sudo passwd -l labops
sudo passwd -S labops
sudo chage -l labops

passwd -l блокирует пароль, но не гарантирует блокирование SSH-ключей и других методов аутентификации. Для полного offboarding нужна отдельная процедура. Разблокировка passwd -u допустима лишь после проверки исходного состояния и необходимости; она не восстанавливает автоматически удалённые ключи или членства.

Не блокируйте системного пользователя сервиса «как сотрудника»: это может не остановить процесс, но сломать необходимые операции. Прекращение сервиса выполняют его штатным управлением, отзыв доступа человека — управлением идентичностью.

Срок пароля, срок аккаунта и service identity

sudo passwd -S labops
sudo chage -l labops
sudo chage -M 90 -W 14 labops
sudo chage -E 2026-12-31 labops

90/14/дата — пример выбранной политики, не универсальное требование. -M задаёт срок пароля, -W предупреждение, -E срок самого аккаунта. Перед изменением сохраните прежние значения; для сервисной записи частая expiry без процедуры ротации может остановить интеграцию. Истечение локального пароля не обязательно отзывает SSH-ключ во всех маршрутах, поэтому проверяют фактический сервис.

Обязательная ротация без причины не заменяет длинный уникальный пароль, MFA и своевременный отзыв после компрометации. Для ключей нужен реестр, владелец, срок и процедура замены. Для AD/LDAP политика задаётся каталогом: chage локального пользователя не управляет доменной учётной записью.

9. Отзовите доступ и действующие сеансы

Перед offboarding сохраните числовой UID, членства и назначение пользователя. Отзовите SSH-ключи, доступы в каталоге, sudoers и ресурсные группы; блокировка только локального пароля недостаточна.

id labops
loginctl user-status labops
sudo usermod --expiredate 1 labops
sudo gpasswd -d labops avg-project

Expiredate задаёт истёкший срок аккаунта; эффективность входа зависит от используемого PAM/authentication-пути и должна быть проверена. Уже запущенные процессы автоматически не исчезают. sudo loginctl terminate-user labops завершает сессии и процессы пользователя и может прервать задания; выполняйте её только после проверки последствий.

На конкретных ресурсах найдите оставшиеся файлы по сохранённому UID: sudo find /srv/avg-project -xdev -uid 1001 -ls, заменив 1001 реальным значением. Не используйте userdel -r как первый шаг: домашний каталог может содержать нужные рабочие данные. Переиспользование UID без анализа старых файлов создаёт риск выдачи их новому пользователю.

Offboarding: пароль — только один из путей

Сначала зафиксируйте UID и ресурсы, затем отзовите ключи/сертификаты, группу проекта, sudo и каталожную запись. passwd -l блокирует парольную аутентификацию, но не гарантирует блокировку key login. usermod --expiredate 1 ставит истёкший срок, эффективность которого подтверждают через используемый PAM/сервис. Существующие процессы продолжают работать до завершения.

id labops
ps -u labops -o pid,ppid,lstart,args
loginctl user-status labops
sudo find /srv/avg-project -xdev -user labops -ls

Командные аргументы могут содержать чувствительные данные: не публикуйте полный ps. Перед loginctl terminate-user проверьте задания/сессии, иначе оборвёте выполняемую работу. Отдельно проверьте user services, cron, API-ключи приложения, VPN, Git/CI и share-права: отзыв локального пользователя не равен отзыву всей корпоративной идентичности.

userdel -r не выполняют первым шагом. Сначала архивируют нужные данные, находят файлы по сохранённому числовому UID и запрещают его преждевременное повторное использование. Файл с UID старого сотрудника может стать собственностью нового после создания такого же UID.

10. Возврат и итоговый реестр

Для возврата восстанавливают именно изменённое членство, файл sudoers, ключи и ACL из сохранённого состояния. Не добавляют обратно группы «по памяти». Изменения sudoers всегда проверяют visudo; SSH — sshd -t и отдельным тестовым входом.

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

Документируйте минимальный реестр и возврат

Реестр содержит источник идентичности, UID/GID, home/shell, группы, назначение ресурса, fingerprint публичного ключа, утверждённые sudo-команды, владельца доступа, сроки и проверенные пути входа. Паролей и private keys в акте нет. Для возврата берут сохранённые группы/ACL/фрагменты, не добавляют человеку все права «для надёжности».

После любого существенного изменения повторяют новый вход, id, положительный/отрицательный файловый тест и sudo policy. После отзыва — отрицательный вход по каждому прежнему каналу и проверка отсутствия действующих сеансов. Качественное управление учётными записями измеряется работающим минимальным доступом и воспроизводимым отзывом, а не числом выполненных usermod.