[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"/ru/kb/how-to/vps/redaktirovanie-fajla-sudoersKbData":3},{"page":4,"pages":137,"recommendedPages":138,"category":69,"categoryTree":69,"total":15,"currentOrder":166,"activeManualCategoryId":69,"tag":-1},{"route":5,"uuid":8,"title":9,"excerpt":10,"content":11,"view_count":12,"published_at":13,"modified_at":13,"like":14,"category":17,"hero_image":62,"seo_metadata":63,"schema_org_metadata":67,"open_graph_metadata":70,"sections":71,"tags":128,"breadcrumbs":129,"images":136},{"language":6,"path":7},"ru","/kb/how-to/vps/redaktirovanie-fajla-sudoers","8d1d2147-56d2-2bbd-2d75-eb8a4b2736b9","Файл Sudoers: инструкция по редактированию и настройке","На сервере с несколькими пользователями права на выполнение команд от имени root приходится разграничивать: одному пользователю нужен полный доступ, другому – только возможность перезапускать определенный сервис, третьему – вообще ничего, кроме собственных задач. За такое разграничение прав в Linux отвечают команда sudo и файл /etc/sudoers.","\n\u003Cp>На сервере с несколькими пользователями права на выполнение команд от имени root приходится разграничивать: одному пользователю нужен полный доступ, другому – только возможность перезапускать определенный сервис, третьему – вообще ничего, кроме собственных задач. За такое разграничение прав в Linux отвечают команда \u003Ccode>sudo\u003C/code> и файл \u003Ccode>/etc/sudoers\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>В статье рассматривается, как устроен файл Sudoers, как его безопасно редактировать и как добавлять в него собственные правила доступа. Все примеры приводятся для VPS с \u003Ca href=\"https://beget.com/ru/cloud/marketplace/ubuntu-24-04?utm_source=kb&utm_medium=article&utm_campaign=sudoers&utm_content=marketplace_ubuntu_24_04\">Ubuntu 24.04 LTS\u003C/a>.\u003C/p>\n\n\n\n\u003Ch2 id=\"chto-takoe-sudo-i-fayl-etc-sudoers\">Что такое sudo и файл /etc/sudoers\u003C/h2>\n\n\n\n\u003Cp>Команда \u003Ccode>sudo\u003C/code> позволяет пользователю выполнить отдельную команду с правами другого пользователя. Чаще всего \u003Ccode>sudo\u003C/code> используется для выполнения административных команд с правами \u003Ccode>root\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>При использовании \u003Ccode>sudo\u003C/code> пользователю не требуется знать пароль \u003Ccode>root\u003C/code>: для подтверждения операции используется пароль самого пользователя.\u003C/p>\n\n\n\n\u003Cp>Использование \u003Ccode>sudo\u003C/code> также позволяет связать выполненную команду с конкретной учетной записью. События, связанные с использованием \u003Ccode>sudo\u003C/code>, записываются в системный журнал. В Ubuntu информация об аутентификации и использовании привилегий обычно находится в файле \u003Ccode>/var/log/auth.log\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo tail -n 20 /var/log/auth.log\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Правила, которые определяют, какие пользователи и группы могут выполнять те или иные команды через \u003Ccode>sudo\u003C/code>, хранятся в файле \u003Ccode>/etc/sudoers\u003C/code>. Это обычный текстовый файл: каждая его строка – либо правило, либо параметр, либо комментарий. \u003Ccode>sudo\u003C/code> читает файл при каждом вызове, поэтому изменения вступают в силу сразу после сохранения – перезапускать или перезагружать ничего не нужно.\u003C/p>\n\n\n\n\u003Cp>Дополнительные правила размещают в отдельных файлах каталога \u003Ccode>/etc/sudoers.d/\u003C/code>. Они подключаются к основному файлу директивой в его последней строке и обрабатываются как его продолжение. Такой способ удобнее правки основного файла: правило для конкретной задачи лежит в отдельном файле, его легко найти, изменить или удалить целиком, а обновление пакета \u003Ccode>sudo\u003C/code> не затронет ваши настройки.\u003C/p>\n\n\n\n\u003Cp>Файл \u003Ccode>/etc/sudoers\u003C/code> принадлежит пользователю root и группе root и имеет права доступа \u003Ccode>0440\u003C/code>. Читать его и вносить изменения могут только root и члены группы \u003Ccode>root\u003C/code> – всем остальным файл недоступен даже на чтение.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-otkryt-fayl-etc-sudoers-dlya-redaktirovaniya\">Как открыть файл /etc/sudoers для редактирования\u003C/h2>\n\n\n\n\u003Cp>Редактирование Sudoers не следует выполнять обычным текстовым редактором. Используйте для этого отдельную команду:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>visudo\u003C/code> блокирует файл на время редактирования, чтобы его не изменил параллельно другой администратор, и проверяет синтаксис перед сохранением: при ошибке команда сообщит о ней и предложит вернуться к правке. Ни один другой способ такой проверки не выполняет – поэтому файлы в каталоге \u003Ccode>/etc/sudoers.d/\u003C/code> тоже создавайте и редактируйте только через \u003Ccode>visudo\u003C/code>, указав путь к файлу явно:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo -f /etc/sudoers.d/имя_файла\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если файла еще нет, \u003Ccode>visudo\u003C/code> создаст его.\u003C/p>\n\n\n\n\u003Cp>Если отредактировать конфигурацию обычным редактором и допустить ошибку в синтаксисе, \u003Ccode>sudo\u003C/code> будет сообщать о ней при каждом вызове. Более того, неверно составленное правило может лишить пользователей доступа — а при отсутствии активной root-сессии восстановить его будет сложнее. \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-alert alert-block alert-block-info\">\u003Cdiv class=\"alert-block-title\">Обратите внимание!\u003C/div>\u003Cdiv class=\"alert-block-content\">Перед тем как приступить к правке откройте вторую сессию с root-доступом – второе подключение по SSH или консоль сервера в панели управления. Не закрывайте ее, пока не убедитесь, что sudo работает как ожидалось. Если новая конфигурация окажется нерабочей, вы сможете откатить изменения через эту сессию, не теряя доступ к серверу.\u003C/div>\u003C/div>\n\n\n\n\u003Cp>Перед крупными изменениями сохраните резервную копию файла:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo cp /etc/sudoers /etc/sudoers.bak\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Каталог \u003Ccode>/etc\u003C/code> для копии выбран не случайно. Файл, сохраненный в \u003Ccode>/etc/sudoers.d/\u003C/code> под именем без точки, будет подключен как еще один конфигурационный файл. А поскольку копия основного файла содержит директиву \u003Ccode>@includedir /etc/sudoers.d\u003C/code>, каталог начнет подключать сам себя: параметры продублируются, и \u003Ccode>sudo\u003C/code> выдаст ошибку \u003Ccode>/etc/sudoers.d: too many levels of includes\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>По умолчанию на Ubuntu \u003Ccode>visudo\u003C/code> открывает файл в редакторе \u003Ccode>nano\u003C/code>. Чтобы выбрать другой редактор, выполните команду:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo update-alternatives --config editor\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда выводит список установленных редакторов с номерами:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>There are 4 choices for the alternative editor (providing /usr/bin/editor).\n  Selection    Path                Priority   Status\n------------------------------------------------------------\n* 0            /bin/nano            40        auto mode\n  1            /bin/ed             -100       manual mode\n  2            /bin/nano            40        manual mode\n  3            /usr/bin/vim.basic   30        manual mode\n  4            /usr/bin/vim.tiny    15        manual mode\n\nPress <enter> to keep the current choice[*], or type selection number:\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Введите номер требуемого редактора и нажмите \u003Ccode>Enter\u003C/code>. Учтите, что эта настройка изменит редактор по умолчанию не только для \u003Ccode>visudo\u003C/code>, а для всех программ, которые обращаются к \u003Ccode>/usr/bin/editor\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"iz-chego-sostoit-fayl-sudoers\">Из чего состоит файл Sudoers\u003C/h2>\n\n\n\n\u003Cp>Файл \u003Ccode>/etc/sudoers\u003C/code> содержит настройки, которые определяют поведение \u003Ccode>sudo\u003C/code> и права пользователей. В нем могут находиться:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>комментарии;\u003C/li>\u003Cli>параметры Defaults;\u003C/li>\u003Cli>правила доступа;\u003C/li>\u003Cli>псевдонимы пользователей, хостов, команд и пользователей для запуска (Runas);\u003C/li>\u003Cli>директивы подключения дополнительных файлов.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>После установки Ubuntu 24.04 LTS файл Sudoers выглядит следующим образом:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>#\n# This file MUST be edited with the 'visudo' command as root.\n#\n# Please consider adding local content in /etc/sudoers.d/ instead of\n# directly modifying this file.\n#\n# See the man page for details on how to write a sudoers file.\n#\nDefaults        env_reset\nDefaults        mail_badpass\nDefaults        secure_path=\"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin\"\n# This fixes CVE-2005-4890 and possibly breaks some versions of kdesu\n# (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)\nDefaults        use_pty\n# This preserves proxy settings from user environments of root\n# equivalent users (group sudo)\n#Defaults:%sudo env_keep += \"http_proxy https_proxy ftp_proxy all_proxy no_proxy\"\n# This allows running arbitrary commands, but so does ALL, and it means\n# different sudoers have their choice of editor respected.\n#Defaults:%sudo env_keep += \"EDITOR\"\n# Completely harmless preservation of a user preference.\n#Defaults:%sudo env_keep += \"GREP_COLOR\"\n# While you shouldn't normally run git as root, you need to with etckeeper\n#Defaults:%sudo env_keep += \"GIT_AUTHOR_* GIT_COMMITTER_*\"\n# Per-user preferences; root won't have sensible values for them.\n#Defaults:%sudo env_keep += \"EMAIL DEBEMAIL DEBFULLNAME\"\n# \"sudo scp\" or \"sudo rsync\" should be able to use your SSH agent.\n#Defaults:%sudo env_keep += \"SSH_AGENT_PID SSH_AUTH_SOCK\"\n# Ditto for GPG agent\n#Defaults:%sudo env_keep += \"GPG_AGENT_INFO\"\n# Host alias specification\n# User alias specification\n# Cmnd alias specification\n# User privilege specification\nroot    ALL=(ALL:ALL) ALL\n# Members of the admin group may gain root privileges\n%admin ALL=(ALL) ALL\n# Allow members of group sudo to execute any command\n%sudo   ALL=(ALL:ALL) ALL\n# See sudoers(5) for more information on \"@include\" directives:\n@includedir /etc/sudoers.d\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Содержимое файла может немного отличаться в зависимости от версии пакета \u003Ccode>sudo\u003C/code>.\u003C/p>\n\n\n\n\u003Ch3 id=\"kommentarii\">Комментарии\u003C/h3>\n\n\n\n\u003Cp>Строки, начинающиеся с \u003Ccode>#\u003C/code>, являются комментариями и не влияют на работу \u003Ccode>sudo\u003C/code>. Например:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode># User alias specification\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>В стандартном файле такие строки служат заголовками разделов конфигурации, а также поясняют закомментированные настройки.\u003C/p>\n\n\n\n\u003Ch3 id=\"parametry-defaults\">Параметры Defaults\u003C/h3>\n\n\n\n\u003Cp>Строки, начинающиеся с \u003Ccode>Defaults\u003C/code>, задают параметры работы \u003Ccode>sudo\u003C/code>. Они не предоставляют пользователям дополнительных прав.\u003C/p>\n\n\n\n\u003Cp>В стандартном файле Ubuntu активны четыре параметра:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>env_reset\u003C/code> – ограничивает набор переменных окружения, которые передаются команде, запущенной через \u003Ccode>sudo\u003C/code>;\u003C/li>\u003Cli>\u003Ccode>mail_badpass\u003C/code> – отправляет письмо (по умолчанию – пользователю \u003Ccode>root\u003C/code>) при вводе неверного пароля. Работает, только если на сервере настроен почтовый агент (MTA);\u003C/li>\u003Cli>\u003Ccode>secure_path\u003C/code> – задает список каталогов, в которых \u003Ccode>sudo\u003C/code> ищет исполняемые файлы;\u003C/li>\u003Cli>\u003Ccode>use_pty\u003C/code> – предписывает \u003Ccode>sudo\u003C/code> запускать команды в отдельном псевдотерминале (PTY).\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Ниже в файле находится блок закомментированных параметров \u003Ccode>env_keep\u003C/code>. Он дополняет \u003Ccode>env_reset: env_keep\u003C/code> перечисляет переменные окружения, которые нужно сохранить при запуске команды через \u003Ccode>sudo\u003C/code>. Эти строки отключены по умолчанию и предлагаются как готовые решения для частых ситуаций: сохранить настройки прокси, выбранный пользователем редактор, переменные Git или переменные SSH-агента. Чтобы применить любую из них, достаточно удалить \u003Ccode>#\u003C/code> в начале строки.\u003C/p>\n\n\n\n\u003Cp>Запись вида \u003Ccode>Defaults:%sudo\u003C/code> означает, что параметр действует не для всех, а только для пользователей группы \u003Ccode>sudo\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Еще два параметра часто добавляют вручную, хотя в стандартном файле Sudoers они отсутствуют:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>timestamp_timeout\u003C/code> – время в минутах, в течение которого sudo не запрашивает пароль повторно;\u003C/li>\u003Cli>\u003Ccode>passwd_tries\u003C/code> – количество попыток ввода пароля (по умолчанию – три).\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Изменять параметры \u003Ccode>Defaults\u003C/code> без необходимости не рекомендуется.\u003C/p>\n\n\n\n\u003Ch2 id=\"pravila-dostupa\">Правила доступа\u003C/h2>\n\n\n\n\u003Cp>Правила доступа определяют, \u003Cstrong>кому, где, от имени какого пользователя и какие команды разрешено выполнять через \u003Ccode>sudo\u003C/code>\u003C/strong>.\u003C/p>\n\n\n\n\u003Cp>Правило строится по схеме:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>кто  где=(от_кого:от_какой_группы)  ТЕГИ:  команды\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Например:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>%sudo ALL=(ALL:ALL) ALL\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Данное правило означает:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>\u003Cstrong>%sudo\u003C/strong> ALL=(ALL:ALL) ALL\u003C/code> – пользователи группы sudo. Символ % перед именем означает, что указана группа;\u003C/li>\u003Cli>\u003Ccode>%sudo \u003Cstrong>ALL\u003C/strong>=(ALL:ALL) ALL\u003C/code> – правило действует на любом хосте;\u003C/li>\u003Cli>\u003Ccode>%sudo ALL=\u003Cstrong>(ALL:ALL)\u003C/strong> ALL\u003C/code> – команду можно выполнить от имени любого пользователя и любой группы;\u003C/li>\u003Cli>\u003Ccode>%sudo ALL=(ALL:ALL) \u003Cstrong>ALL\u003C/strong>\u003C/code> – разрешены любые команды.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Таким образом, пользователи группы \u003Ccode>sudo\u003C/code> могут выполнять любые команды с помощью \u003Ccode>sudo\u003C/code>. Пользователь, добавленный в эту группу командой \u003Ccode>sudo usermod -aG sudo username\u003C/code>, получает права, определенные этим правилом. Чтобы новое членство в группе вступило в силу, пользователю нужно переподключиться по SSH.\u003C/p>\n\n\n\n\u003Cp>В скобках указывается, от чьего имени разрешено выполнять команду. Это может быть любая учетная запись, существующая на сервере: \u003Ccode>(root)\u003C/code>, \u003Ccode>(www-data)\u003C/code>. Значение \u003Ccode>ALL\u003C/code> разрешает выполнить команду от имени любого пользователя – выбрать его можно флагом \u003Ccode>sudo -u\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Через двоеточие добавляется второе значение – группа, с которой выполняется команда: например, \u003Ccode>(ALL:ALL)\u003C/code> или \u003Ccode>(www-data:www-data)\u003C/code>. Выбрать группу можно флагом \u003Ccode>sudo -g\u003C/code>. Если вторая часть не указана, флаг \u003Ccode>-g\u003C/code> использовать не требуется.\u003C/p>\n\n\n\n\u003Cp>Строка \u003Ccode>%admin ALL=(ALL) ALL\u003C/code> осталась в файле от старых версий Ubuntu, где группа \u003Ccode>admin\u003C/code> использовалась для выдачи административных прав. В современных версиях Ubuntu для этой цели используется группа \u003Ccode>sudo\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Перед списком разрешенных команд можно использовать специальные теги. Наиболее распространенный – \u003Ccode>NOPASSWD:\u003C/code>. Он отключает запрос пароля для указанных команд:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>ivan ALL=(root) NOPASSWD: /usr/bin/apt update\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если \u003Ccode>NOPASSWD:\u003C/code> не указан, \u003Ccode>sudo\u003C/code> запросит пароль самого пользователя. После успешного ввода пароль не запрашивается повторно в течение 15 минут в рамках того же терминала – это поведение задается параметром \u003Ccode>timestamp_timeout\u003C/code>. В другом терминале пароль будет запрошен заново.\u003C/p>\n\n\n\n\u003Ch3 id=\"psevdonimy\">Псевдонимы\u003C/h3>\n\n\n\n\u003Cp>Псевдонимы позволяют объединить несколько пользователей, хостов или команд под одним именем. Это удобно, когда один и тот же набор команд или пользователей встречается в нескольких правилах:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>User_Alias ADMINS = ivan, petr\nCmnd_Alias SERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart mysql\nADMINS      ALL=(root) SERVICES\n%deployers  ALL=(root) NOPASSWD: SERVICES\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Данные правила означают:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>ADMINS\u003C/code> – псевдоним пользователей \u003Ccode>ivan\u003C/code> и \u003Ccode>petr\u003C/code>;\u003C/li>\u003Cli>\u003Ccode>SERVICES\u003C/code> – псевдоним двух разрешенных команд;\u003C/li>\u003Cli>третья строка разрешает пользователям \u003Ccode>ivan\u003C/code> и \u003Ccode>petr\u003C/code> выполнять эти команды с запросом пароля;\u003C/li>\u003Cli>четвертая строка разрешает те же команды пользователям группы \u003Ccode>deployers\u003C/code>, но уже без запроса пароля.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Если позже потребуется добавить в список третий сервис, достаточно изменить одну строку с \u003Ccode>Cmnd_Alias\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Имя псевдонима должно начинаться с заглавной буквы и состоять из заглавных латинских букв, цифр и подчеркиваний. Имена вида \u003Cstrong>Admins\u003C/strong> или \u003Cstrong>admins\u003C/strong> \u003Ccode>visudo\u003C/code> не примет.\u003C/p>\n\n\n\n\u003Cp>Кроме \u003Ccode>User_Alias\u003C/code> и \u003Ccode>Cmnd_Alias\u003C/code>, есть еще два типа псевдонимов: \u003Ccode>Host_Alias\u003C/code> – для объединения хостов и \u003Ccode>Runas_Alias\u003C/code> – для объединения пользователей, от имени которых разрешено выполнять команды. Например, для пользователя \u003Ccode>www-data\u003C/code> можно завести псевдоним:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Runas_Alias WEB = www-data\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>И затем указывать в правилах \u003Ccode>(WEB)\u003C/code> вместо \u003Ccode>(www-data)\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Пока правил немного, псевдонимы только усложняют файл. Они полезны в конфигурациях с большим количеством пользователей и разрешенных команд.\u003C/p>\n\n\n\n\u003Ch3 id=\"podklyuchenie-kataloga-sudoers-d\">Подключение каталога sudoers.d\u003C/h3>\n\n\n\n\u003Cp>В конце стандартного файла Ubuntu находится директива:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>@includedir /etc/sudoers.d\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Она подключает дополнительные конфигурационные файлы из каталога \u003Ccode>/etc/sudoers.d/\u003C/code>. Например:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>/etc/sudoers.d/deploy\n/etc/sudoers.d/backup\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>В Ubuntu 20.04 и более ранних версиях эта же строка выглядит как \u003Ccode>#includedir /etc/sudoers.d\u003C/code>. Несмотря на символ \u003Ccode>#\u003C/code>, это не комментарий, а та же директива в старом синтаксисе.\u003C/p>\n\n\n\n\u003Cp>\u003Ccode>sudo\u003C/code> рассматривает основной файл и подключенные файлы как единую конфигурацию. Если пользователю соответствуют несколько правил, они могут влиять на итоговые разрешения. Для совпадающих команд порядок правил имеет значение: последующее правило может изменить, например, тег \u003Ccode>NOPASSWD\u003C/code> на \u003Ccode>PASSWD\u003C/code> или наоборот.\u003C/p>\n\n\n\n\u003Cp>Файлы из \u003Ccode>/etc/sudoers.d/\u003C/code> обрабатываются в лексикографическом порядке: например, \u003Ccode>/etc/sudoers.d/10-deploy\u003C/code> будет прочитан раньше, чем \u003Ccode>/etc/sudoers.d/20-monitor\u003C/code>. Файлы, чье имя содержит точку или заканчивается на \u003Ccode>~\u003C/code>, пропускаются – такие имена характерны для резервных копий и временных файлов, которые оставляют некоторые редакторы.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-dobavit-sobstvennoe-pravilo\">Как добавить собственное правило\u003C/h2>\n\n\n\n\u003Cp>Собственные правила рекомендуем добавлять в отдельные файлы каталога \u003Ccode>/etc/sudoers.d/\u003C/code>, а не изменять основной файл \u003Ccode>/etc/sudoers\u003C/code>. Так вы сможете изменить или удалить правило отдельно от основной конфигурации.\u003C/p>\n\n\n\n\u003Cp>Создайте файл – назовите его по назначению правила или по имени пользователя, например, \u003Ccode>deploy\u003C/code>, \u003Ccode>backup\u003C/code> или \u003Ccode>nginx-restart\u003C/code>. Точки в имени быть не должно: как сказано выше, такие файлы \u003Ccode>sudo\u003C/code> пропускает. Например:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo -f /etc/sudoers.d/nginx-restart\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>После сохранения задайте файлу права \u003Ccode>0440\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo chmod 0440 /etc/sudoers.d/nginx-restart\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>С другими правами \u003Ccode>sudo\u003C/code> продолжит применять правила из файла, но при проверке конфигурации будет сообщать \u003Ccode>bad permissions, should be mode 0440\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Команды в правилах указываются полным путем. Узнать путь можно командой \u003Ccode>command -v\u003C/code>. Например:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>command -v systemctl\n/usr/bin/systemctl\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Ниже разобраны четыре типовые ситуации – от простого правила к более сложному.\u003C/p>\n\n\n\n\u003Ch3 id=\"odna-komanda-dlya-odnogo-polzovatelya\">Одна команда для одного пользователя\u003C/h3>\n\n\n\n\u003Cp>Начнем с самого простого случая: разработчик \u003Ccode>ivan\u003C/code> должен уметь перезапускать nginx после правки конфигурации сайта, но полный доступ к \u003Ccode>sudo\u003C/code> ему не нужен.\u003C/p>\n\n\n\n\u003Cp>Добавьте в файл правило:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>ivan ALL=(root) /usr/bin/systemctl restart nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Данное правило означает:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>ivan\u003C/code> – пользователь, которому предоставляется право;\u003C/li>\u003Cli>\u003Ccode>ALL\u003C/code> – правило действует на любом хосте;\u003C/li>\u003Cli>\u003Ccode>(root)\u003C/code> – команда выполняется только от имени \u003Ccode>root\u003C/code>. Перезапуск системного сервиса требует прав \u003Ccode>root\u003C/code>, но указывать здесь \u003Ccode>(ALL)\u003C/code> не нужно: это разрешило бы запускать команду и от имени любой другой учетной записи;\u003C/li>\u003Cli>\u003Ccode>/usr/bin/systemctl restart nginx\u003C/code> – конкретная разрешенная команда с фиксированным аргументом.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Теперь \u003Ccode>ivan\u003C/code> может выполнить \u003Ccode>sudo systemctl restart nginx\u003C/code>, введя свой пароль. Любая другая команда через \u003Ccode>sudo\u003C/code> ему недоступна, в том числе \u003Ccode>sudo systemctl restart mysql\u003C/code> или \u003Ccode>sudo systemctl stop nginx\u003C/code>.\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-alert alert-block alert-block-info\">\u003Cdiv class=\"alert-block-title\">Обратите внимание!\u003C/div>\u003Cdiv class=\"alert-block-content\">\u003Ccode>sudo\u003C/code> сравнивает команду с правилом посимвольно. Правило из примера выше не разрешит команду \u003Ccode>sudo systemctl restart nginx.service\u003C/code>, хотя для \u003Ccode>systemd\u003C/code> это то же самое действие.\u003C/div>\u003C/div>\n\n\n\n\u003Ch3 id=\"neskolko-komand-bez-zaprosa-parolya\">Несколько команд без запроса пароля\u003C/h3>\n\n\n\n\u003Cp>Теперь усложним задачу: тот же перезапуск nginx выполняет не человек, а скрипт автоматического деплоя, который работает от имени пользователя \u003Ccode>deploy\u003C/code>. Кроме перезапуска, скрипту нужно перезагружать конфигурацию nginx без остановки сервиса. Пароль в этом случае вводить некому – значит, его запрос нужно отключить.\u003C/p>\n\n\n\n\u003Cp>Несколько команд перечисляются в одном правиле через запятую, а за отключение пароля отвечает тег \u003Ccode>NOPASSWD:\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Пользователю \u003Ccode>deploy\u003C/code> становятся доступны обе команды, причем без ввода пароля. Любая другая команда через \u003Ccode>sudo\u003C/code> останется недоступной – при условии, что \u003Ccode>deploy\u003C/code> не состоит в группе \u003Ccode>sudo\u003C/code> и под него не подходит другое, более широкое правило.\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-alert alert-block alert-block-info\">\u003Cdiv class=\"alert-block-title\">Обратите внимание!\u003C/div>\u003Cdiv class=\"alert-block-content\">Тег \u003Ccode>NOPASSWD:\u003C/code> стоит использовать только там, где ввод пароля действительно невозможен: в скриптах, заданиях cron и системах автоматического развертывания. Если команду выполняет человек, запрос пароля лучше оставить.\u003C/div>\u003C/div>\n\n\n\n\u003Ch3 id=\"pravilo-dlya-neskolkih-polzovateley\">Правило для нескольких пользователей\u003C/h3>\n\n\n\n\u003Cp>Следующая ситуация: смотреть журнал nginx нужно всем разработчикам, а не одному человеку. Перечислять их поименно неудобно – при появлении нового сотрудника необходимо будет внести изменения в конфигурацию \u003Ccode>sudo\u003C/code>. Вместо этого права выдают группе.\u003C/p>\n\n\n\n\u003Cp>Создайте группу и добавьте в нее пользователей:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo groupadd devs\nsudo usermod -aG devs имя_пользователя\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>После добавления в группу пользователь должен переподключиться по SSH – новая сессия нужна, чтобы изменение членства в группе вступило в силу.\u003C/p>\n\n\n\n\u003Cp>В правиле вместо имени пользователя укажите группу, поставив перед ее именем знак \u003Ccode>%\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>%devs ALL=(root) /usr/bin/journalctl -u nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Правило распространяется на всех участников группы \u003Ccode>devs\u003C/code>. Чтобы выдать право новому сотруднику, теперь достаточно добавить его в группу – файлы в \u003Ccode>/etc/sudoers.d/\u003C/code> менять не нужно.\u003C/p>\n\n\n\n\u003Ch3 id=\"zapusk-komandy-ot-imeni-drugogo-polzovatelya\">Запуск команды от имени другого пользователя\u003C/h3>\n\n\n\n\u003Cp>В последней ситуации меняется не список команд, а учетная запись, от имени которой они выполняются. Пользователю \u003Ccode>deploy\u003C/code> нужно запускать скрипт очистки кеша приложения. Сам кеш принадлежит \u003Ccode>www-data\u003C/code> – учетной записи, от имени которой работает веб-сервер и приложение. Если запустить скрипт от \u003Ccode>root\u003C/code>, файлы, которые он создаст заново, будут принадлежать \u003Ccode>root\u003C/code>, и приложение под \u003Ccode>www-data\u003C/code> не сможет их перезаписать – работа сайта нарушится.\u003C/p>\n\n\n\n\u003Cp>Укажите в скобках \u003Ccode>www-data\u003C/code> вместо \u003Ccode>root\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>deploy ALL=(www-data) /usr/local/bin/clear-app-cache.sh\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Такое правило требует, чтобы пользователь \u003Ccode>deploy\u003C/code> явно указал целевую учетную запись флагом \u003Ccode>-u\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo -u www-data /usr/local/bin/clear-app-cache.sh\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Без флага \u003Ccode>-u\u003C/code> команда выполнялась бы от имени \u003Ccode>root\u003C/code> – а такого разрешения правило не дает, и \u003Ccode>sudo\u003C/code> отклонит запуск.\u003C/p>\n\n\n\n\u003Cp>Пользователю \u003Ccode>deploy\u003C/code> при этом не нужно ни состоять в группе \u003Ccode>sudo\u003C/code>, ни знать пароль учетной записи \u003Ccode>www-data\u003C/code>: право переключиться на нее дает правило, а \u003Ccode>sudo\u003C/code> запрашивает пароль пользователя \u003Ccode>deploy\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Если правил, где команды выполняются от имени \u003Ccode>www-data\u003C/code>, становится несколько, заведите для него псевдоним \u003Ccode>Runas_Alias\u003C/code>, как показано в разделе «Псевдонимы», и используйте его вместо повторения имени пользователя в каждом правиле.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-proverit-pravilo\">Как проверить правило\u003C/h2>\n\n\n\n\u003Cp>После сохранения проверьте синтаксис всей конфигурации \u003Ccode>sudo\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo -c\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Чтобы проверить только один файл, укажите путь к нему:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo -c -f /etc/sudoers.d/deploy\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если ошибок нет, посмотрите права пользователя:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo -l -U deploy\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Среди разрешенных команд должно присутствовать добавленное правило.\u003C/p>\n\n\n\n\u003Cp>После этого проверьте правило непосредственно от имени пользователя \u003Ccode>deploy\u003C/code>. Переключитесь на него:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo -u deploy -i\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>После чего выполните разрешенную команду:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl restart nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если правило составлено верно, команда выполнится. Попытка выполнить любую другую команду через \u003Ccode>sudo\u003C/code> будет отклонена: \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Sorry, user deploy is not allowed to execute '/usr/bin/systemctl stop nginx' as root on server \u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Такой ответ означает, что правила для пользователя есть, но конкретная команда в них не разрешена. \u003C/p>\n\n\n\n\u003Cp>Если пользователь отсутствует в файле sudoers, то есть для него нет ни персонального правила, ни правила для его группы, при попытке выполнить команду появится другая ошибка:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>[sudo] password for alex:\nalex is not in the sudoers file.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Выполнять команды через \u003Ccode>sudo\u003C/code> такой пользователь не сможет, пока правило для него или его группы не будет добавлено. Если правило вы создавали, проверьте имя пользователя в правиле и имя файла.\u003C/p>\n\n\n\n\u003Cp>Чтобы вернуться в свою учетную запись, введите \u003Ccode>exit\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-izmenit-ili-udalit-pravilo\">Как изменить или удалить правило\u003C/h2>\n\n\n\n\u003Cp>Чтобы изменить правило, снова откройте соответствующий файл:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo visudo -f /etc/sudoers.d/deploy\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Чтобы удалить правило, удалите нужную строку из файла и сохраните изменения. Если файл больше не содержит нужных правил, удалите его целиком:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo rm /etc/sudoers.d/deploy\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>После изменения или удаления правила снова проверьте конфигурацию командой \u003Ccode>sudo visudo -c\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-ne-vydat-lishnie-prava\">Как не выдать лишние права\u003C/h2>\n\n\n\n\u003Cp>Правило может выглядеть достаточно строгим, но фактически давать пользователю полный доступ к серверу. Чаще всего это происходит в трех случаях: \u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Cstrong>Команда указана без аргументов.\u003C/strong> Например, правило \u003Ccode>deploy ALL=(root) /usr/bin/systemctl\u003C/code> разрешает не перезапуск одного сервиса, а любые действия с любыми юнитами \u003Ccode>systemd\u003C/code> – например, подмену и запуск произвольного юнита от имени \u003Ccode>root\u003C/code>. Указывайте аргументы явно.\u003C/li>\u003Cli>\u003Cstrong>Разрешена команда, из которой можно выйти в командную оболочку.\u003C/strong> Текстовые редакторы (\u003Ccode>vim\u003C/code>, \u003Ccode>nano\u003C/code>), а также \u003Ccode>find\u003C/code>, \u003Ccode>less\u003C/code>, \u003Ccode>tar\u003C/code>, \u003Ccode>awk\u003C/code> умеют запускать произвольные команды или изменять любые файлы. Разрешив их через \u003Ccode>sudo\u003C/code>, вы фактически выдаете права \u003Ccode>root\u003C/code>.\u003C/li>\u003Cli>\u003Cstrong>В аргументах использован шаблон.\u003C/strong> Конструкция \u003Ccode>/usr/bin/systemctl restart *\u003C/code> разрешает перезапуск любого сервиса, а не только нужного.\u003C/li>\u003C/ul>\n\n\n\n\u003Ch2 id=\"vosstanovlenie-posle-vozniknoveniya-oshibki-v-fayle-etc-sudoers\">Восстановление после возникновения ошибки в файле /etc/sudoers\u003C/h2>\n\n\n\n\u003Cp>Не всякая ошибка в конфигурации приводит к потере доступа. Если синтаксически неверной оказалась одна строка, \u003Ccode>sudo\u003C/code> сообщит о ней, пропустит ее и продолжит работать по остальным правилам:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>/etc/sudoers:58:9: syntax error\nthis is broken\n        ^~~~~~\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Опаснее другой случай: ошибка в строке, которая как раз и выдает права. Например, при ошибке в строке \u003Ccode>%sudo ALL=(ALL:ALL) ALL\u003C/code> отброшена будет именно она, и все пользователи группы sudo потеряют возможность выполнять административные команды. Воспользоваться sudo, чтобы это исправить, уже не получится – права root придется получить другим способом.\u003C/p>\n\n\n\n\u003Cp>Проще всего это сделать через вторую сессию с root-доступом, открытую заранее. Верните файл из резервной копии:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>cp /etc/sudoers.bak /etc/sudoers\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если такая сессия не была открыта, есть еще несколько вариантов:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Cstrong>Переключиться на root командой su -.\u003C/strong> Пароль пользователя \u003Ccode>root\u003C/code> для VPS выдается при создании сервера.\u003C/li>\u003Cli>\u003Cstrong>Загрузить сервер в режиме восстановления.\u003C/strong> Сервер загружается в отдельную среду, где можно смонтировать его диск и отредактировать файл напрямую, без \u003Ccode>sudo\u003C/code>, – доступ предоставляется от имени \u003Ccode>root\u003C/code>.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>При восстановлении из копии верните файлу Sudoers владельца и права доступа:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>chown root:root /etc/sudoers\nchmod 0440 /etc/sudoers\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если файл принадлежит не \u003Ccode>root\u003C/code>, sudo откажется работать полностью – для всех пользователей и для всех команд:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo: /etc/sudoers is owned by uid 1009, should be 0\nsudo: error initializing audit plugin sudoers_audit\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>К правам доступа sudo относится менее строго, но \u003Ccode>visudo -c\u003C/code> ожидает только \u003Ccode>0440\u003C/code> и при других значениях сообщает \u003Ccode>bad permissions, should be mode 0440\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>После восстановления проверьте синтаксис командой \u003Ccode>visudo -c\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"zaklyuchenie\">Заключение\u003C/h2>\n\n\n\n\u003Cp>Файл \u003Ccode>/etc/sudoers\u003C/code> определяет, кому и какие команды разрешено выполнять через \u003Ccode>sudo\u003C/code>. Редактируйте его только через \u003Ccode>visudo\u003C/code>, а собственные правила храните отдельными файлами в каталоге \u003Ccode>/etc/sudoers.d/\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Составляя правило, выдавайте минимально необходимый набор прав: указывайте конкретные команды с фиксированными аргументами вместо \u003Ccode>ALL\u003C/code> и конкретного пользователя вместо \u003Ccode>(ALL)\u003C/code>. После каждого изменения проверяйте синтаксис командой \u003Ccode>sudo visudo -c\u003C/code>, а фактические права пользователя – командой \u003Ccode>sudo -l -U\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Если возникнут вопросы, напишите нам, пожалуйста, тикет из панели управления аккаунта (раздел “\u003Ca href=\"https://cp.beget.com/support?utm_source=kb&utm_medium=article&utm_campaign=sudoers&utm_content=cp_support\">Помощь и поддержка\u003C/a>”), а если вы захотите обсудить, как добавить пользователя в Sudoers, или другие вопросы с коллегами по цеху и сотрудниками Beget – ждем вас в нашем \u003Ca href=\"https://t.me/beget_chat\">сообществе\u003C/a> в Telegram.\u003C/p>\n",12,"2026-08-25T11:36:36.000Z",{"count":15,"liked":16},0,false,{"route":18,"title":20,"tags":21,"breadcrumbs":54,"uuid":55,"parent_uuid":56,"default_page_path":25,"seo_metadata":57},{"language":6,"path":19},"/kb/how-to/vps","VPS",[22,26,30,34,38,42,46,50],{"id":23,"title":20,"seo_metadata":24},"vps",{"title":25,"description":25,"header":25,"keywords":25},"",{"id":27,"title":28,"seo_metadata":29},"apache","Apache",{"title":25,"description":25,"header":25,"keywords":25},{"id":31,"title":32,"seo_metadata":33},"lets-encrypt","Let's Encrypt",{"title":25,"description":25,"header":25,"keywords":25},{"id":35,"title":36,"seo_metadata":37},"nginx","Nginx",{"title":25,"description":25,"header":25,"keywords":25},{"id":39,"title":40,"seo_metadata":41},"ssl","SSL",{"title":25,"description":25,"header":25,"keywords":25},{"id":43,"title":44,"seo_metadata":45},"vestacp","VestaCP",{"title":25,"description":25,"header":25,"keywords":25},{"id":47,"title":48,"seo_metadata":49},"perenos-sajta","Перенос сайта",{"title":25,"description":25,"header":25,"keywords":25},{"id":51,"title":52,"seo_metadata":53},"terminal","Терминал",{"title":25,"description":25,"header":25,"keywords":25},[],"957abe7d-4a90-1475-bfb0-6439507ed391","fa9a1354-631a-4206-df34-291f0db8f42a",{"title":58,"description":59,"header":60,"keywords":61},"VPS. Полезные статьи – Beget","Полезные статьи о VPS на сайте Beget","VPS. Полезные статьи","vps, вопрос ответ",{"src":25,"text":25},{"title":64,"description":65,"keywords":66},"Файл Sudoers: редактирование и настройка","Подробный разбор файла Sudoers, как его редактировать и настраивать самостоятельно | Инструкция от Beget","выполнение команд с привилегиями, команда sudo, мануал по файлу sudoers",{"faq":68,"how_to":69,"product":69},[],null,{},[72,76,79,82,86,89,92,95,98,101,104,107,110,113,116,119,122,125],{"level":73,"name":74,"anchor":75},1,"Что такое sudo и файл /etc/sudoers","chto-takoe-sudo-i-fayl-etc-sudoers",{"level":73,"name":77,"anchor":78},"Как открыть файл /etc/sudoers для редактирования","kak-otkryt-fayl-etc-sudoers-dlya-redaktirovaniya",{"level":73,"name":80,"anchor":81},"Из чего состоит файл Sudoers","iz-chego-sostoit-fayl-sudoers",{"level":83,"name":84,"anchor":85},2,"Комментарии","kommentarii",{"level":83,"name":87,"anchor":88},"Параметры Defaults","parametry-defaults",{"level":73,"name":90,"anchor":91},"Правила доступа","pravila-dostupa",{"level":83,"name":93,"anchor":94},"Псевдонимы","psevdonimy",{"level":83,"name":96,"anchor":97},"Подключение каталога sudoers.d","podklyuchenie-kataloga-sudoers-d",{"level":73,"name":99,"anchor":100},"Как добавить собственное правило","kak-dobavit-sobstvennoe-pravilo",{"level":83,"name":102,"anchor":103},"Одна команда для одного пользователя","odna-komanda-dlya-odnogo-polzovatelya",{"level":83,"name":105,"anchor":106},"Несколько команд без запроса пароля","neskolko-komand-bez-zaprosa-parolya",{"level":83,"name":108,"anchor":109},"Правило для нескольких пользователей","pravilo-dlya-neskolkih-polzovateley",{"level":83,"name":111,"anchor":112},"Запуск команды от имени другого пользователя","zapusk-komandy-ot-imeni-drugogo-polzovatelya",{"level":73,"name":114,"anchor":115},"Как проверить правило","kak-proverit-pravilo",{"level":73,"name":117,"anchor":118},"Как изменить или удалить правило","kak-izmenit-ili-udalit-pravilo",{"level":73,"name":120,"anchor":121},"Как не выдать лишние права","kak-ne-vydat-lishnie-prava",{"level":73,"name":123,"anchor":124},"Восстановление после возникновения ошибки в файле /etc/sudoers","vosstanovlenie-posle-vozniknoveniya-oshibki-v-fayle-etc-sudoers",{"level":73,"name":126,"anchor":127},"Заключение","zaklyuchenie",[],[130,134],{"route":131,"title":133},{"language":6,"path":132},"/kb/how-to","Полезные статьи",{"route":135,"title":20},{"language":6,"path":19},[],[],[139,148,157],{"route":140,"uuid":142,"title":143,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":144,"tags":145,"breadcrumbs":146,"images":147},{"language":6,"path":141},"/kb/how-to/vps/vypusk-i-ustanovka-ssl-sertifikatov-ot-lets-encrypt-na-vps","b327c054-235e-4b6c-847f-3db6de0f8f6e","Получение SSL-сертификата от Let's Encrypt на VPS",[],[],[],[],{"route":149,"uuid":151,"title":152,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":153,"tags":154,"breadcrumbs":155,"images":156},{"language":6,"path":150},"/kb/how-to/vps/ochistka-obrazov-kontejnerov-i-tomov-v-docker","475b07ab-1ff6-8dbc-f36b-c0e30992eee7","Как очистить образы, контейнеры и тома Docker",[],[],[],[],{"route":158,"uuid":160,"title":161,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":162,"tags":163,"breadcrumbs":164,"images":165},{"language":6,"path":159},"/kb/how-to/vps/simvolicheskie-ssylki-kak-sozdat-i-rabotat","94078842-b665-208c-9277-c4c9ba0c7b54","Символические ссылки: как создать и работать в Linux",[],[],[],[],"popularity-desc"]