Как создать пользователя с sudo на VPS

Материал продолжает серию о создании и настройке VPS в Timeweb Cloud: после первого подключения создаём отдельного администратора.

После первого входа на VPS под root стоит создать отдельного пользователя для повседневной работы. Обычные команды он выполняет со своими правами, а административные — через sudo. Так проще заметить момент, когда действие затронет систему целиком, и меньше вероятность случайно изменить системный файл.

Ниже создадим пользователя deploy на Ubuntu 24.04 LTS, добавим его в группу sudo, настроим вход по SSH-ключу и проверим результат в новом соединении. До завершения проверки исходное подключение администратора должно оставаться открытым.

Для практической части используем уже работающий VPS с Ubuntu 24.04 LTS — это позволяет сократить расходы на подготовку уроков. Если вы пока не подключались к серверу, начните с инструкции о первом входе по SSH.

Что означает доступ через sudo

root — системный администратор с UID 0. У нового пользователя собственный домашний каталог и обычные права. Добавление в группу sudo разрешает ему выполнять административные команды согласно политике системы.

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

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

Шаг 1. Проверяем имя и действующий доступ

В уже открытой административной сессии выполните:

whoami
getent passwd deploy

Если первая команда выводит root, следующие команды можно запускать без префикса sudo. Если вы вошли другим администратором, добавляйте sudo перед командами управления пользователями и системными файлами.

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

В примерах имя deploy условное. Можно выбрать другое короткое имя из строчных латинских букв. Используйте выбранный вариант последовательно в командах, путях /home/… и строке подключения.

Шаг 2. Создаём пользователя и задаём пароль

На Ubuntu удобно воспользоваться adduser:

adduser deploy

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

Для раздельного создания записи и назначения пароля есть другой вариант:

adduser --disabled-password --gecos "" deploy
passwd deploy

Выберите один способ. Не запускайте оба блока подряд. Флаг --disabled-password позволяет сначала создать запись без действующего пароля, а passwd — установить пароль следующим действием. Не оставляйте этот шаг незавершённым, если собираетесь использовать обычную политику sudo с запросом пароля.

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

Шаг 3. Добавляем пользователя в группу sudo

usermod -aG sudo deploy
id deploy
getent passwd deploy | cut -d: -f1,3,4,6,7

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

В выводе id deploy должна появиться группа sudo. Конкретные номера UID и GID на другом VPS будут отличаться. В строке учётной записи проверьте домашний каталог /home/deploy и обычную оболочку, например /bin/bash.

Изменение групп не обновляет уже работающие процессы пользователя. Если вы добавили sudo к существующей записи, откройте новое SSH-соединение. Вывод id deploy в административной сессии подтверждает запись в базе, а команда id внутри новой сессии — группы реально работающего пользователя.

Шаг 4. Подготавливаем вход по SSH-ключу

На своём компьютере создайте ключ, если подходящего ключа ещё нет:

ssh-keygen -t ed25519

При предложении сохранить файл проверьте путь: не перезаписывайте существующий ключ. Для постоянного административного доступа задайте кодовую фразу. Приватная часть остаётся на вашем компьютере, на сервер передаётся только файл с окончанием .pub.

На Linux и macOS публичный ключ можно установить командой:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Адрес 203.0.113.10 в статье — пример. Замените его IP своего VPS. Этот способ требует, чтобы сервер уже разрешал вход пользователя по паролю. Если парольная аутентификация отключена, установите публичный ключ через открытую административную сессию.

На сервере под root подготовьте каталог и файл:

install -d -o deploy -g deploy -m 700 /home/deploy/.ssh
touch /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
nano /home/deploy/.ssh/authorized_keys

Добавьте полную строку публичного ключа в отдельную строку файла. Она начинается, например, с ssh-ed25519. Сохраните существующие разрешённые ключи. Никогда не вставляйте туда содержимое приватного файла с заголовком BEGIN OPENSSH PRIVATE KEY.

В Windows публичную часть можно посмотреть в PowerShell:

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"

Если при генерации вы указали другой путь, используйте его. Windows OpenSSH может подключаться с ключом напрямую; команда ssh-copy-id для ручного способа не требуется.

Проверьте владельца и права:

stat -c '%a %U:%G %n' /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys

Для .ssh ожидается 700, для authorized_keys — 600, владелец обоих объектов — deploy. Домашний каталог не должен быть доступен на запись посторонним. Значение 750 для него подходит для этого примера; не меняйте рекурсивно права всего /home.

Шаг 5. Проверяем вход во втором терминале

Оставьте первоначальную сессию открытой. На своём компьютере запустите:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 deploy@203.0.113.10

При первом соединении сверяйте отпечаток сервера с доверенным источником, как описано в инструкции по SSH. Кодовая фраза защищает локальный ключ; пароль пользователя — отдельный способ аутентификации. Чтобы убедиться именно во входе по ключу, можно дополнительно указать:

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -i ~/.ssh/id_ed25519 deploy@203.0.113.10

Если ключ не подходит, такое соединение завершится ошибкой, а не незаметно перейдёт на пароль. Параметры этой команды действуют на клиенте и не меняют настройки SSH-сервера.

В новой сессии выполните:

whoami
id
sudo -v
sudo id -u

whoami должен вывести deploy, в id должна присутствовать группа sudo, а последняя команда — число 0. При sudo -v введите пароль пользователя deploy.

На нашем стенде также проверили конфигурацию уже установленного Nginx:

sudo nginx -t

Если Nginx ещё не установлен, этот шаг пропустите: отсутствие команды не означает неисправность sudo. Установка веб-сервера разобрана в отдельном уроке.

Что делать при ошибках

Ошибка	Что проверить
user already exists	Назначение существующей записи и её домашний каталог. Не удаляйте её ради повторного запуска инструкции.
deploy is not in the sudoers file	Членство в группе sudo, новое SSH-соединение и наличие стандартного правила группы в политике sudo.
Permission denied (publickey)	Имя пользователя, выбранный приватный ключ на клиенте, полную публичную строку на сервере, владельца и права файлов.
Пароль sudo не принимается	Используется пароль текущего пользователя, а не root или кодовая фраза ключа. Администратор может назначить новый пароль через passwd deploy.
После изменения группы sudo не работает	Закройте только новую пользовательскую сессию и войдите повторно. Первоначальный административный доступ сохраните.
sudo: command not found	На минимальном образе проверьте наличие пакета sudo; установку выполняет действующий администратор.

Для проверки политики под root используйте sudo -l -U deploy, для журналов входа — journalctl -u ssh.service --since "15 minutes ago". Не публикуйте журналы без проверки: в них могут присутствовать имена пользователей, адреса и другие данные доступа.

Если требуется изменить правила sudo, открывайте их через visudo: он проверяет синтаксис перед сохранением. Для добавления пользователя в стандартную административную группу Ubuntu редактирование /etc/sudoers обычно не требуется.

Как отозвать административные права

Удалить пользователя из группы можно из другой проверенной административной сессии:

gpasswd -d deploy sudo

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

Не выполняйте отзыв доступа у единственного работающего администратора. Удалять домашний каталог при простом снятии прав sudo не нужно.

Что проверить перед переходом к следующему уроку

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

Следующий шаг — настроить UFW и оставить открытыми необходимые порты. После этого можно разместить первый сайт на Nginx и подключить HTTPS.