Встановіть пароль sudo інакше, ніж пароль для входу

Як привілейований користувач, я намагаюся встановити sudoпароль іншому, ніж той, який використовується при вході в систему.

Я провів деякі дослідження, але не знайшов відповіді. Чи sudoпідтримує таку конфігурацію?

Якщо ви коли-небудь втратите свій пароль, ви втратите все. Хтось міг увійти та просувати себе rootтим самим паролем.

sudoє можливість запитувати rootпароль замість викликаного пароля користувача, ( rootpw), але rootпароль спільного доступу , безумовно, не є варіантом, тому ми встановили sudo.

Я це робив config 2FAу минулому, він працював чудово, але також перемагає призначення автоматизації. Наприклад, якщо ви хочете виконати привілейовану команду на дюжині серверів із expectсценарієм, додавання 2FAне дозволяє вам це робити.

Найближче рішення, яке я знайшов, - це дозволити приватний ключ SSH та налаштувати пропускну фразу за допомогою ключа, який відрізняється від sudoпароля (логін). Але це не зручно, оскільки в надзвичайній ситуації ви не можете увійти з ПК, де немає цього ключа.

Якщо ви хочете запитати корінний пароль, на відміну від пароля користувача, є варіанти, які ви можете ввести /etc/sudoers. rootpwзокрема змусить запросити пароль для кореня. Є runaspwі targetpwяк; див. детальну інформацію про сторінку "sudoers (5)".

Крім цього, sudo робить аутентифікацію (як і все інше) через PAM. PAM підтримує конфігурацію програми. Конфігурація Sudo знаходиться в (принаймні, в моїй системі Debian) /etc/pam.d/sudoі виглядає так:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

Іншими словами, за замовчуванням він автентифікує, як і все, що в системі. Ви можете змінити цей @include common-authрядок, і PAM (і, таким чином, sudo) використовувати альтернативне джерело паролів. Рядки, коментовані без коментування, у загальному auth виглядають приблизно так (за замовчуванням це буде інакше, якщо ви використовуєте, наприклад, LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Ви можете використовувати, наприклад, pam_userdb.soзамість pam_unix.so, а також зберігати альтернативні паролі в базі даних Berkeley DB.

приклад

Я створив каталог /var/local/sudopass, власника / групу root:shadow, режим 2750. Всередині нього я пішов вперед і створив файл бази даних паролів за допомогою db5.1_load(яка є версією Берклі БД, що використовується в Debian Wheezy):

# umask 0027
# db5.1_load -h / var / local / sudopass -t хеш -T passwd.db
антоній
WMaEFvCFEFplI
^D

Цей хеш був створений за mkpasswd -m desдопомогою пароля "пароль". Дуже високобезпечно! (На жаль, схоже, пам_userdb не підтримує нічого кращого, ніж древнє crypt(3)хешування).

Тепер відредагуйте /etc/pam.d/sudoта видаліть @include common-authрядок, а замість цього поставте:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Зауважте, що pam_userdb додає .dbрозширення до переданої бази даних, тому потрібно залишити .dbвимкнено.

За словами dannysauer у коментарі , можливо, вам доведеться зробити таку саму редакцію/etc/pam.d/sudo-i .

Тепер для sudo я повинен використовувати passwordзамість реального пароля вхід:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit працював'
[sudo] пароль для антоні: passwordRETURN

це спрацювало

Для Redhat / Centos вимогу можна досягти, виконавши наступні кроки:

Створіть користувацького користувача та пройдіть:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Відредагуйте файл sudo pam.d так, щоб він виглядав так:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Я все ще шукаю спосіб конфігурації, так що лише певний користувач / група повинна бути автентичною за допомогою цього користувальницького методу, інші ще можуть бути автентичними звичайним методом auth системи. Хтось може дати мені поради?

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

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

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

Якщо хтось може отримати ваш ssh пароль, він, ймовірно, також може отримати альтернативний пароль sudo, тому вам краще вкладати час для того, щоб зробити ваші зв’язки більш безпечними, ніж витрачати час, просто ускладнюючи речі лише для ілюзії більшої безпеки.

У мене немає негайного доступу до системи, де я можу перевірити це і опрацювати деталі, але у мене є ідея:

• (Припустимо, ваш звичайний обліковий запис для входу є shau.)
• Створіть другу обліковий запис: shau2. (Я не впевнений, чи бажаєте ви мати такий самий UID, як shau).
• Налаштуйте shau2права доступу до NOPASSWD.
• Налаштуйте псевдонім або сценарій оболонки для виконання su shau2 -c sudo "$@". Тут слід запитати shau2пароль. Якщо це введено правильно, воно буде працювати sudoяк shau2 (що не повинно запитувати пароль).
• Видаліть shauпривілеї sudo.

На жаль, вам доведеться повторити це для кожного користувача, який має привілеї sudo.

Дякую @ Shâu Shắc за відповідь ! Це рішення також працює для LinuxMint 17.1 Cinnamon 32bit (я встановив лише db-utilпакет для запуску db_load).

Але я дуже плутаю отриманий passwd.dbфайл. Я зробив те саме, що і у вашій відповіді (але використовувані Девід і Джонс , вони виглядають більш привабливо):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Але введені облікові дані зберігаються у хеш-файлі як звичайний текст:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Ви також можете бачити Девід і Джонс через mcedit :

Так, можна обмежити дозволи /usr/local/etc/passwd.db. Але як би там не було, ім’я користувача та пароль, які зберігаються як звичайний текст, погані.

Навіть з окремим паролем sudo є деякі потенційні отвори в безпеці (за замовчуванням настройки дистрибутива). Таким чином, окремий пароль не застосовується для su (тому можна запустити кореневу сесію за допомогою suта входу пароля). Також окремий пароль не дотримується Policy Kit (можна запустити Synaptic за допомогою synaptic-pkexecта входу пароля. Потім видаліть пакети ...). Ці проблеми можна усунути додатковою настройкою файлів конфігурації.

Взагалі, схоже, що безпечний окремий пароль sudo може бути досягнутий лише за допомогою спеціального модуля PAM (можливо, такий модуль буде порівнювати пароль та зчитуваний хеш SHA-512 з файлу) або функціональність SELinux.

PS: вибачте, це повинен бути коментар. Але це відповідає як через текст тексту. Спасибі за розуміння.