Управление пользователями и sudo в Linux

Зачем вообще разделять root и обычных пользователей

Учётная запись root в Linux не подчиняется обычной модели прав доступа: она может читать, изменять и удалять любой файл в системе, останавливать любой процесс и менять настройки ядра без каких-либо ограничений. Это делает root одновременно необходимым (без него невозможно администрировать систему) и опасным — любая опечатка в команде, выполненной от имени root, способна необратимо повредить систему, тогда как та же опечатка от имени обычного пользователя в лучшем случае завершится ошибкой доступа.

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

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

В этой статье разобраны практические шаги: создание, изменение и удаление пользователей, работа с группами, безопасное редактирование /etc/sudoers через visudo, гранулярная выдача прав на отдельные команды, отличие sudo от su, отключение root-логина по SSH и способы проверить, кто и что делал через sudo на сервере.

Создание, изменение и удаление пользователей

Базовая команда для создания нового пользователя в Linux — useradd. Без дополнительных флагов она создаёт учётную запись с минимальными настройками, часто без домашней директории и без назначенной оболочки по умолчанию, поэтому на практике почти всегда используют флаги, задающие эти параметры явно.

useradd -m -s /bin/bash -c "Иван Петров, backend" ipetrov
passwd ipetrov

Флаг -m создаёт домашнюю директорию (обычно /home/ipetrov) и копирует в неё содержимое /etc/skel — набора файлов-заготовок вроде .bashrc и .profile, которые получает каждый новый пользователь. Флаг -s задаёт оболочку входа: без него на некоторых дистрибутивах пользователь получает /bin/sh или вовсе оболочку, не позволяющую интерактивный вход, что неожиданно ломает попытку зайти по SSH под этим пользователем. Команда passwd после useradd устанавливает пароль интерактивно — без него учётная запись создаётся, но не может пройти парольную аутентификацию, что иногда специально используют для сервисных пользователей, входящих только по SSH-ключу.

Для изменения уже существующей учётной записи используется usermod — она позволяет менять домашнюю директорию (-d), оболочку (-s), список групп (-aG) и блокировать учётную запись без удаления (-L, а обратно — -U), что полезно, когда сотрудник временно отстранён от работы с сервером, но его файлы и права нужно сохранить на будущее.

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

Группы пользователей: первичная и дополнительные

У каждого пользователя в Linux есть ровно одна первичная группа (обычно создаётся автоматически с тем же именем, что и сам пользователь, при использовании useradd без явного указания) и произвольное число дополнительных групп, через которые чаще всего и выдаются права на конкретные ресурсы — доступ к сокету Docker, право читать логи определённого приложения или, как в контексте этой статьи, право выполнять команды через sudo.

groups ipetrov
id ipetrov
cat /etc/group | grep sudo

Файл /etc/group хранит список всех групп системы и их участников в простом текстовом формате: имя группы, пароль группы (практически никогда не используется на современных системах), числовой идентификатор GID и список пользователей через запятую. Редактировать этот файл напрямую не запрещено, но на практике почти всегда удобнее и безопаснее пользоваться командами usermod, groupadd и gpasswd, которые сами следят за корректностью формата файла.

Самая частая ошибка при добавлении пользователя в группу — забыть флаг -a у usermod -G. Без него команда полностью заменяет весь список дополнительных групп указанным значением, а не добавляет к нему новую группу: если у пользователя уже была группа docker, а администратор выполнит usermod -G sudo ipetrov без -a, пользователь потеряет доступ к Docker молча, без единого сообщения об ошибке, и обнаружится это только тогда, когда очередная команда docker откажет в доступе.

Для проверки, в какие именно группы входит пользователь прямо сейчас (в том числе после недавних изменений, которые ещё не применились к его текущей сессии — членство в новых группах в Linux подхватывается только при новом входе в систему), удобнее всего команда id: она выводит и первичную, и все дополнительные группы одной строкой вместе с их числовыми идентификаторами.

/etc/sudoers и почему его нельзя редактировать напрямую

