Як перемикатися між користувачами в Ubuntu

Будь-який Linux, в тому числі операційна система Ubuntu - це система, яка часто опиняється на перетині інтересів, оскільки один і той же сервер може обслуговувати розробників, адміністраторів, CI/CD-процеси, сервісні акаунти, а іноді і бізнес-користувачів. На робочій станції картина може бути не менш насиченою, з існуванням основного користувача, сервісних облікових записів, тимчасових акаунтів і тестового середовища.

І одним з найчастіших завдань є те, як коректно перемикатися між користувачами в Ubuntu.

Якщо добре подумати, то це питання не про "ввести команду і забути". Це про безпеку, зручність, контроль середовища і чітке розуміння того, хто саме і в якому контексті зараз працює в системі. У цій статті ми спробували дати вам детальний практичний розбір всіх основних способів перемикання між користувачами в Linux, їх відмінностей і підводних каменів при використанні кожного з методів. Кожен інженер або адміністратор зобов'язаний розуміти відмінності цих методів і глибоко розуміти, як вони працюють, щоб не допустити компрометації системи.

 

 

 

 

Навіщо взагалі перемикатися між користувачами

Якщо ви працюєте в Linux не перший день, то базова ідея вам вже знайома: один користувач - одна зона відповідальності. Але на практиці перемикання між користувачами - це не просто формальність і вже тим більше не пережиток старих Unix-традицій.

У сучасних системах, таких як, наприклад, Ubuntu, користувачами є не тільки люди, але і процеси, сервіси, пайплайни автоматизації, контейнери, агенти деплоя і моніторингу і т.д. і т.п.. Кожен з них живе у своєму контексті, зі своїми правами, змінними оточення, домашнім каталогом, ключами доступу та історією команд. І коли цей контекст порушується, то починаються проблеми, які складно діагностувати і ще складніше відтворити.

Неправильний користувач при виконанні тієї чи іншої команди може привести до непомітних помилок в правах доступу, поламаних залежностей, дивної поведінки додатків і вразливостей в безпеці. Особливо часто це проявляється на серверах і VPS, де під однією системою працюють відразу кілька ролей.

Саме тому вміння свідомо перемикатися між користувачами є базовою навичкою не тільки для системних адміністраторів, але і для розробників, DevOps-інженерів і всіх, хто працює з продакшн-системами. Мова йде саме про контроль, передбачуваність і відповідальність, а не про банальну зручність однієї команди в терміналі.

 

Тепер давайте розберемо, навіщо саме це потрібно на практиці і які завдання вирішує коректний розподіл користувачів.

• Розподіл прав доступу між звичайним користувачем і адміністратором;
• Робота з сервісними акаунтами (деплой, CI/CD, cron, systemd);
• Тестування додатків від імені іншого користувача;
• Підтримка multi-user середовища на сервері або VPS;
• Мінімізація ризиків при роботі з чутливими командами.

 

Ubuntu за замовчуванням досить ліберальна в плані sudo-доступу, але саме тому особливо важливо розуміти, що саме ви робите і в якому контексті, а не просто виконувати команди "на автоматі". Така модель зручна для старту і повсякденної роботи, але вона легко притупляє відчуття межі між звичайним користувачем і адміністратором.

Згодом це призводить до того, що команди з підвищеними привілеями виконуються без належного аналізу наслідків, наприклад змінюються власники файлів, створюються артефакти з некоректними правами, порушується ізоляція середовищ тощо. У невеликих системах це може залишитися непомітним, але в серверній або multi-user середовищі такі дрібниці швидко перетворюються на реальні проблеми.

Тому важливо не просто мати sudo-доступ, а свідомо керувати ним, вибираючи відповідний спосіб перемикання в залежності від завдання, а не з звички або зручності.

 

Практичні сценарії, де перемикання є критичним

• Перевірка прав доступу до файлів від імені www-data;
• Запуск міграцій бази даних від імені користувача додатка;
• Діагностика багів, що залежать від змінних оточення;
• Робота на сервері декількома адміністраторами;
• Налагодження проблем, що виникають тільки у конкретного користувача.

 

 

 

 

 

Перемикання користувачів у графічному інтерфейсі Ubuntu

Отже, перейдемо до практики і почнемо з найочевиднішого варіанту - перемикання користувачів через графічний інтерфейс Ubuntu. Цей спосіб знайомий більшості користувачів і найчастіше використовується на персональних комп'ютерах, робочих станціях і ноутбуках, де система працює в інтерактивному режимі.

