useradd проти adduser: Технічні відмінності, випадки використання та коли використовувати кожну з них

`useradd` — це низькорівнева бінарна утиліта, доступна практично в кожному дистрибутиві Linux, яка створює облікові записи користувачів шляхом безпосереднього запису до `/etc/passwd`, `/etc/shadow` та `/etc/group`. `adduser` — це скрипт-обгортка вищого рівня — зазвичай написаний на Perl у системах на основі Debian — який викликає `useradd` внутрішньо, автоматизуючи створення домашнього каталогу, заповнення файлів-шаблонів, запит пароля та збір полів GECOS. Практична різниця полягає не лише в зручності використання: вибір неправильного інструменту в автоматизованому конвеєрі підготовки або в системі, що не є Debian, може непомітно створити неповні облікові записи користувачів.

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

Що насправді робить useradd під капотом

`useradd` є частиною пакету shadow-utils (іноді називається `passwd` у старіших дистрибутивах). При виклику він виконує серію атомарних операцій:

1. Зчитує `/etc/login.defs` для визначення діапазонів UID за замовчуванням, політик старіння паролів та чи створювати домашній каталог за замовчуванням.
2. Зчитує `/etc/default/useradd` для отримання оболонки за замовчуванням, шляху до каталогу-шаблону та поведінки груп.
3. Записує новий запис до `/etc/passwd` та `/etc/shadow`.
4. За потреби створює домашній каталог і копіює файли з `/etc/skel`, якщо явно передано `-m`.
5. За потреби створює приватну групу, що відповідає імені користувача, якщо `USERGROUPS_ENAB` встановлено в `yes` у `/etc/login.defs`.

Критичний момент, який багато посібників упускають: у дистрибутивах на основі Red Hat (RHEL, CentOS, Rocky Linux, AlmaLinux) `useradd` створює домашній каталог за замовчуванням, оскільки `/etc/login.defs` встановлює `CREATE_HOME yes`. У Debian та Ubuntu цього не відбувається — прапорець `-m` є обов’язковим, якщо ви не змінюєте `/etc/default/useradd`. Ця поведінкова асиметрія є частим джерелом плутанини, коли адміністратори переходять між сімействами дистрибутивів.

Ключові прапорці та їхня поведінка

Практичний приклад useradd з повними параметрами

“`bash

useradd

-m

-d /srv/appuser

-s /bin/bash

-u 1500

-g developers

-G sudo,docker

-e 2025-12-31

-c "Application Service Account"

appuser

passwd appuser

“`

Пароль не встановлюється до виклику `passwd`. До того часу обліковий запис існує, але заблокований — запис у shadow містить `!` як хеш пароля, що запобігає входу через автентифікацію за паролем. Однак вхід за допомогою SSH-ключа не залежить від цього стану.

Що насправді робить adduser під капотом

У Debian та Ubuntu `adduser` — це скрипт Perl, розташований за адресою `/usr/sbin/adduser`. Він зчитує власну конфігурацію з `/etc/adduser.conf` — окремого файлу від `/etc/login.defs` — а потім викликає `useradd` з відповідними прапорцями на основі цієї конфігурації та введення користувача.

Скрипт виконує додаткові кроки, яких `useradd` сам по собі не виконує:

• Інтерактивно запитує пароль і підтверджує його повторним введенням.
• Збирає поля GECOS (повне ім’я, номер кімнати, робочий телефон, домашній телефон, інше) через керовані підказки.
• Автоматично копіює файли-шаблони з `/etc/skel` без необхідності вказувати `-m`.
• Встановлює правильне право власності та дозволи на домашній каталог.
• За потреби додає користувача до додаткових груп, визначених у `/etc/adduser.conf`.

У системах на основі Red Hat `adduser` зазвичай є символічним посиланням на `useradd`, тобто поводиться ідентично до низькорівневого бінарного файлу — без інтерактивної обгортки. Це найважливіша проблема переносимості при написанні скриптів для різних дистрибутивів.

