Вход под root в Ubuntu: su, sudo -i и когда это вообще нужно

Вы арендовали VPS в WeaselCloud, а в панели прямо на странице сервера уже написано: логин root, и рядом - настоящий пароль. Заходите по нему - и вы сразу root, без отдельного пользователя и без sudo. Удобно, но именно это удобство и путает: половина туториалов в интернете написана для другого мира - там VPS выдают с обычным пользователем и заблокированным root, и половина команд вроде su - в этом мире работает иначе, чем у вас. Разбираемся, что root на самом деле означает, чем отличаются sudo, sudo -i, sudo su - и su -, и почему на многих других провайдерах su - вообще не работает, а у вас - работает.

Коротко. Root - это учётная запись с UID 0 и максимально широкими административными правами в системе, а не «режим», который где-то включается. На VPS от WeaselCloud вход под root по SSH включён с первого дня - логин и пароль показаны прямо в панели, и su - или ssh root@ сработают этим же паролем. Это удобно для старта, но не значит, что стоит постоянно работать под root: любая команда выполняется немедленно, без разделения на «обычные» и «привилегированные» действия. sudo команда даёт root-права на одну команду и не открывает отдельную сессию. sudo -i и sudo su - на типичной Ubuntu приводят к одинаковому результату - интерактивной root-сессии с /root в качестве домашнего каталога, но механика у них разная и разбирается отдельно ниже. Если хотите работать безопаснее, заведите себе отдельного sudo-пользователя и переключайтесь на root только когда это правда нужно - как это делается, тоже разбираем ниже.

Что такое root на самом деле

Root - обычная учётная запись Linux, устроенная так же, как любой другой пользователь, только с идентификатором UID 0. Проверить это можно одной командой:

head -1 /etc/passwd

Вы увидите строку вроде root:x:0:0:root:/root:/bin/bash. Два нуля после root:x: - это UID и GID, идентификаторы пользователя и группы. root - суперпользователь с UID 0 и максимально широкими административными правами в обычной системе: может читать и писать любые файлы, останавливать чужие процессы, менять сетевые настройки, монтировать диски. Это не переключатель «режим администратора вкл/выкл» - это конкретная учётная запись, под которую можно войти так же, как под любую другую, если знать пароль или иметь ключ.

Почему у вас уже есть root - и почему не у всех

Здесь WeaselCloud отличается от многих крупных облачных провайдеров - и разница объясняет большую часть путаницы вокруг root в интернете. Стандартный облачный образ Ubuntu (тот, что используют почти все провайдеры, включая WeaselCloud) по умолчанию блокирует root: пароля нет, вход по SSH под root запрещён на уровне SSH-демона, вместо этого создаётся один обычный пользователь. Но при разворачивании сервера WeaselCloud поверх этого образа сам задаёт root пароль и открывает по нему прямой SSH-доступ - и показывает этот пароль вам в панели, на странице сервера. Это осознанное решение ради простоты первого запуска: не нужно разбираться с sudo и пользователями, чтобы просто зайти на только что созданный сервер.

Именно поэтому туториалы расходятся: инструкция, написанная под условный DigitalOcean или чистый образ облака, честно говорит «сначала создайте sudo-пользователя, у root по умолчанию нет пароля» - и это правда для того окружения. На WeaselCloud та же самая команда su - у вас просто сработает сразу настоящим паролем root, потому что провайдер уже включил то, что в другом месте пришлось бы включать вручную.

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

Как проверить, что у вас есть доступ к root

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

groups

Ищите в выводе sudo - если группа есть, у пользователя в принципе есть право повышать привилегии. Вторая команда точнее - она показывает, что именно разрешено:

sudo -l

• если ваш пользователь настроен на полный доступ, в выводе будет строка вроде (ALL : ALL) ALL - это значит «может выполнить любую команду от имени любого пользователя»;
• если доступ ограничен, там будет конкретный список разрешённых команд;
• если пользователя вообще нет в sudoers, команда ответит Sorry, user ubuntu may not run sudo on host - и тогда все команды ниже не сработают, пока администратор не добавит вас в группу sudo.

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

sudo команда - разовый пропуск, не сессия

Самый частый и самый безопасный способ - выполнить одну конкретную команду от имени root, не открывая отдельную сессию. sudo не создаёт нового логина: он запускает только указанную команду с повышенными правами и сразу возвращает управление вашей обычной оболочке. Текущий рабочий каталог обычно не меняется, но окружение самой команды sudo фильтрует по своим правилам - это не то же самое, что «всё остаётся как было».

sudo apt update
sudo systemctl restart nginx