GUI-перемикання сприймається як щось просте, звичне і від того безпечне, але за зовнішньою наочністю і простотою ховається цілком повноцінний механізм управління сесіями. Кожному користувачеві виділяється власний простір, що полягає в окремому наборі процесів, змінних оточення, конфігураціях робочого столу і правах доступу. З точки зору системи це не спрощений режим, а такі ж ізольовані контексти користувачів, як і при вході через термінал або SSH.

Важливо розуміти заздалегідь, що графічне перемикання - це не спосіб "тимчасово стати іншим користувачем", а створення паралельної сесії користувача. Саме тому цей варіант чудово підходить для локальної роботи, але практично не застосовується в серверному середовищі, де графічна оболонка відсутня і пріоритет віддано термінальному доступу.

 

У стандартному середовищі Ubuntu (GNOME):

1. У правому верхньому куті екрана відкривається системне меню, що об'єднує індикатори мережі, звуку та живлення. Це єдина панель управління сесією і станом системи.
2. У меню вибирається пункт Змінити користувача (Switch User), після чого поточний робочий стіл ховається, а система повертає користувача на екран входу.
3. Поточна сесія користувача не завершується і всі запущені програми, процеси і відкриті файли залишаються активними і продовжують працювати у фоновому режимі.
4. Новий користувач виконує звичайний вхід в систему - з введенням пароля або використанням налаштованого методу аутентифікації.
5. Після входу створюється окрема, повністю ізольована сесія з власним набором процесів, змінних оточення і користувацьких налаштувань.
6. Права доступу не успадковуються, тобто якщо новий користувач не входить до групи sudo, то він не отримає адміністративних прав, навіть якщо попередня сесія ними володіла.
7. У системі одночасно може існувати кілька активних сесій користувачів, між якими можна перемикатися без втрати стану.

Важливо! Конкретні кроки можуть відрізнятися залежно від версії ОС і конкретної збірки.

 

Це паралельні сесії, кожна зі своїми процесами, змінними середовища і робочим столом. Дуже зручно для локальної машини, але майже марне на серверах, де графічного середовища просто немає.

 

 

 

 

 

Команда su - класика Unix

Команда su - це один з найстаріших способів перемикання користувачів в Unix-подібних системах.

За замовчуванням:

• su без параметрів перемикає на root;
• потрібен пароль цільового користувача;
• середовище змінюється частково.

І саме тут починається плутанина.

Якщо використовувати просто su, ви змінюєте користувача, але не повністю змінюєте середовище. Робочий каталог, змінні середовища і PATH можуть залишитися від попереднього користувача. Іноді це зручно, але набагато частіше це є джерелом важко вловимих помилок.

 

Тому на практиці майже завжди використовують login-режим:

su - username # або su --login username 

 

Різниця між su і su --login

Команда	Користувач змінюється	Оточення	Profile-файли	Тип сесії
su	так	частково	ні	неповна
su -	так	повністю	так	login
su --login user	user	повністю	так	login

 

 

 

 

 

Команда sudo su- швидкий, але небезпечний шлях

Якщо su- це класика Unix, то sudo suдійсно можна назвати її темною стороною. Формально команда виглядає нешкідливо, але по суті вона обходить кілька важливих принципів, на яких будується модель безпеки Ubuntu.

З технічної точки зору відбувається наступне:

• ви використовуєте sudo, підтверджуючи, що маєте право на виконання привілейованих команд;
• система видає вам root-права на основі вашого sudo-доступу;
• запускається інтерактивний shell від імені root, всередині якого ви продовжуєте роботу.

При цьому пароль користувача root не потрібен взагалі, а використовується ваш власний sudo-доступ. На Ubuntu серверах root за замовчуванням часто заблокований або не має встановленого пароля, що і робить sudo su таким популярним способом швидко стати root'ом.

Проблема в тому, що такий підхід розмиває межу відповідальності. У момент запуску sudo su ви перестаєте працювати як конкретний користувач і переходите в неявний root-контекст, де стає складно однозначно визначити, хто саме виконував команди і з якими намірами.

І саме тут виникає той самий серйозний нюанс, який часто ігнорують до першого інциденту: sudo su порушує прозорість аудиту і ускладнює контроль над діями в системі.

Чому sudo su ламає аудит

