В этом посте разберёмся, как правильно и безопасно редактировать файл sudoers — тот самый, который определяет, кто и как может использовать команду sudo на вашем сервере. Почему это важно? Потому что одна опечатка в sudoers может оставить вас без рута, а неправильная настройка — открыть дыру в безопасности размером с Гранд-Каньон. Если вы настраиваете сервер для себя, для клиентов или просто хотите спать спокойно, зная, что никто не получит root-доступ через кривую настройку, — этот гайд для вас. Разберёмся, как всё устроено, как быстро и безболезненно внести нужные изменения, и как не попасть в классические ловушки.

Как работает файл sudoers?

Файл /etc/sudoers — это конфиг, который определяет, кто может выполнять команды от имени других пользователей (чаще всего — root) через sudo. Система проверяет этот файл каждый раз, когда кто-то запускает sudo. В нём можно:

• Разрешить или запретить доступ к sudo отдельным пользователям или группам
• Ограничить выполнение только определённых команд
• Настроить, нужно ли вводить пароль
• Задать специальные переменные окружения

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

Как быстро и просто всё настроить?

Главное правило: никогда не редактируйте /etc/sudoers напрямую через nano, vim или vi. Используйте только visudo. Эта утилита проверяет синтаксис перед сохранением и не даст вам сломать систему из-за опечатки.


sudo visudo


По умолчанию visudo откроет файл в vi или nano (зависит от дистрибутива и настроек переменной EDITOR). Если вы не любите vi, можно временно переключить редактор:


sudo EDITOR=nano visudo


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

Примеры, схемы, практические советы

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

Добавление пользователя в sudoers

Самый частый кейс — дать пользователю alice права на выполнение любых команд через sudo:


alice ALL=(ALL) ALL


Что это значит:

• alice — имя пользователя
• ALL — с любого хоста (актуально для сетевых систем)
• (ALL) — от имени любого пользователя (чаще всего root)
• ALL — любые команды

Добавление группы

Если у вас несколько админов, лучше добавить их в группу (например, sudo или wheel), а не прописывать каждого отдельно:


%sudo ALL=(ALL:ALL) ALL


Знак % означает группу. Все пользователи из группы sudo получат права.

Ограничение команд

Иногда нужно дать права только на определённые команды. Например, разрешить пользователю bob только перезапускать nginx:


bob ALL=NOPASSWD: /bin/systemctl restart nginx


Здесь NOPASSWD — не спрашивать пароль. Можно убрать, если хотите, чтобы пароль всё-таки спрашивался.

Плохие и хорошие примеры

Пример	Что не так?	Рекомендация
bob ALL=(ALL) NOPASSWD: ALL	bob может делать что угодно без пароля. Если bob взломают — сервер под угрозой.	Используйте NOPASSWD только для конкретных команд, а не для всего.
alice ALL=(ALL) ALL (без проверки через visudo)	Опечатка — и sudo перестанет работать для всех.	Редактируйте только через visudo.
%deploy ALL=(ALL) /usr/bin/git pull	Ограничение только на git pull — безопаснее, но если git pull вызывает скрипты, возможны уязвимости.	Проверяйте, какие команды реально выполняются, и ограничивайте максимально жёстко.

Практические советы

• Делайте резервную копию /etc/sudoers перед изменениями: sudo cp /etc/sudoers /etc/sudoers.bak
• Используйте sudo -l -U username для проверки, какие права есть у пользователя
• Для массовых изменений используйте /etc/sudoers.d/ — отдельные файлы для каждого пользователя или группы
• Не давайте NOPASSWD: ALL без крайней необходимости
• Проверяйте логи /var/log/auth.log (или /var/log/secure на CentOS) для аудита использования sudo

Команды и утилиты


# Открыть sudoers через visudo
sudo visudo

# Открыть sudoers через nano
sudo EDITOR=nano visudo

# Проверить права пользователя
sudo -l -U username

# Создать отдельный файл для пользователя
sudo visudo -f /etc/sudoers.d/alice

# Проверить синтаксис sudoers вручную
sudo visudo -c


Официальная документация: https://www.sudo.ws/man/1.8.13/sudoers.man.html

Похожие решения и альтернативы

• doas — альтернатива sudo, проще и безопаснее по умолчанию. Но sudo — стандарт де-факто на Linux.
• PolicyKit (polkit) — для более сложных политик доступа, но для большинства задач sudoers хватает с головой.
• SaltStack, Ansible, Chef — автоматизация, но всё равно используют sudo для выполнения команд от root.

Статистика и сравнение

Решение	Гибкость	Безопасность	Простота	Поддержка
sudoers	Высокая	Высокая (при правильной настройке)	Средняя	Linux, Unix, BSD
doas	Средняя	Очень высокая	Высокая	OpenBSD, Linux
polkit	Очень высокая	Высокая	Низкая	Linux

Интересные факты и нестандартные способы

• Можно использовать sudoers для ограничения переменных окружения, чтобы не дать пользователю подменить PATH и выполнить вредоносную команду.
• В sudoers можно использовать алиасы для группировки команд, пользователей и хостов — удобно для больших инфраструктур.
• Через sudoers можно разрешить запускать скрипты без пароля для автоматизации (например, деплой через CI/CD), но только для конкретных скриптов!
• Можно логировать все действия через Defaults log_output (поддерживается в новых версиях sudo) — удобно для аудита.
• В sudoers можно запретить запуск определённых команд даже с sudo (через ! перед командой).

Новые возможности для автоматизации и скриптов

Грамотно настроенный sudoers — это ключ к автоматизации. Например:

• CI/CD пайплайны могут выполнять деплой без ручного ввода пароля
• Скрипты мониторинга могут перезапускать сервисы при сбоях
• Пользователи могут выполнять только нужные им команды, не получая полный root
• Можно централизованно управлять доступом через /etc/sudoers.d/ — удобно для больших команд

Это не только ускоряет работу, но и снижает риски: никто не получит лишних прав, а вы всегда знаете, кто и что может делать на сервере.

Выводы и рекомендации

Редактирование sudoers — это не страшно, если соблюдать простые правила:

• Используйте только visudo — это ваш страховочный трос
• Давайте права только тем, кому они реально нужны, и только на нужные команды
• Используйте группы и /etc/sudoers.d/ для масштабируемости
• Не злоупотребляйте NOPASSWD
• Проверяйте логи и периодически ревизируйте настройки

Если вы только начинаете работать с серверами — не бойтесь экспериментировать, но всегда делайте бэкапы и тестируйте изменения на тестовой машине или VPS. Кстати, если нужен VPS для экспериментов — заказать VPS можно здесь, а если нужен выделенный сервер — тут.

Помните: правильная настройка sudoers — это не только про удобство, но и про безопасность. Чем раньше вы научитесь делать это правильно, тем меньше будет головной боли в будущем. Удачной настройки и пусть ваши сервера будут всегда под контролем!

---

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

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