Пользователи, sudo и минимальные права на VPS

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

В этой статье создаётся пользователь admin. Это имя используется как пример: замените его своим постоянным именем латиницей. До проверки нового входа держите открытыми исходный сеанс и консоль хостера.

Какие пользователи бывают на сервере

Для начала достаточно различать три роли:

• root управляет всей системой;
• личный пользователь представляет конкретного администратора и работает с обычными правами;
• служебный пользователь запускает одну программу, например веб-приложение, и не предназначен для входа человека.

Linux хранит для пользователя числовой UID, а для группы — GID. Группа объединяет несколько пользователей, которым нужен одинаковый доступ к файлам. Имена удобны людям, но ядро сопоставляет права по этим числовым идентификаторам.

Под какой учётной записью открыт текущий сеанс

Выполните на VPS три команды. Они ничего не меняют и показывают пользователя, его группы и наличие административной группы Ubuntu:

whoami
id
getent group sudo

whoami печатает имя текущего пользователя. id показывает UID, основную GID и дополнительные группы процесса. Например, фрагмент uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo) означает, что пользователь alex входит в свою основную группу и в группу sudo.

getent group sudo получает запись группы sudo из настроенного источника учётных данных. После последнего двоеточия перечислены её участники. Если команда ничего не вывела, остановитесь: в другом дистрибутиве административная группа может называться иначе.

Личная учётная запись администратора

Следующие команды выполняются из действующего root-сеанса или под уже проверенным администратором. Они создают пользователя admin, добавляют его в группу sudo и показывают результат:

sudo adduser admin
sudo usermod -aG sudo admin
id admin

adduser создаёт учётную запись и домашний каталог /home/admin, затем предлагает задать пароль и необязательные сведения. У usermod ключ -G задаёт дополнительные группы, а -a добавляет новую группу к существующему списку. Без -a список можно случайно заменить.

В выводе id admin должна появиться группа sudo. Если adduser сообщает, что имя занято, не изменяйте найденную учётную запись: сначала посмотрите её через getent passwd admin и выясните назначение.

Вход по SSH-ключу

Закрытый SSH-ключ остаётся на компьютере администратора. На VPS хранится только соответствующий публичный ключ в файле authorized_keys.

Если старый способ входа ещё разрешён, выполните следующую команду на своём компьютере. Вместо SERVER_IP подставьте IP-адрес VPS:

ssh-copy-id admin@SERVER_IP

ssh-copy-id выбирает локальный публичный ключ и добавляет его в /home/admin/.ssh/authorized_keys на сервере. Программа может запросить пароль нового пользователя. Если ключей несколько, укажите нужный публичный файл параметром -i, например ssh-copy-id -i "$HOME/.ssh/id_ed25519.pub" admin@SERVER_IP.

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

ssh admin@SERVER_IP
whoami
sudo -v
sudo id

После подключения whoami должен вывести admin. Команда sudo -v проверяет разрешение на повышение прав и при необходимости запрашивает пароль, но не выполняет административного действия. sudo id запускает только id с правами root; ожидаемый вывод содержит uid=0(root). После завершения вы по-прежнему остаетесь в сеансе admin.

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

Что именно делает sudo

В команде sudo apt update повышенные права получает только apt update. Это проще контролировать, чем открывать отдельную root-оболочку через sudo -i, где все последующие команды будут административными.

Посмотреть разрешения текущего пользователя можно без изменения системы:

sudo -l

Ключ -l означает list — вывести список. После проверки пароля sudo покажет команды, которые пользователь может или не может запускать. Строка (ALL : ALL) ALL обычно означает полные административные возможности. Она уместна для личного администратора, но не для приложения или сценария публикации.

Правило NOPASSWD отключает запрос пароля. Не используйте NOPASSWD: ALL ради удобства: украденный сеанс сразу получит полный доступ. Для автоматизации разрешают только конкретную команду после проверки того, нельзя ли через её параметры запустить что-то ещё.

Отдельный пользователь для приложения

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

Перед созданием проверьте, свободно ли имя myapp. Первая и последняя команды читают запись, средняя создаёт её:

getent passwd myapp
sudo useradd --system --home-dir /srv/myapp \
  --shell /usr/sbin/nologin myapp
getent passwd myapp

Первый getent при свободном имени ничего не выводит. Если строка появилась, не продолжайте — такой пользователь уже существует. У useradd --system параметр выбирает системную учётную запись, --home-dir записывает рабочий путь, а --shell /usr/sbin/nologin запрещает обычную интерактивную оболочку.

Эта команда не создаёт /srv/myapp, потому что не указан --create-home. Повторный getent должен показать имя, путь и /usr/sbin/nologin. Приложению не дают sudo; ему назначают доступ только к необходимым рабочим каталогам.

Общая группа для файлов проекта

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

sudo groupadd webdeploy
sudo usermod -aG webdeploy admin
sudo usermod -aG webdeploy myapp
id admin
id myapp

groupadd создаёт группу webdeploy. Обе команды usermod -aG добавляют её, не удаляя прежние группы. Последние две строки должны показать webdeploy в списках.

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

Когда приходится менять правила sudo

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

Редактируйте такой файл только через visudo и держите запасной root-сеанс открытым:

sudo visudo -f /etc/sudoers.d/deploy

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

После сохранения проверьте всю конфигурацию и итоговые разрешения пользователя admin:

sudo visudo -c
sudo -l -U admin

У visudo -c ключ означает check. Успешная проверка заканчивается сообщениями parsed OK. Вторая команда показывает правила для пользователя, указанного после -U. При ошибке снова откройте тот же файл через visudo -f из запасного сеанса; не закрывайте его до повторной успешной проверки.

Как отменить создание пользователя

Не удаляйте старую административную учётную запись сразу после первого удачного входа. Сначала проверьте SSH, sudo, доступ к нужным файлам и возможность войти через консоль хостера.

Если тестового пользователя всё же нужно удалить, сделайте это из другого административного сеанса. Первая команда ещё раз показывает точную цель, вторая удаляет запись пользователя:

id admin
sudo userdel admin

userdel без дополнительных параметров оставляет домашний каталог и файлы. После команды getent passwd admin не должен ничего вывести. Не добавляйте автоматическое удаление домашнего каталога: сначала проверьте его содержимое, процессы пользователя и файлы с его UID в других местах.

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

Первоисточники

• Ubuntu Server: user management
• sudoers manual
• OpenSSH: authorized_keys