Правила, определяющие, кто и какие команды может выполнять через sudo, хранятся в файле /etc/sudoers и в дополнительных файлах внутри директории /etc/sudoers.d/. Формально это обычный текстовый файл, и теоретически его можно открыть любым редактором, но на практике так делать не стоит никогда — sudo крайне чувствителен к синтаксическим ошибкам в этом файле, и одна лишняя запятая или неверно закрытая скобка способна полностью сломать работу sudo для всех пользователей системы разом, включая того, кто внёс ошибку.

visudo

Утилита visudo решает именно эту проблему: она открывает файл во временной копии, а перед сохранением прогоняет проверку синтаксиса — если найдена ошибка, visudo сообщает о ней и предлагает либо вернуться к редактированию, либо выйти без сохранения изменений, но никогда не позволяет применить заведомо испорченный конфиг. Редактор, который использует visudo, определяется переменной окружения EDITOR или VISUAL — по умолчанию это часто vi, но его несложно сменить на nano, если так удобнее.

Для отдельных наборов правил (например, права деплоя или временное правило для подрядчика) удобнее не трогать основной sudoers, а создать отдельный файл внутри /etc/sudoers.d/ через visudo -f с указанием пути — он подключается автоматически, а его удаление мгновенно откатывает выданные права, не трогая основной набор правил.

Синтаксис правил sudoers и NOPASSWD

Базовая строка правила в sudoers имеет вид "пользователь_или_группа хост=(от_чьего_имени) команды" — на практике поле хоста почти всегда остаётся ALL, поскольку один и тот же файл sudoers редко переносят между серверами без изменений, а поле "от чьего имени" задаёт, под какой учётной записью будет выполняться команда, обычно тоже ALL, то есть под любым пользователем, включая root.

# Полный административный доступ для группы sudo
%sudo   ALL=(ALL:ALL) ALL

# Полный доступ конкретному пользователю без запроса пароля
deploy  ALL=(ALL) NOPASSWD: ALL

Знак процента перед именем в первой строке означает, что правило применяется к группе, а не к конкретному пользователю, — это стандартный способ выдать одинаковые права сразу всем участникам группы sudo или wheel, не прописывая правило для каждого человека отдельно. Ключевое слово NOPASSWD отключает запрос пароля перед выполнением команд, попадающих под это правило, — удобно для автоматизации (например, для пользователя, от имени которого выполняется деплой через CI/CD), но снижает степень контроля, если применяется слишком широко.

Для сокращения длинных списков команд или пользователей sudoers поддерживает алиасы — именованные группы, которые затем можно использовать в правилах вместо перечисления всех значений заново каждый раз.

Cmnd_Alias WEBSERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart php8.3-fpm, /usr/bin/systemctl reload nginx
User_Alias  WEBADMINS = ipetrov, asmirnova

WEBADMINS ALL=(root) NOPASSWD: WEBSERVICES

Такой подход особенно оправдан на серверах с несколькими администраторами и повторяющимся набором задач: вместо копирования одной и той же длинной строки с командами для каждого нового человека достаточно добавить его имя в существующий User_Alias, а логика допустимых команд остаётся в одном месте и меняется один раз для всех, кто под неё подпадает.

Гранулярные права: разрешаем только то, что действительно нужно

Полный sudo-доступ (правило ALL) удобен, но нарушает принцип наименьших привилегий — учётная запись, скомпрометированная через слабый пароль или забытую активную сессию, в этом случае получает контроль над всем сервером целиком. Для многих практических задач достаточно куда более узкого набора прав: разработчику, отвечающему за деплой, обычно не нужен полный root, ему нужно перезапускать конкретные сервисы и, возможно, писать в конкретные директории.

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp, /usr/bin/journalctl -u myapp -n 100

Важная деталь, о которую спотыкаются даже опытные администраторы: разрешение конкретного бинарника без ограничения аргументов иногда позволяет обойти узость правила через встроенные возможности самой программы. Классический пример — редакторы vi и less, у которых есть команда запуска внешней оболочки (:!bash в vi или !bash в less); если пользователю разрешён sudo-доступ к такому редактору без ограничения аргументов, он фактически получает полный root-доступ через встроенную команду выхода в shell, а не только доступ к самому редактору.

