Набор sudo пароль по-другому по сравнению с входом в систему один

Для 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

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

Я не думаю, что 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 за ответ ! Это решение также работает для LinuxMint 17.1 Cinnamon 32bit (я установил только пакет db-util для запуска db_load ).

Но меня очень смущает получившийся файл passwd.db . Я сделал то же самое, что и в вашем ответе (но использовал david и jones , они выглядят более привлекательно):

# 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 / локальный / etc / passwd.db . Но в любом случае имя пользователя и пароль, хранящиеся в виде простого текста, - это плохо.

Даже с отдельным паролем sudo есть некоторые потенциальные дыры в безопасности (по умолчанию установка дистрибутива). Таким образом, отдельный пароль не применяется для su (поэтому можно запустить корневой сеанс, используя su и пароль для входа). Также отдельный пароль не соблюдается Policy Kit (можно запустить Synaptic , используя synaptic-pkexec и пароль для входа. Затем удалите пакеты ...). Эти проблемы могут быть устранены дополнительной настройкой файлов конфигурации.

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

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