• У логах складно відстежити, хто саме виконував команди;
• Історія команд змішується;
• Втрачається прозорість дій при декількох адміністраторах;
• Ускладнюється розслідування інцидентів.

Саме тому в професійному середовищі sudo su або використовують строго усвідомлено, або не використовують взагалі.

 

 

 

 

Команда sudo -i - правильний спосіб стати root'ом

Якщо вам потрібен саме root-доступ, а не просто тимчасова зміна користувача, то sudo -i по праву вважається золотим стандартом в Ubuntu і більшості сучасних Linux-дистрибутивів.

На відміну від sudo su, ця команда ініціює повноцінну login-сесію користувача root, максимально наближену до реального входу в систему. Завантажуються стандартні конфігураційні файли root-користувача, коректно ініціалізується робоче середовище і формується окрема історія команд.

Чому на практиці це так важливо:

• створюється повноцінна login-сесія root, а не тимчасовий shell без явного контексту;
• середовище і змінні ініціалізуються передбачувано і однаково при кожному вході;
• історія команд залишається чистою і логічно пов'язаною з конкретною сесією;
• системні логи зберігають коректну інформацію про те, хто і коли отримав root-доступ через sudo.

 

Саме тому sudo -i вважається найбільш безпечним і прозорим способом роботи під root, особливо на серверах, VPS і в продакшн-середовищах, де важливі контроль, аудит і відтворюваність дій.

 

 

 

 

Команда sudo -u як точкове виконання від імені іншого користувача

Іноді дійсно немає необхідності "ставати" іншим користувачем і змінювати весь робочий контекст. Набагато частіше потрібно виконати одну конкретну команду від імені потрібного користувача, не виходячи зі своєї сесії і не порушуючи оточення.

Саме для таких завдань існує команда sudo -u, що дозволяє точково запускати процеси від імені іншого користувача. Наприклад:

sudo -u www-data ls /var/www

sudo -u deploy ./deploy.sh

sudo -u postgres psql

 

У всіх цих випадках команда виконується з правами зазначеного користувача, але при цьому ви не переходите в його shell і не створюєте окрему сесію.

Типові сценарії застосування команди sudo -u:

• запуск скриптів від імені сервісного користувача або користувача додатка;
• виконання міграцій і обслуговуючих команд в правильному контексті;
• перевірка доступу до файлів і каталогів без зміни власників;
• робота з сервісами, демонами і їх даними.

 

Ключова перевага sudo -u в тому, що ви залишаєтеся у своїй сесії користувача, оточення системи не ламається, а виконується рівно та дія, яка потрібна. Завдяки цьому sudo -u вважається акуратним і практично хірургічним інструментом і широко використовується DevOps-інженерами та адміністраторами в production-середовищі, де важливо мінімізувати побічні ефекти і зберегти прозорість дій.

 

 

 

 

Перемикання користувачів по SSH

На серверах і VPS все простіше і одночасно суворіше, ніж на десктопах. Тут майже завжди використовується термінальний доступ, а будь-які дії користувача чітко прив'язані до конкретної сесії і контексту.

У SSH-моделі кожен користувач - це окрема точка входу в систему. Перемикання між користувачами означає не зміну ролі всередині вже існуючої сесії, а встановлення нового SSH-з'єднання. Це автоматично створює новий контекст виконання команд з урахуванням власних середовищ, змінних, прав доступу та історії дій.

Саме тому такий підхід вважається еталонним для серверного середовища. Він дійсно:

• Безпечний - кожен користувач аутентифікується окремо;
• Прозорий - в логах чітко видно, хто і коли підключався;
• Ідеальний для продакшну - виключає неявні перемикання контексту.
•  

Рекомендації щодо безпечної роботи з користувачами по SSH

У реальній інфраструктурі зазвичай дотримуються таких принципів:

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

Додатково про налаштування SSH на сервері можна прочитати тут.

Такий підхід може здатися менш зручним, ніж швидке su або sudo su, але саме він забезпечує максимальну керованість і передбачуваність системи. Не випадково багато адміністраторів принципово не використовують su на серверах, віддаючи перевагу окремим SSH-користувачам і ключам.

Це трохи повільніше в повсякденній роботі, але в довгостроковій перспективі - в рази надійніше, особливо в multi-user і production-середовищах.

 

 

 

 

Часті помилки і несподівані ефекти

Навіть досвідчені користувачі Ubuntu регулярно наступають на одні й ті ж граблі, особливо коли робота з користувачами перетворюється на рутину і виконується "на автоматі":