Ограничение аргументов через маску сужает разрешённую команду до конкретного паттерна путей, что снижает риск использовать ту же команду для чтения произвольных файлов через символические ссылки или относительные пути с ../, — при построении гранулярных правил стоит проверять каждую разрешённую команду на такие обходные пути, а не полагаться только на видимость безопасности самого правила.

sudo vs su: разница в модели доступа

Команда su ("switch user", хотя изначально означала "substitute user") переключает текущую сессию на другого пользователя, запрашивая пароль именно этого целевого пользователя, — su root, например, запросит пароль root и после успешного ввода откроет полноценную сессию от его имени, в которой можно выполнять сколько угодно команд подряд без повторной аутентификации.

su -
whoami
exit

sudo устроен принципиально иначе: он не переключает сессию целиком, а выполняет одну конкретную команду от имени указанного пользователя (по умолчанию root), запрашивая при этом пароль не целевого пользователя, а самого вызывающего — то есть каждый администратор аутентифицируется собственным паролем, а не общим паролем root, которым пользуется su.

Эта разница напрямую влияет на аудит: su не оставляет никакой информации о том, какие именно команды выполнялись после переключения — с точки зрения системных логов это просто одна долгая сессия под root без привязки к личности того, кто её открыл. sudo, напротив, логирует каждый отдельный вызов с точным указанием, кто, когда и какую именно команду запустил, что делает восстановление истории действий на сервере с несколькими администраторами практически осуществимым, а не гипотетическим, а прямой su к root на защищённых серверах и вовсе намеренно ограничивают, требуя проходить только через sudo.

Отключение root-логина по SSH в пользу sudo-пользователей

После того как для администраторов созданы именные учётные записи с sudo-доступом, вход по SSH напрямую под root стоит отключить — это устраняет самую очевидную и самую часто атакуемую цель для перебора паролей, поскольку имя учётной записи root известно заранее на любом Linux-сервере, а имя обычного администратора атакующему ещё предстоит угадать или узнать.

# В файле /etc/ssh/sshd_config
PermitRootLogin no

Значение no полностью запрещает вход под root по SSH любым способом, включая аутентификацию по ключу; альтернативное значение prohibit-password (или без-пароля через ключ) допускает вход под root только по SSH-ключу, но не по паролю — это компромиссный вариант для случаев, когда некоторые автоматизированные системы всё ещё ожидают именно root, но полный отказ от парольной аутентификации для этой учётной записи уже заметно снижает риск успешного перебора.

Перед применением изменения критично убедиться, что хотя бы один sudo-пользователь с проверенным доступом уже существует и работает: открыть новое SSH-соединение под этим пользователем в отдельном окне терминала, не закрывая текущую сессию под root, выполнить sudo -l для проверки прав и только после подтверждения, что всё работает, перезапускать sshd с новой конфигурацией. Если сначала перезапустить sshd и лишь потом проверять доступ, единственная ошибка в настройке sudo-пользователя обернётся полной потерей SSH-доступа к серверу.

sshd -t
systemctl restart sshd

Команда sshd -t проверяет синтаксис конфигурационного файла точно так же, как visudo проверяет sudoers, — перезапускать sshd без этой проверки на продакшн-сервере не стоит никогда, поскольку ошибка в конфиге в лучшем случае помешает службе запуститься, а в худшем — оставит открытым способ входа, который администратор считал закрытым.

Аудит использования sudo: кто, когда и что делал

Каждая попытка выполнить команду через sudo — успешная или отклонённая — фиксируется в системном журнале аутентификации: на Debian и Ubuntu это /var/log/auth.log, на CentOS, AlmaLinux и других RHEL-подобных дистрибутивах — /var/log/secure. Запись включает имя пользователя, рабочую директорию, от чьего имени выполнялась команда и саму команду с аргументами.