Файл конфігурації adduser: /etc/adduser.conf

Ключові директиви у `/etc/adduser.conf`, що впливають на поведінку:

“`

DSHELL=/bin/bash # Default shell

DHOME=/home # Parent directory for home directories

GROUPHOMES=no # Whether to create group-named subdirectories

LETTERHOMES=no # Whether to use first-letter subdirectories

USERGROUPS=yes # Create a group with the same name as the user

USERS_GID=100 # Default GID if USERGROUPS=no

DIR_MODE=0755 # Permissions on new home directories

SETGID_HOME=no

QUOTAUSER=""

SKEL=/etc/skel

SKEL_IGNORE_REGEX="dpkg-(old|new|dist|tmp)"

“`

Змінення цього файлу дозволяє стандартизувати створення користувачів на всьому парку серверів Debian/Ubuntu без необхідності щоразу передавати прапорці.

Практичний приклад adduser

“`bash

adduser customuser

“`

Інтерактивний сеанс виглядає так:

“`

Adding user 'customuser' …

Adding new group 'customuser' (1001) …

Adding new user 'customuser' (1001) with group 'customuser' …

Creating home directory '/home/customuser' …

Copying files from '/etc/skel' …

New password:

Retype new password:

passwd: password updated successfully

Changing the user information for customuser

Enter the new value, or press ENTER for the default

Full Name []: Jane Smith

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] Y

“`

Щоб додати існуючого користувача до групи неінтерактивно за допомогою `adduser`:

“`bash

adduser customuser sudo

“`

Це помітна особливість: `adduser` також слугує інструментом управління членством у групах, що `useradd` не відтворює однією командою.

Порівняння пліч-о-пліч

Коли використовувати useradd

Автоматизація та інфраструктура як код

`useradd` є правильним вибором у будь-якому неінтерактивному контексті: плейбуки Ansible, провайдери Terraform, інструкції Docker `RUN`, скрипти cloud-init та конвеєри CI/CD. Він забезпечує детермінований вивід без залежності від stdin.

“`bash

Ansible task equivalent

useradd -m -s /bin/bash -G sudo -c "Deploy User" deployuser

echo "deployuser:$(openssl passwd -6 'securepassword')" | chpasswd

“`

Переносимість між дистрибутивами

Будь-який shell-скрипт, призначений для роботи як на системах на основі Debian, так і на системах на основі RHEL, повинен використовувати `useradd`. Покладання на поведінку `adduser` призведе до непомітних збоїв або неочікуваної поведінки на CentOS, Fedora, Rocky Linux або Alpine Linux.

Системні облікові записи та облікові записи служб

Створення заблокованих облікових записів служб без оболонки входу для демонів є спеціалізацією `useradd`:

“`bash

useradd -r -s /usr/sbin/nologin -d /var/lib/myservice -m myservice

“`

Прапорець `-r` призначає UID нижче порогу системного облікового запису, сигналізує адміністраторам, що це не обліковий запис людини, і є стандартним шаблоном для розгортання додатків у середовищах VPS Хостингу, де критична ізоляція служб.

Точний контроль UID/GID

У середовищах NFS, оркестрації контейнерів або при синхронізації баз даних користувачів між кількома серверами узгоджені UID та GID є обов’язковими. `useradd -u 1500 -g 1500` гарантує це; `adduser` не пропонує такого детермінованого контролю без значної конфігурації.

Коли використовувати adduser

Інтерактивне налаштування сервера

При ручному підготовці нового Виділеного сервера та додаванні перших кількох облікових записів людей `adduser` знижує ризик неповного налаштування. Керовані підказки роблять практично неможливим пропустити крок встановлення пароля.

Середовища Debian/Ubuntu зі стандартними налаштуваннями за замовчуванням

Якщо вся ваша інфраструктура працює на Debian або Ubuntu і ви створюєте стандартних користувачів з домашніми каталогами, `adduser` дає правильні результати швидше з меншою кількістю прапорців для запам’ятовування.