• Робота під root без реальної необхідностіПідвищує ризик випадкових змін в системі і ускладнює пошук джерела проблеми, якщо щось піде не так.
• Плутанина з оточенням при su без login-прапораКоманди виконуються від імені іншого користувача, але зі змінними і шляхами попередньої сесії, що призводить до важкозрозумілої поведінки додатків.
• Забуті фонові процеси іншого користувачаСервіси, скрипти або завдання продовжують працювати після перемикання сесії, споживаючи ресурси і створюючи несподівані побічні ефекти.
• Некоректні права на файли після sudoФайли і каталоги раптово виявляються належними root або сервісному користувачеві, через що додатки перестають нормально працювати.
• Неочевидне змішування контекстівКоманди запускаються в правильний момент, але від неправильного користувача, що особливо критично для деплоя, міграцій і операцій з даними.

Linux не прощає неуважність, але майже завжди чесно показує наслідки. Якщо щось пішло не так, в більшості випадків проблема не в Ubuntu як системі, а в тому, в якому контексті і від імені якого користувача була виконана команда. Саме тому усвідомлене управління користувачами і сесіями - це не проста формальність, а важлива частина надійної роботи з системою.

 

 

 

 

Часто задавані питання

 

Чи можна завжди працювати під root?

Технічно - так, система цього не забороняє. Практично - це вкрай не рекомендується. Постійна робота під root збільшує ризик випадкових помилок, робить незворотними багато дій і суттєво ускладнює пошук причини проблеми. Крім того, при роботі під root втрачається прозорість аудиту: стає складніше зрозуміти, хто і навіщо виконував ті чи інші команди, особливо в multi-user середовищі.

 

Чим sudo -i краще за sudo su?

sudo -i створює повноцінну login-сесію користувача root з коректно ініціалізованим середовищем, правильними змінними і зрозумілим логуванням. На відміну від sudo su, цей спосіб не розмиває контекст і краще вписується в модель аудиту Ubuntu. Саме тому sudo -i вважається кращим варіантом для адміністративних завдань.

 

Чи небезпечно використовувати su?

Сам по собі su не є небезпечним, якщо використовувати його усвідомлено. Рекомендується застосовувати su --login або su -, щоб отримати повноцінну сесію цільового користувача з коректним середовищем. Основна небезпека виникає при використанні su без login-прапора, коли користувач змінюється, а середовище залишається колишнім.

 

Чи потрібно знати пароль root в Ubuntu?

У більшості випадків - ні. За замовчуванням Ubuntu використовує sudo-модель доступу, при якій root-пароль або не встановлений, або заблокований. Управління системою відбувається через sudo, що дозволяє зберігати контроль, аудит і гнучкість прав доступу.

 

Що краще використовувати в продакшні?

Для production-систем оптимальною вважається модель з окремими користувачами, SSH-ключами, мінімально необхідними привілеями і використанням sudo -i тільки тоді, коли дійсно потрібен root-доступ. Такий підхід підвищує безпеку, спрощує аудит і робить поведінку системи більш передбачуваною.

 

Чи можна комбінувати різні способи перемикання?

Так, і на практиці так роблять майже завжди. Наприклад, для повсякденних завдань використовується sudo -u, для адміністративних - sudo -i, а доступ до сервера організований через SSH-користувачів. Головне - розуміти, в якому контексті і навіщо застосовується кожен спосіб.

 

Коли графічне перемикання користувачів - це погана ідея?

Графічне перемикання не підходить для серверів, VPS і будь-яких production-середовищ без GUI. Крім того, воно не замінює адміністративні інструменти і не дає додаткових привілеїв. Це зручний механізм для локальної роботи, але не для управління системою.

 

 

 

 

Висновки

Отже, перемикання між користувачами в Ubuntu - це не просто набір команд або зручний прийом для повсякденної роботи, а відображення базових принципів Linux, таких як чіткий розподіл ролей, мінімально необхідні привілеї та усвідомлений контроль над контекстом виконання команд.

І чим глибше ви занурюєтеся в роботу з системою, будь то адміністрування серверів, DevOps-практики, розробка додатків або експлуатація продакшн-інфраструктури, тим важливіше в кожен момент розуміти, від імені якого користувача ви дієте і з яким оточенням. Помилки тут рідко виглядають критичними відразу, але саме вони найчастіше стають причиною важкозрозумілих збоїв і проблем з безпекою.