sudo обычно спрашивает ваш собственный пароль - не пароль root - при первой привилегированной команде в сессии, а затем какое-то время использует уже сохранённую авторизацию: по умолчанию в Ubuntu это около 15 минут, если администратор не менял таймаут. Поэтому вторая команда подряд, как systemctl restart nginx здесь, обычно пароль уже не спросит - это нормально, не баг. Если хотите сразу сбросить сохранённую авторизацию, есть sudo -k. Каждая команда подействует только на себя: закончилась - вы снова обычный пользователь, никакой отдельной root-сессии не осталось. Для 90% задач на сервере этого достаточно: поставить пакет, перезапустить сервис, посмотреть содержимое системного файла через sudo cat.

sudo -i - полноценный вход под root

Когда команд от root нужно много подряд - редактируете несколько системных файлов, разбираетесь с логами в нескольких каталогах, запускаете скрипт обслуживания - постоянно набирать sudo перед каждой строкой неудобно. Для этого есть sudo -i: флаг -i означает «симулировать начальный вход» и открывает полноценную root-сессию, как будто вы залогинились под root с нуля.

sudo -i

После ввода своего пароля приглашение меняется: было ubuntu@host:~$, стало root@host:~# - смена символа с $ на # стандартный маркер root-сессии в Ubuntu. Меняется и рабочий каталог: $HOME теперь /root, а не ваш прежний домашний каталог, и cd без аргументов уводит именно туда. Загружается профиль root - его переменные окружения, не ваши.

Выйти из root-сессии и вернуться к своему пользователю - команда exit или сочетание Ctrl+D. Приглашение снова станет $.

sudo su - и sudo -i - в чём разница на практике

В старых инструкциях часто встречается sudo su - вместо sudo -i. Внешне результат похож, но механика реально разная, не только «исторически». sudo -i сам запускает shell целевого пользователя как login shell и формирует окружение по собственным правилам. sudo su - делает это в два шага: сначала sudo поднимает вас до root, чтобы запустить команду su, а затем su - с дефисом на конце ещё раз формирует login-окружение уже по своим правилам и через PAM. Из-за этой лишней прослойки PATH, переменные окружения и то, что попадает в аудит-логи, теоретически могут немного отличаться между двумя вариантами.

sudo su -

На типичной Ubuntu обе команды приводят к интерактивной root-сессии с /root в качестве домашнего каталога, и для повседневной работы разница не критична. Но sudo -i делает это напрямую и в этом смысле понятнее и предсказуемее; sudo su - запускает дополнительный процесс su поверх и по сути не даёт ничего, чего не даёт sudo -i, так что специально переходить на него не стоит. Если уже привыкли к sudo su - и не видите проблем - менять привычку тоже необязательно.

su - без sudo - почему на WeaselCloud он просто работает

Важная деталь, которая путает почти всех, кто уже читал про Linux где-то ещё: su - без sudo впереди спрашивает пароль не вашего пользователя, а пароль ТОГО аккаунта, под который вы переключаетесь - то есть пароль root.

su -

На многих Ubuntu cloud-образах это не сработает, потому что учётная запись root по умолчанию password-locked и у неё нет пригодного для аутентификации пароля - это не гарантия на все случаи, конкретный провайдер или администратор сервера мог всё поменять, но для стокового облачного образа это типичное поведение. На WeaselCloud - сработает, если ввести пароль root, который показан в панели на странице сервера: приглашение сменится на root@host:~#, и вы в root-сессии. Именно поэтому важно не путать «su - не работает» (типичное поведение на большинстве других провайдеров) с «su - работает, но просит незнакомый пароль» - у вас второй случай, и пароль просто нужно взять из панели, а не искать, где его сбросили.

Держать этот пароль под рукой удобно, но лишний раз вводить его вручную не обязательно: sudo -i или sudo su - от своего пользователя (если вы его завели, см. ниже) решают ту же задачу через ваш собственный пароль, а не пароль root - это на один секрет меньше, который может утечь.

ssh root@сервер напрямую - работает сразу, но подумайте дважды

На WeaselCloud прямое подключение под root по SSH работает из коробки - это ровно то, что показано в панели как основной способ подключения: логин root, пароль рядом.

ssh [email protected]

Введите пароль из панели - и вы сразу в корневой сессии, без промежуточного пользователя. На многих других провайдерах та же команда чаще всего ответит Permission denied (publickey), потому что password login для root там отключён и SSH предлагает только вход по ключу - но само по себе это сообщение говорит лишь, что доступные в этом соединении методы аутентификации не сработали: причиной может быть и запрет root, и отсутствие нужного ключа в authorized_keys, и не тот ключ, и права на файлы, и Match-блок в конфиге - точную причину видно только по эффективному конфигу sshd и логам. У WeaselCloud блокировки нет, и это одновременно и самый быстрый путь на сервер, и самый широкий - если пароль root узнает кто-то ещё, он получает вообще всё, без единого дополнительного барьера. Дальше по тексту - как сделать вход надёжнее, если сервер смотрит наружу дольше, чем на пару тестовых часов.