Управління групами після створення

Синтаксис `adduser username groupname` для додавання існуючого користувача до існуючої групи є чистішим, ніж `usermod -aG groupname username`, хоча обидва варіанти є дійсними.

Навчання молодших адміністраторів

Інтерактивна природа `adduser` робить його кращим навчальним інструментом. Він виводить на перший план поля, що мають значення (пароль, повне ім’я), і приховує складність діапазонів UID та каталогів-шаблонів, поки адміністратор не буде готовий їх вивчити.

Критичні граничні випадки та підводні камені

Пастка відсутнього домашнього каталогу

У Debian/Ubuntu запуск `useradd username` без `-m` створює користувача, але не домашній каталог. Користувач може увійти (після встановлення пароля), але `$HOME` не існуватиме, що спричинить збої в будь-якому додатку, який записує до домашнього каталогу при першому вході — включаючи `.bash_history`, `.ssh/authorized_keys` та багато каталогів конфігурації додатків.

“`bash

Verify home directory existence after creation

ls -la /home/newuser || echo "Home directory missing — run: mkhomedir_helper newuser"

“`

Блокування файлу shadow

Обидві команди блокують `/etc/shadow` під час запису. У скриптах підготовки з високим паралелізмом, що одночасно створюють десятки користувачів, це спричиняє стани гонки. Використовуйте чергу або послідовне виконання при масовому створенні користувачів.

Колізія UID у контейнеризованих середовищах

При розгортанні додатків на VPS з cPanel або інших середовищах з панелями керування, сама панель керує розподілом UID. Запуск `useradd` вручну з жорстко закодованим UID може зіткнутися з UID, призначеними панеллю, що спричинить помилки дозволів для кількох облікових записів. Завжди перевіряйте `getent passwd | awk -F: '{print $3}' | sort -n` перед ручним вказанням UID.

adduser –disabled-password для скриптів

Якщо вам необхідно використовувати `adduser` у скрипті (наприклад, щоб скористатися його налаштуваннями `/etc/adduser.conf` за замовчуванням), придушіть інтерактивні підказки:

“`bash

adduser –disabled-password –gecos "Automated User,,," scriptuser

echo "scriptuser:$(openssl passwd -6 'password')" | chpasswd

“`

Прапорець `–gecos` приймає рядок через кому, що відповідає полям GECOS, усуваючи всі інтерактивні підказки.

Інтеграція PAM та NSS

Ні `useradd`, ні `adduser` не налаштовують модулі PAM або записи NSS (Name Service Switch) для LDAP, Active Directory або інших централізованих систем автентифікації. На серверах, інтегрованих з `sssd` або `winbind`, локальне створення користувачів будь-якою з команд створює облікові записи, які можуть конфліктувати з обліковими записами служби каталогів або бути замінені ними. Перевіряйте `/etc/nsswitch.conf` перед створенням локальних користувачів на системах, приєднаних до домену.

Налаштування файлів-шаблонів

Обидві команди за замовчуванням копіюють з `/etc/skel`. Для команд, що керують середовищами Спільного веб-хостингу, де кожен користувач потребує попередньо налаштованого `.bashrc`, `.vimrc` або конфігурації SSH, правильним підходом є заповнення `/etc/skel` перед запуском будь-якої з команд — а не змінення файлів після створення облікового запису.

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

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

“`bash

Check passwd entry

getent passwd newuser

Check shadow entry (requires root)

getent shadow newuser

Check group memberships

groups newuser

id newuser

Verify home directory and permissions

ls -la /home/newuser

Test login shell

su -s /bin/bash – newuser -c "echo login successful"

“`

Змінення та видалення користувачів

`useradd` та `adduser` лише створюють облікові записи. Управління після створення використовує різні команди:

