Установите пароль sudo иначе, чем логин

Как привилегированный пользователь, я пытаюсь установить sudoпароль для другого, чем тот, который используется при входе в систему.

Я провел некоторое исследование, но не нашел ответа. sudoПоддерживает ли такую ​​конфигурацию?

Если вы когда-нибудь потеряете свой пароль, вы потеряете все. Кто-то может войти и рекламировать себя rootс тем же паролем.

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

Я делал это config 2FAв прошлом, это прекрасно работало, но также побеждало цель автоматизации. Например, если вы хотите выполнить привилегированную команду на дюжине серверов со expectскриптом, добавление 2FAне позволит вам сделать это.

Самое близкое решение, которое я нашел, - разрешить только закрытый ключ SSH и установить пароль с ключом, который отличается от sudoпароля (логина). Тем не менее, это не удобно, потому что в чрезвычайной ситуации вы не можете войти в систему с ПК, где у него нет этого ключа.

Если вы хотите запросить пароль root, в отличие от пароля пользователя, есть варианты, которые вы можете ввести /etc/sudoers. rootpwв частности заставит его запросить пароль root. Есть runaspwи targetpwтак же; см. man-страницу 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) использовать альтернативный источник пароля. Некомментированные строки в common-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(это версия Berkeley DB, используемая в Debian Wheezy):

# umask 0027
# db5.1_load -h / var / local / sudopass -t хэш -T passwd.db
Энтони
WMaEFvCFEFplI
^D

Этот хэш был создан с mkpasswd -m desиспользованием пароля «пароль». Очень надежно! (К сожалению, pam_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расширение к переданной базе данных, поэтому вы должны оставить .dboff.

Согласно dannysauer в комментарии , вам, возможно, придется сделать то же самое редактирование /etc/pam.d/sudo-i.

Теперь, чтобы использовать sudo, я должен использовать passwordвместо своего реального пароля для входа в систему:

Энтони @ Судотест: ~ $ Судо -К
anthony @ sudotest: ~ $ sudo echo -e '\ nit works'
[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

Я все еще ищу способ настройки, так что этот пользовательский метод должен быть авторизован только для определенного пользователя / группы, другие могут быть авторизованы обычным методом system-auth. Кто-нибудь может дать мне несколько советов?

Я не думаю, что sudo поддерживает такую ​​настройку. Цель запроса пароля sudo состоит в том, чтобы гарантировать, что лицо, выполняющее команду sudo, является тем же лицом, которое вошло в систему, и самый простой способ сделать это - запросить вошедшего в систему пользователя для повторной аутентификации.

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

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

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

У меня нет немедленного доступа к системе, где я могу проверить это и проработать детали, но у меня есть идея:

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

К сожалению, вам придется повторить это для каждого пользователя, имеющего привилегии sudo.

Спасибо @ Shâu Shắc за ответ ! Это решение также работает для 32-битной LinuxMint 17.1 Cinnamon (я только установил 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и пароль для входа). Также отдельный пароль не уважается Kit политики (можно запустить Synaptic , используя synaptic-pkexecи Логин пароль. Затем удалите пакеты ...). Эти проблемы могут быть устранены путем дополнительной настройки файлов конфигурации.

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

PS: извините, это должен быть комментарий. Но это идет как ответ из-за текстового формата. Спасибо за понимание.