Как сделать вход безопаснее, если сервер остаётся в проде надолго

Для теста на пару часов дефолтная настройка WeaselCloud - логин и пароль root прямо в панели - нормальна и удобна. Для сервера, который будет смотреть в интернет неделями и месяцами, стоит сузить вход. root - имя учётной записи, которое есть на любом Linux-сервере в мире, поэтому оно первым идёт в списке любого автоматического перебора паролей: боты стучатся именно в root@ваш_ip круглосуточно, а не только когда вы сами об этом думаете.

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

sudo adduser deploy
sudo usermod -aG sudo deploy

Теперь заходите под deploy и используете sudo -i, когда нужен root. Это не значит, что случайная команда вроде rm -rf сама по себе перестанет быть опасной - если вы уже внутри root-сессии через sudo -i, она выполнится немедленно, точно так же, как при прямом входе под root. Реальная польза отдельного sudo-пользователя в другом: обычная работа идёт без UID 0, а повышение до root происходит осознанно и только там, где оно правда нужно - это снижает шанс случайно выполнить обычную команду с root-правами просто потому, что вы и так уже были root. И у запуска sudo <команда> есть более явный след в логе отдельных повышений привилегий, чем у долгой сессии - если открыть root-шелл через sudo -i, команды, которые вы наберёте внутри него дальше, уже не превращаются в отдельные записи sudo-лога; для полноценного журнала команд внутри такой сессии нужны отдельные механизмы вроде sudo I/O logging или auditd.