grep sudo /var/log/auth.log | tail -50
journalctl _COMM=sudo --since "1 hour ago"

На системах с systemd тот же журнал удобнее просматривать через journalctl с фильтрацией по имени процесса или по временному диапазону — это особенно полезно при разборе конкретного инцидента, когда известно примерное время события, но неизвестно, какая именно команда его вызвала. Флаг --since принимает как относительные значения вроде "1 hour ago", так и точные временные метки.

Отдельного внимания заслуживает настройка самого sudo для более подробного логирования — по умолчанию в лог попадает только факт выполнения команды, но не её полный вывод. Директива в sudoers log_input и log_output вместе с указанием отдельного logfile позволяет при необходимости расширить аудит до записи не только команд, но и того, что именно они вывели на экран, что бывает важно при расследовании инцидентов на серверах с повышенными требованиями к комплаенсу — включать это стоит точечно, поскольку полная запись вывода быстро займёт заметный объём диска и требует отдельной ротации через logrotate.

Типичные ошибки при настройке пользователей и sudo

Прямое редактирование /etc/sudoers любым текстовым редактором вместо visudo — риск полностью сломать sudo для всех пользователей одной синтаксической опечаткой, которую заметит только сам sudo при следующем вызове, а не редактор в момент сохранения файла.

Забытый флаг -a у usermod -G при добавлении пользователя в новую группу — команда молча заменяет весь список дополнительных групп указанным значением, и пользователь незаметно теряет доступ к ресурсам через группы, в которых состоял раньше.

Отключение входа root по SSH до того, как проверен и подтверждён доступ хотя бы одного sudo-пользователя в отдельной, ещё не закрытой сессии, — самый быстрый способ гарантированно потерять доступ к серверу и обращаться за восстановлением к провайдеру через консоль.

Выдача разрешения sudo на редакторы или интерпретаторы общего назначения (vi, less, python, bash) без ограничения аргументов — большинство таких программ имеют встроенный способ выйти в shell, что фактически превращает узкое, казалось бы, правило в полный root-доступ.

Использование общего пароля root или общей SSH-пары ключей для нескольких администраторов вместо именных учётных записей — при таком подходе аудит действий через sudo теряет смысл, поскольку невозможно отличить одного администратора от другого по одной и той же учётной записи.

Чек-лист и итог: разграничение доступа как базовая гигиена сервера

Шаг 1. Создайте именную учётную запись для каждого администратора через useradd -m -s /bin/bash и установите пароль или загрузите SSH-ключ в её ~/.ssh/authorized_keys.

Шаг 2. Добавьте нужных пользователей в группу sudo (Debian/Ubuntu) или wheel (RHEL-подобные) через usermod -aG, не забывая флаг -a, чтобы не затереть уже имеющиеся группы.

Шаг 3. Для сервисных и автоматизированных учётных записей выдайте не полный, а гранулярный sudo-доступ на конкретные команды через отдельный файл в /etc/sudoers.d/, редактируемый через visudo -f.

Шаг 4. Проверьте доступ каждого нового sudo-пользователя в отдельной сессии до того, как менять что-либо в конфигурации SSH.

Шаг 5. Отключите PermitRootLogin в /etc/ssh/sshd_config, проверьте синтаксис через sshd -t и только затем перезапустите службу.

Шаг 6. Периодически просматривайте /var/log/auth.log (или /var/log/secure) и journalctl на предмет неожиданных попыток использования sudo, особенно после увольнения сотрудника с прежним доступом к серверу.

Разграничение доступа через именные учётные записи и sudo — это не разовая настройка при первом развёртывании сервера, а постоянная практика: каждый новый человек с доступом к серверу получает собственную учётную запись и ровно тот набор прав, который нужен для его задач, а не общий пароль root, унаследованный от предыдущего администратора. Такой подход не устраняет риски полностью, но делает почти любой инцидент отслеживаемым и обратимым — что при постоянном доступе под root просто невозможно в принципе.