Linux • VPS • SSH • sudo • Безопасность

Отдельный пользователь с sudo на VPS: создание и безопасная настройка SSH

Опубликовано 15 июля 2026 6 мин чтения Урок 3 из 6

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

Главное правило: не закрывайте текущий root-сеанс

Все изменения выполняйте, оставив первое SSH-подключение открытым. Проверка нового пользователя должна проходить во втором окне терминала. Только после успешного входа и выполнения sudo можно ограничивать root-доступ или парольную авторизацию.

Создайте пользователя

Замените artem на нужное имя. Лучше использовать короткое имя из латинских букв, цифр, дефиса или подчёркивания.

sudo adduser artem

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

Проверьте запись:

id artem
getent passwd artem
ls -ld /home/artem

Выдайте право использовать sudo

На Debian и Ubuntu штатная административная группа обычно называется sudo:

sudo usermod -aG sudo artem
id artem
getent group sudo

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

Новая группа применяется при следующем входе. Откройте отдельную сессию или выполните:

su - artem
sudo -v
sudo whoami

Последняя команда должна вывести root.

Перенесите SSH-ключ

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

ssh-copy-id artem@SERVER_IP

Если доступ пока есть только у root, скопируйте уже проверенный файл authorized_keys:

sudo install -d -m 700 -o artem -g artem /home/artem/.ssh
sudo install -m 600 -o artem -g artem \
  /root/.ssh/authorized_keys \
  /home/artem/.ssh/authorized_keys

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

sudo namei -l /home/artem/.ssh/authorized_keys
sudo -u artem ssh-keygen -l -f /home/artem/.ssh/authorized_keys

Каталог .ssh должен принадлежать пользователю и иметь права 700, файл ключей — 600. Слишком широкие права могут привести к отказу SSH использовать ключ.

Проверьте вход во втором окне

ssh artem@SERVER_IP
whoami
groups
sudo -v
sudo systemctl status ssh --no-pager

Не считайте настройку завершённой, пока одновременно не подтверждены:

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

Настройте sudo без редактирования основного файла

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

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

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

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

Не выдавайте NOPASSWD: ALL без веской причины. Команды, позволяющие запуск оболочки, редактировать произвольные файлы или менять сервисные юниты, фактически дают полный root-доступ.

Проверка всей конфигурации:

sudo visudo -c
sudo -l -U artem

Ограничьте root-вход только после теста

На современных системах удобно создать отдельный файл конфигурации:

sudoedit /etc/ssh/sshd_config.d/20-access.conf

Пример:

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

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

Перед применением:

sudo sshd -t
sudo systemctl reload ssh

Используйте reload, а не restart: действующий сеанс останется открытым. Затем снова создайте новое SSH-подключение.

Проверьте эффективные параметры SSH

sudo sshd -T | grep -E \
'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups'

Команда показывает итог после объединения основного файла и фрагментов из sshd_config.d. Это важнее просмотра одного файла: значение могло быть переопределено позже.

Дополнительное ограничение через AllowUsers или AllowGroups

На сервере с несколькими системными пользователями можно разрешить SSH только администраторам:

AllowGroups ssh-users

Создание группы:

sudo groupadd --system ssh-users
sudo usermod -aG ssh-users artem

Перед включением убедитесь, что пользователь действительно входит в группу. Ошибка в AllowUsers или AllowGroups — частая причина блокировки доступа.

Защитите локальную учётную запись

sudo passwd -S artem
sudo chage -l artem
sudo lastlog -u artem
sudo last -a | head

Не блокируйте пароль командой passwd -l, если он нужен для sudo. Вход по SSH уже можно запретить параметром PasswordAuthentication no, сохранив локальную проверку пароля для повышения прав.

Как удалить доступ бывшему администратору

Сначала заблокируйте вход и завершите активные сеансы:

sudo usermod -L artem
sudo pkill -KILL -u artem

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

sudo deluser artem sudo

Проверьте задания, процессы и файлы:

sudo crontab -u artem -l
ps -u artem -f
sudo find /etc /opt /srv /var/www -xdev -user artem -ls

Только после переноса нужных данных удаляйте пользователя:

sudo deluser --remove-home artem

Типовые ошибки

Пользователь не видит группу sudo. Нужно выйти и войти заново.
Ключ игнорируется. Проверьте владельца домашнего каталога, .ssh и authorized_keys.
После отключения паролей вход пропал. Вернитесь в оставленный root-сеанс или консоль провайдера и исправьте конфигурацию.
sudo сообщает об ошибке синтаксиса. Редактируйте правила только через visudo.
Скопирован приватный ключ. На сервер помещается только публичный ключ. Приватный ключ остаётся на доверенном устройстве.

Итоговый безопасный порядок

Оставить root-сеанс открытым.
Создать пользователя и включить его в группу sudo.
Добавить публичный SSH-ключ с правильными правами.
Проверить вход и sudo во втором окне.
Проверить конфигурацию sshd -t.
Отключить парольный вход и при необходимости root-доступ.
Ещё раз проверить новое подключение и сохранить доступ к консоли VPS.

Периодический аудит административных пользователей

После первоначальной настройки регулярно проверяйте, кто имеет право повышать привилегии и входить по SSH. Список участников группы sudo:

getent group sudo
sudo -l -U artem
sudo awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd

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

sudo find /etc/sudoers.d -maxdepth 1 -type f -ls
sudo grep -R --line-number -E 'NOPASSWD|ALL=' \
  /etc/sudoers /etc/sudoers.d 2>/dev/null

Проверьте ключи всех интерактивных пользователей и удалите неизвестные или устаревшие:

sudo find /root /home -path '*/.ssh/authorized_keys' \
  -type f -print -exec ssh-keygen -lf {} \;

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

Не храните общую учётную запись для команды

У каждого администратора должен быть собственный пользователь и собственный SSH-ключ. Общая учётная запись усложняет аудит и отзыв доступа. Для автоматизации создавайте отдельные service accounts с ограниченным набором команд, запретом интерактивной оболочки там, где она не нужна, и отдельным жизненным циклом ключей.