Второй шаг - убрать вход root по паролю через SSH и оставить только вход по ключу, или вовсе выключить прямой SSH-доступ для root. Не редактируйте главный /etc/ssh/sshd_config напрямую: Ubuntu подключает к нему все файлы из /etc/ssh/sshd_config.d/*.conf в самом начале, а для большинства директив OpenSSH побеждает первое встреченное значение - если там уже лежит какой-то более ранний drop-in с PermitRootLogin (например, от образа или от прошлой настройки), именно он определит реальное поведение, а не ваша правка в основном файле, и вы получите ложное чувство, что закрыли root, когда на деле не закрыли. Правильный способ - создать свой собственный drop-in с понятным именем:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PermitRootLogin prohibit-password

Это значение разрешает root заходить только по ключу, без единой попытки подобрать пароль по SSH. Если root по SSH вообще не нужен - под своим deploy-пользователем и так есть sudo -i - поставьте PermitRootLogin no. Файл с префиксом 00- обрабатывается раньше остальных drop-in, поэтому его значение и станет тем самым «первым встреченным». Перед перезапуском обязательно проверьте синтаксис и то, какое значение реально получилось в эффективном конфиге:

sudo sshd -t
sudo sshd -T | grep -i permitrootlogin

Если sshd -t прошла без ошибок и sshd -T показывает именно то значение, которое вы поставили - применяйте изменение перезагрузкой конфига, не полным перезапуском:

sudo systemctl reload ssh

• в Ubuntu системный юнит называется ssh, а не sshd, как в некоторых других дистрибутивах - это не опечатка;
• reload здесь предпочтительнее restart по той же логике, что и для nginx - конфиг перечитывается без разрыва уже установленных соединений;
• не закрывайте текущую SSH-сессию, пока не откроете новую под пользователем deploy и не убедитесь, что вход работает - опечатка в конфиге может оставить вас без доступа к серверу вообще.

Permission denied и command not found - разные проблемы

Эти два сообщения путают чаще всего, хотя причины у них не связаны между собой.

Если вы опечатались в имени команды - написали, например, sudp вместо sudo - оболочка ответит bash: sudp: command not found. Это значит только одно: такой программы не существует под этим именем, прав доступа здесь вообще ни при чём.

Если ваш пользователь не состоит в группе sudo, при попытке выполнить sudo что-нибудь вы увидите другое сообщение: ubuntu is not in the sudoers file. This incident will be reported. Это про права - самостоятельно добавить себя в группу sudo не получится, нужен другой пользователь с root-правами.

А если пароль просто неверный - для sudo, su - или при подключении по SSH с паролем - ответ будет вида Sorry, try again. или su: Authentication failure. Команда существует, доступ разрешён, введённые данные не подошли - или, как в случае su - без заданного пароля root, не могли подойти в принципе.

Как зайти под root в Ubuntu?

На WeaselCloud - напрямую, логином root и паролем из панели, через ssh root@ваш_ip или su -. На большинстве других провайдеров прямого пути нет: там заходят под обычным пользователем и используют sudo -i или sudo su -, потому что у root изначально нет ни пароля, ни разрешённого SSH-входа.

sudo su - и sudo -i - в чём разница?

По итоговому состоянию на типичной Ubuntu - почти никакой: обе приводят к интерактивной root-сессии с /root в качестве домашнего каталога. Механика разная: sudo -i сам формирует login-окружение по правилам sudo, а sudo su - делает то же самое в два шага через дополнительный su -, из-за чего PATH и то, что попадает в аудит-логи, могут немного отличаться. sudo -i проще и предсказуемее, специально переходить на sudo su - незачем.

Почему su - просит пароль, которого я не задавал?

su - спрашивает пароль от root, а не ваш собственный. На WeaselCloud этот пароль уже задан провайдером и показан в панели на странице сервера - введите именно его, а не пароль своего SSH-логина. На большинстве других провайдеров пароля root вообще нет, учётная запись заблокирована по умолчанию, и там su - будет отвечать Authentication failure при любом вводе - это нормальное поведение для того окружения, просто не для WeaselCloud.

Как включить root-доступ по SSH в Ubuntu?

На WeaselCloud он уже включён - логин root и пароль показаны в панели. Если нужно настроить его вручную на другом сервере или образе - предпочтительно разрешать root только по ключу, не по паролю: создайте /etc/ssh/sshd_config.d/00-hardening.conf со строкой PermitRootLogin prohibit-password. Значение PermitRootLogin yes при разрешённой парольной аутентификации открывает и вход root по паролю - для обычного VPS, смотрящего в интернет, это почти никогда не нужно и заметно увеличивает поверхность атаки. После правки - обязательно sudo sshd -t, затем sudo sshd -T | grep -i permitrootlogin для проверки эффективного значения, и sudo systemctl reload ssh. Проверяйте вход в новой сессии, не закрывая текущую.

Что значит Permission denied при ssh root@?

На WeaselCloud это чаще всего означает, что вы ввели неверный пароль, либо что кто-то уже поменял настройки безопасности сервера (например, поставил PermitRootLogin no). На других провайдерах то же сообщение часто значит, что password login для root отключён и сервер предлагает только вход по ключу - но само сообщение лишь говорит, что доступные в этом соединении методы аутентификации не сработали, точную причину стоит смотреть по эффективному конфигу (sudo sshd -T | grep -i permitrootlogin) и логам, а не гадать по одному сообщению.

Коротко

• root - суперпользователь с UID 0 и максимально широкими административными правами, а не отдельный «режим» системы.
• На WeaselCloud вход под root по SSH включён с первого дня - логин и пароль показаны в панели; на многих других провайдерах root по умолчанию заблокирован.
• sudo команда запускает только указанную команду с повышенными правами; sudo обычно спрашивает пароль на первой команде в сессии, а дальше около 15 минут использует сохранённую авторизацию - это нормально, не дыра.
• sudo -i и sudo su - на типичной Ubuntu приводят к похожему результату - root-сессии с /root в качестве домашнего каталога, но механика разная (sudo -i - напрямую, sudo su - через дополнительный su -); специально переходить на sudo su - незачем.
• su - без sudo спрашивает пароль root - на WeaselCloud он есть и сработает, на многих Ubuntu cloud-образах root password-locked и пароля попросту нет.
• Реальная польза отдельного sudo-пользователя - не в паузе перед rm -rf (её нет, если вы уже в root-сессии), а в том, что обычная работа идёт без UID 0, и повышение до root происходит осознанно.
• Для сервера, который остаётся в проде надолго, стоит завести отдельного sudo-пользователя и сузить root-доступ по SSH через свой drop-in /etc/ssh/sshd_config.d/00-hardening.conf - до ключа (PermitRootLogin prohibit-password) или выключить вовсе (no), с проверкой sshd -t / sshd -T перед reload.

Что дальше

Если попутно нужно поменять свой пароль, пароль другого пользователя или пароль root - в статье про смену пароля в Ubuntu разобраны все три сценария отдельно. Для подключения к серверу по SSH с macOS или Linux с нуля - в базе знаний есть отдельная инструкция про SSH с macOS и Linux. Если вместо проблем с root у вас команда вообще не находится - смотрите разбор command not found в Ubuntu. А полный список типичных проблем на свежем Linux-сервере собран в материале частые проблемы Linux-сервера.