• `usermod` — Змінення існуючих атрибутів користувача (оболонка, групи, домашній каталог, термін дії).
• `userdel` / `deluser` — Видалення облікових записів. `deluser –remove-home username` у Debian також видаляє домашній каталог та поштову скриньку.
• `passwd` — Встановлення або зміна паролів, блокування/розблокування облікових записів.
• `chage` — Управління політиками старіння та закінчення терміну дії паролів.

“`bash

Lock an account without deleting it

usermod -L username

Unlock

usermod -U username

Force password change on next login

chage -d 0 username

“`

Практична матриця рішень

Використовуйте цей контрольний список для вибору правильної команди:

• Скрипт виконується в системі, що не є Debian, або потребує переносимості? Використовуйте `useradd`.
• Це автоматизоване, неінтерактивне середовище (CI/CD, Ansible, Docker)? Використовуйте `useradd`.
• Вам потрібен конкретний UID/GID для узгодженості NFS або контейнерів? Використовуйте `useradd -u -g`.
• Ви створюєте системний обліковий запис або обліковий запис служби без оболонки входу? Використовуйте `useradd -r -s /usr/sbin/nologin`.
• Ви в Debian/Ubuntu, створюєте стандартний обліковий запис людини інтерактивно? Використовуйте `adduser`.
• Хочете додати існуючого користувача до групи за допомогою чистого однорядкового рядка? Використовуйте `adduser username groupname`.
• Ви пишете документацію або навчаєте молодших співробітників на Debian? Використовуйте `adduser`.
• Вам потрібно неінтерактивно налаштувати розташування домашнього каталогу, термін дії або оболонку у великому масштабі? Використовуйте `useradd` з явними прапорцями.

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

—

FAQ

Чи створює useradd домашній каталог за замовчуванням?

Це залежить від дистрибутива. У системах на основі Red Hat (RHEL, CentOS, Rocky Linux) `CREATE_HOME yes` у `/etc/login.defs` змушує `useradd` автоматично створювати домашній каталог. У Debian та Ubuntu домашній каталог не створюється, якщо явно не передати прапорець `-m`.

Чи доступний adduser на CentOS або Rocky Linux?

У дистрибутивах на основі RHEL `adduser` є символічним посиланням на `useradd`, а не інтерактивною обгорткою Perl, що є в Debian/Ubuntu. Запуск `adduser username` на CentOS поводиться ідентично до `useradd username` — без підказок, без автоматичного домашнього каталогу за налаштуваннями у стилі Debian.

Як використовувати adduser неінтерактивно у скрипті?

Передайте `–disabled-password` для пропуску запиту пароля та `–gecos ""` для пропуску підказок полів GECOS: `adduser –disabled-password –gecos "" username`. Встановіть пароль після цього за допомогою `echo "username:password" | chpasswd` або передаючи хеш `openssl passwd -6` через pipe.

У чому різниця між /etc/login.defs та /etc/adduser.conf?

`/etc/login.defs` — це загальносистемний файл конфігурації, який зчитується `useradd`, `userdel` та `usermod` — він контролює діапазони UID/GID, налаштування старіння паролів за замовчуванням та поведінку створення домашнього каталогу. `/etc/adduser.conf` зчитується виключно скриптами Perl `adduser` та `deluser` у системах на основі Debian і контролює налаштування вищого рівня за замовчуванням, такі як оболонка за замовчуванням, батьківський шлях домашнього каталогу та каталог-шаблон.

Чи можна безпечно змішувати useradd та adduser на одному сервері Debian?

Так. Обидва зрештою записують до одних і тих самих файлів `/etc/passwd`, `/etc/shadow` та `/etc/group`. Облікові записи, створені будь-якою з команд, є неrozрізненними на системному рівні. Єдина практична проблема — це узгодженість: якщо ваша команда використовує `adduser` інтерактивно, а скрипт автоматизації використовує `useradd` без `-m`, у вас можуть опинитися деякі користувачі без домашніх каталогів. Стандартизуйте один підхід для кожного середовища та задокументуйте його.