Керування обліковими записами в Linux – це базова механіка адміністрування, без якої не працюють ні права доступу, ні ізоляція сервісів, ні безпечна робота через sudo. Далі – щільний практичний розбір: як система ідентифікує користувача, де лежать облікові дані, як створювати, змінювати, блокувати й видаляти користувачів, а також як не зламати доступ собі чи сервісу.
Як Linux ідентифікує користувача
Username і UID – це не одне й те саме
Ядро Linux працює з числами. Для користувача це UID, для групи – GID. Ім’я облікового запису – лише зручний псевдонім для людини та утиліт на кшталт ls, ps чи id.
Звідси випливає важливий наслідок. Якщо видалити користувача і створити нового з тим самим ім’ям, але з іншим UID, старі файли не стануть його файлами. Права прив’язані саме до UID, а не до текстового імені.
Типовий набір атрибутів користувача такий:
-
ім’я входу;
-
UID;
-
первинна група через GID;
-
домашній каталог;
-
login shell;
-
поле GECOS з коментарем.
Швидка діагностика на сервері
На незнайомій машині спочатку варто подивитися, хто ви, які у вас групи й що система знає про акаунт.
id id -u id -g whoami getent passwd deployer getent group docker
Для систем з LDAP, NIS або іншими NSS-джерелами краще використовувати саме getent, а не лізти одразу в /etc/passwd. Так картина буде коректною і на локальній машині, і в корпоративному середовищі.
Як працює доступ до файлів і чому тут важливі користувачі та групи
Кожен файл, каталог, сокет або пристрій має власника і групу. Це метадані inode. Коли процес звертається до об’єкта, ядро перевіряє UID і GID процесу та порівнює їх з власником і групою файлу.
ls -la /var/log/nginx/
Логіка перевірки прав проста:
процес (UID/GID) -> owner? -> group? -> others
Перевірка йде зліва направо і зупиняється на першому збігу. Якщо UID процесу дорівнює owner файла, права групи вже не аналізуються. Це часто плутають під час налагодження доступу.
Які бувають користувачі в Linux
У Linux є кілька практичних категорій облікових записів.
-
UID 0 – root.
-
Нижні діапазони UID – системні користувачі для сервісів і демонів.
-
UID від типового порогу 1000 і вище – звичайні користувачі.
-
Окремо часто трапляється nobody як обліковий запис з мінімальною довірою.
Точні межі задаються в /etc/login.defs. Саме там система бере значення для UID_MIN, UID_MAX, SYS_UID_MIN, SYS_UID_MAX та пов’язаних параметрів.
UID_MIN 1000 UID_MAX 60000 SYS_UID_MIN 201 SYS_UID_MAX 999 CREATE_HOME yes PASS_MIN_LEN 8
У більшості дистрибутивів системні користувачі живуть нижче порогу звичайних користувачів. Але покладатися на це без перевірки не варто. Якщо переносите акаунти між хостами або робите автоматику, дивіться на конкретні налаштування системи.
Системні користувачі і nologin
Сервіси на кшталт nginx, redis чи postgres часто працюють від окремого системного користувача. Для таких акаунтів звичайно вказують /usr/sbin/nologin або /bin/false як shell. Це блокує інтерактивний вхід.
awk -F: '$3 < 1000 && $3 > 0 {print $1, $3, $7}' /etc/passwd
Іноді трапляються винятки. Наприклад, окремим сервісам можуть залишити shell, якщо це потрібно для сервісних операцій. Тому дивіться не на загальне правило, а на конкретний запис.
Root і nobody – дві крайні точки
root з UID 0 має максимальні повноваження. Компрометація root – це фактично компрометація всієї системи.
nobody, навпаки, використовують як контекст з мінімальними привілеями. Але тут є нюанс: ім’я і UID можуть відрізнятися залежно від системи. Іноді це nobody, іноді nfsnobody, іноді значення UID інше. На продакшені це потрібно перевіряти, а не вгадувати.
Навіщо потрібні групи
Групи в Linux – це механізм колективного доступу. Замість роздачі прав кожному користувачу окремо, простіше надати права групі й додати до неї потрібних людей або сервісні акаунти.
Класичний приклад – група docker. Якщо користувач входить до неї, він може працювати з сокетом Docker без sudo. І саме тому додавання в такі групи потрібно робити обережно: це вже не просто зручність, а делегування реальних привілеїв.
Первинна і додаткові групи
У користувача є одна первинна група і довільна кількість додаткових.
-
Первинна група зберігається в /etc/passwd.
-
Додаткові групи зберігаються в /etc/group.
Первинна група зазвичай стає GID нових файлів, які створює користувач. Додаткові групи потрібні для розширення доступу.
groups groups maria id getent group docker
Де зберігаються облікові записи
/etc/passwd
Це реєстр користувачів, доступний на читання всім. Парольного хеша тут немає. У полі пароля стоїть x, а сам хеш лежить в іншому файлі.
deployer:x:1001:1001:Deploy Bot,,:/home/deployer:/bin/bash
Поля тут такі:
-
ім’я користувача;
-
маркер x замість пароля;
-
UID;
-
GID первинної групи;
-
GECOS;
-
домашній каталог;
-
login shell.
Колись хеші паролів зберігали просто в /etc/passwd. Це виявилося поганою ідеєю, бо файл повинен читатися всіма, а отже будь-хто міг забрати хеші і спокійно брутфорсити їх офлайн. Тому хеші винесли в shadow.
/etc/shadow
У /etc/shadow лежать хеші паролів і параметри старіння пароля. Доступ до цього файлу має лише root або відповідні системні механізми.
deployer:$6$rounds=5000$xPwF...$kE9...hash...:19800:0:99999:7:::
Тут є кілька важливих деталей.
-
Префікс на кшталт $6$ вказує на схему хешування.
-
Зберігається дата останньої зміни пароля.
-
Можуть задаватися мінімальний і максимальний вік пароля.
-
Символи ! або * зазвичай означають блокування пароля.
Формат хешу залежить від дистрибутива й налаштувань PAM. У різних системах можна побачити різні маркери алгоритмів. Тут не варто переносити очікування з одного дистрибутива на інший без перевірки.
/etc/group і /etc/gshadow
/etc/group містить назви груп, GID і список користувачів у додаткових групах.
docker:x:998:deployer,ci-bot
/etc/gshadow – менш помітний файл. У ньому зберігаються службові дані для груп, включно з хешами групових паролів і адміністраторами груп. На практиці він потрібен рідко, але про нього краще пам’ятати.
Редагувати ці файли напряму – погана ідея
Не треба правити /etc/passwd, /etc/shadow чи /etc/group через звичайний nano або vim без блокувань. При паралельних змінах легко отримати гонку та пошкоджений файл.
vipw vipw -s vigr vigr -s pwck grpck
vipw і vigr дають блокування та базову валідацію. А pwck і grpck допомагають перевірити цілісність після ручних змін.
Покрокове створення користувача в Linux
Коли потрібне керування обліковими записами для нового адміністратора, девелопера або сервісу, робоча послідовність така.
-
Створити користувача з потрібним home і shell.
-
Додати в необхідні групи.
-
Задати пароль або налаштувати інший спосіб входу.
-
Перевірити запис у системі та членство в групах.
-
За потреби примусити зміну пароля при першому вході.
useradd -m -s /bin/bash ivan passwd ivan usermod -aG sudo,docker ivan id ivan passwd -e ivan
Якщо створюється сервісний акаунт, логіка інша. Йому часто не потрібен інтерактивний shell, а home може бути службовим каталогом.
useradd -r -m -d /var/lib/prometheus -s /usr/sbin/nologin prometheus
Для CI або ботів часто обирають системного користувача без login shell.
useradd -r -s /usr/sbin/nologin -c "CI Bot" ci-bot
Що робить useradd під капотом
Якщо викликається useradd -m, система не просто додає рядок у passwd.
-
Створюється запис у /etc/passwd.
-
Створюється запис у /etc/shadow.
-
Зазвичай створюється однойменна первинна група.
-
Створюється домашній каталог.
-
У home копіюється шаблон з /etc/skel.
-
На каталог виставляється коректний owner.
Це важливо розуміти, коли ви налагоджуєте нестандартний базовий каталог, власний skeleton або централізовану політику shell.
Пароль, шаблони і типові дефолти
Установка пароля
Найпростіший варіант – інтерактивний passwd. Для автоматизації часто використовують chpasswd.
passwd ivan
echo 'ivan:secretpass' | chpasswd
NEW_PASS=$(openssl rand -base64 16)
echo "ivan:${NEW_PASS}" | chpasswd
passwd -e ivan
Остання команда примушує змінити пароль під час першого входу. Для тимчасових акаунтів або ручної видачі доступу це нормальна практика.
/etc/skel
Коли створюється користувач з home, система копіює в нього файли з /etc/skel. Це зручна точка для стандартизації середовища.
ls -la /etc/skel/
cat > /etc/skel/.gitconfig <<'EOF'
[core]
autocrlf = input
editor = vim
[pull]
rebase = true
EOF
Все, що ви покладете в /etc/skel, автоматично опиниться в нових домашніх каталогах. Але вже створені користувачі цих змін не отримають.
Глобальні налаштування
Кілька системних файлів впливають на те, як саме створюються користувачі і як виглядає їхня сесія.
-
/etc/default/useradd – дефолти для useradd;
-
/etc/login.defs – діапазони UID, політика паролів, umask;
-
/etc/profile і /etc/profile.d/*.sh – глобальне середовище для login shell;
-
/etc/bash.bashrc – глобальний bashrc у Debian та Ubuntu.
umask і права за замовчуванням
umask визначає, які біти прав будуть відняті під час створення нових файлів і каталогів. Це не просте арифметичне віднімання, а маска виключення.
umask touch test.txt && ls -l test.txt umask 027
Загальна логіка така:
-
для файлів база – 666;
-
для каталогів база – 777.
Наприклад, umask 022 дає 644 для файлів і 755 для каталогів. А umask 027 дає 640 і 750 відповідно.
Це часто ламається в shared-сценаріях. Наприклад, команда очікує спільний доступ до каталогу, а нові файли створюються занадто закритими. Або навпаки, на сервері виявляються каталоги, відкриті ширше, ніж очікувалося.
Глобально umask можуть задавати /etc/login.defs або PAM.
# /etc/login.defs # UMASK 022 # /etc/pam.d/common-session # session optional pam_umask.so umask=002
Як змінювати користувачів без сюрпризів
usermod
Для зміни shell, home, терміну дії акаунта або груп використовують usermod.
usermod -s /bin/zsh ivan usermod -l ivan-petrov ivan usermod -d /home/ivan-petrov -m ivan-petrov usermod -e 2025-12-31 contractor usermod -g developers ivan-petrov usermod -aG docker ivan-petrov
Критичний момент тут один: ключ -G без -a перезаписує список додаткових груп. Саме так люди випадково викидають себе з sudo або з доступу до docker, libvirt чи інших сервісів.
Тобто для додавання в групу треба саме:
usermod -aG group user
а не usermod -G group user.
chsh і /etc/shells
Зміна оболонки може робитися через chsh. Але shell має бути дозволеним у /etc/shells.
chsh chsh -s /bin/fish ivan cat /etc/shells
Тому проста установка нової оболонки ще не означає, що її можна призначити користувачу. Якщо shell не внесений до /etc/shells, команда відмовиться працювати або поведеться не так, як очікуєте.
Блокування і розблокування
Якщо потрібно тимчасово закрити парольний доступ, можна заблокувати пароль.
passwd -l ivan usermod -L ivan passwd -u ivan usermod -U ivan passwd -S ivan
Але тут є підводний камінь: блокування через passwd -l зазвичай блокує саме пароль, а не вхід по SSH-ключу. Якщо потрібно реально зупинити будь-який вхід, доведеться додатково змінити shell на nologin або виставити дату завершення акаунта.
usermod -s /usr/sbin/nologin ivan usermod -e 1 ivan
Як видаляти користувачів і не залишати сміття
Базове видалення робиться через userdel.
userdel ivan userdel -r ivan
Без -r домашній каталог залишиться. З -r він піде разом з поштовими файлами користувача. Якщо в home були дані, їх краще забекапити до видалення.
tar -czf /backup/ivan-$(date +%F).tar.gz /home/ivan userdel -r ivan
Де зазвичай ламається видалення
Є кілька типових проблем.
-
Видаляється home, але залишаються файли з тим самим UID в інших місцях.
-
Користувач досі залогінений, і userdel відмовляється працювати.
-
Пізніше UID перевикористовують, і новий акаунт раптом отримує доступ до старих файлів.
Щоб перевірити сирітські файли, корисно прогнати:
find / -nouser -nogroup -ls 2>/dev/null
А якщо користувач ще має процеси або сесії, спочатку доведеться їх завершити.
pkill -u ivan && userdel -r ivan
У середовищах з shared storage це особливо важливо. Видалення запису з passwd ще не означає, що всі сліди облікового запису зникли.
Керування групами
Створення, перейменування і видалення груп робиться стандартними утилітами.
groupadd developers groupadd -g 5000 infra groupadd -r appservice groupmod -n backend developers groupmod -g 5100 backend groupdel backend
Зміна GID – операція не така невинна, як здається. Файли зі старим GID не будуть автоматично переприв’язані. Вони просто залишаться з числовим значенням, яке вже ні до чого не прив’язане. Це класичний спосіб отримати orphaned group ownership.
Додавання користувача в групи робиться так:
usermod -aG docker ivan usermod -aG docker,sudo,adm maria
Зміни в додаткових групах зазвичай застосовуються лише після нового логіну. Для поточної сесії можна використати нову оболонку з активною групою або перевідкрити login shell.
newgrp docker exec su -l $USER
Перевірка після цього проста:
getent group docker id maria groups maria
su і sudo – різні інструменти для різних задач
su
su перемикає вас на іншого користувача і в класичному сценарії вимагає пароль саме цільового користувача.
su su - su -l root su - maria su -c "whoami; id" - maria
Різниця між su і su – критична. Звичайний su міняє UID, але може лишити старе оточення. su – запускає повний login shell і підтягує середовище цільового користувача.
У дистрибутивах на кшталт Ubuntu root часто заблокований для прямого входу по паролю. У такому випадку логіка через su стає менш корисною, і практичніше використовувати sudo.
sudo
sudo дає точкове підвищення привілеїв. Це кращий варіант для більшості серверних сценаріїв, бо він логований і дозволяє делегувати рівно ті дії, які потрібні.
sudo apt update sudo -i sudo -s sudo -u www-data id sudo -l grep sudo /var/log/auth.log | tail -20
sudo авторизує користувача його власним паролем, а не паролем root. Це зручніше для аудиту і безпечніше з погляду щоденної експлуатації.
Налаштування sudoers
Редагувати sudoers треба тільки через visudo. Будь-яка синтаксична помилка в /etc/sudoers може відрізати вам sudo на системі.
visudo
Приклади правил:
%sudo ALL=(ALL:ALL) ALL deployer ALL=(root) NOPASSWD: /usr/sbin/service nginx restart ci-bot ALL=(root) NOPASSWD: /usr/bin/docker %developers ALL=(ALL) ALL, !/usr/sbin/visudo
Для окремих правил краще використовувати /etc/sudoers.d.
visudo -f /etc/sudoers.d/ci-bot chmod 0440 /etc/sudoers.d/ci-bot
Коли робите таке керування обліковими записами для ботів або CI, не давайте ширші права, ніж треба. NOPASSWD на одну конкретну команду – нормальний варіант. Повний root без причини – ні.
Як перевірити, що все справді працює
Після створення або зміни акаунта варто пройти короткий чек.
-
Подивитися UID і GID через id.
-
Перевірити членство в групах через groups і getent group.
-
Звірити shell і home у getent passwd.
-
Переконатися, що sudo дає саме ті права, які планувалися.
-
Для видалених акаунтів знайти orphaned files.
id username groups username getent passwd username sudo -l find / -nouser -nogroup -ls 2>/dev/null
Якщо користувач щойно доданий у групу і зміни не видно, проблема найчастіше не в groupadd чи usermod, а в тому, що сесія ще стара.
Типові помилки під час роботи з користувачами і групами
-
Плутанина між ім’ям користувача і UID.
-
Редагування системних файлів напряму без vipw і vigr.
-
usermod -G без -a.
-
Очікування, що passwd -l відключить SSH-ключі.
-
Зміна GID без подальшої перевірки файлової системи.
-
Видалення користувача без пошуку orphaned files.
-
Роздача груп на кшталт docker так, ніби це безпечний read-only доступ.
Саме ці речі найчастіше ламають або безпеку, або повсякденну роботу команди.
Коли цього підходу вже замало
Локальні облікові записи в /etc/passwd нормальні для одного сервера, кількох VM у homelab або невеликої інфраструктури. Але коли хостів стає багато, ручне керування перестає бути зручним.
Межа настає в кількох сценаріях:
-
треба централізовано керувати доступом на багатьох серверах;
-
потрібна єдина політика паролів і ротації;
-
з’являються тимчасові доступи для команд і підрядників;
-
потрібен нормальний аудит поза межами локального sudo log.
Тоді вже дивляться в бік LDAP, FreeIPA, AD-інтеграції, PAM-політик, SSH CA або централізованого IAM. Але навіть у такій архітектурі локальна модель Linux нікуди не зникає. UID, GID, групи, shell і sudo все одно лишаються базою.
Практична шпаргалка
Діагностика
id whoami id username groups username getent passwd username getent group groupname passwd -S username last w
Користувачі
useradd -m -s /bin/bash -G sudo user passwd user usermod -aG group user usermod -L user usermod -U user userdel -r user
Групи
groupadd groupname groupmod -n newname oldname groupdel groupname newgrp docker
Безпечне редагування
visudo vipw vipw -s vigr pwck && grpck
У підсумку все зводиться до простого правила: в Linux доступ визначають не назви, а ідентифікатори та групи. Якщо це розуміти, керування користувачами стає передбачуваним. Якщо ні – дрібна зміна на кшталт одного ключа в usermod легко перетворюється на втрату доступу або дірку в безпеці.