LINUX.ORG.RU

Проверка валидности указанного пароля root в bash скрипте

 , ,


0

1

Имеется некоторый bash-скрипт, автоматизирующий процесс обновления и конфигурирования некоторого софта на солидной группе удаленных хостов. Все манипуляции выполняются от имени root, соответственно, на всех удаленных хостах и хосте откуда скрипт пускается пароли root одинаковые. Хранение этого пароля в тексте скрипта нежелательно по соображениям безопасности, пароль указывается через read ROOTPASS при запуске. Как проверить что введен правильный пароль root? Запуск возможен от любого юзера. Для не-rootа проблем нет, выполняем любое рутовое действие, через expect подсовываем ROOTPASS и проверяем результат. При запуске от рута это не катит. Пробовал коннектиться по ssh root@localhost - не проходит. Возиться с shadow слишком муторно. Посоветуйте что-нибудь.

Я правильно понимаю, что с авторизацией по ключам есть некие непреодолимые проблемы и поэтому парольный доступ это единственный путь?

zolden ★★★★★
()
Ответ на: комментарий от zolden

Да, по ключам допускается авторизация только для юзеров, к тому же в процессе обновления удаленные хосты самостоятельно качают обновления с сервера, соответственно ключевая авторизация к серверу должна быть и у них, а это крайне нехорошо

tig1818
() автор топика

Все манипуляции выполняются от имени root

Так проверяй root’a, а не пароли

if [ "$EUID" -ne 0 ]; then
    echo "Bye!"
    exit 0
fi
lnx4
()

Возможно я не так понял. Однако, у тебя неверная постановка задачи. Ты чего-то не того хочешь.

Как проверить что введен правильный пароль root?

При запуске от рута это не катит.

lnx4
()

У меня такое ощущение, что ты пытаешься переизобрести оркестрацию. Может лучше использовать для этого всего готовые системы, в которых подобные проблемы уже решены?

Radjah ★★★★★
()
Ответ на: комментарий от lnx4

Пароль рута запрашивается при запуске и в дальнейшем используется тут же в скрипте (по необходимости) и передается на удаленные хосты для использования там. Независимо от кого запускается основной скрипт, апдейт на удаленных хостах выполняется под рутом т.к. может затрагивать /etc/… и т.п. + пароль рута нужен для обратной связи с сервером. На разных хостах могут быть забиты разные юзеры, на некоторых вообще нет никого кроме рута (такая специфика), а рут есть везде и пароль везде одинаковый

tig1818
() автор топика
Ответ на: комментарий от Radjah

Увы, вынужден использовать то что уже имеется, доустановка «готовых систем» невозможна

tig1818
() автор топика
Ответ на: комментарий от lnx4

Прочитайте внимательно шапку: Запуск возможен от любого юзера. В том числе и от рута. И проверять это незачем.

tig1818
() автор топика
Ответ на: комментарий от Radjah

К тому же «готовые системы» слишком универсальны, и все равно требуют допиливания под конкретные нужды. Овчинка выделки не стоит. Имеется полностью функциональная система, описанная проблема практически единственное слабое место, которое не особо и мешает, просто опечатку и дальнейшую кривую работу трудно отслеживать

tig1818
() автор топика

Возиться с shadow слишком муторно

тем не менее это единственный путь. В libc есть простой апи (man getpwnam, man crypt), но что-то мне подсказывает, что компилять что-то вручную на этом хосте вообще не вариант.

Поэтому таки да. Вот например кто-то написал делающий это shell-скрипт: https://github.com/TobjasR/chkpasswd. Наверно можно использовать его, если openssl в зависимостях не смущает.

Lrrr ★★★★★
()

Есть есть какой-то обычный пользователь на хосте или можно его временно создать, то можно извратиться:

su -c 'su -c exit -' - user
xaizek ★★★★★
()
Последнее исправление: xaizek (всего исправлений: 2)
Ответ на: комментарий от tig1818

рут есть везде и пароль везде одинаковый

Ну, как вариант… Если пароль заранее известен, можно не в открытом виде хранить, а хэш и сравнивать по нему.

lnx4
()
Ответ на: комментарий от lnx4

можно не в открытом виде хранить, а хэш Увы, пароль подается в expect, хэш там не примут

tig1818
() автор топика

запускать скрипт из-под sudo. на всех машинах через sudoers.d разрешать беспарольный запуск этого скрипта от root.
далее защита скрипта от редактирования и изменения от простых пользователей.

pfg ★★★★★
()
Ответ на: комментарий от xaizek

можно извратиться Интересное решение, запрашивает пароль рута даже при запуске от рута, а как можно вытащить оттуда результат? Ну, типа сработало или нет? Мне это вряд-ли подойдет из-за ограниченных возможностей по манипуляции списком юзеров, но интерес вызвало

tig1818
() автор топика
Ответ на: комментарий от pfg

запускать скрипт из-под sudo. на всех машинах через sudoers.d разрешать беспарольный запуск этого скрипта от root

Все это было бы легко, когда бы не было так сложно. Еще проще забить пароль прямо в тексте скрипта и дать ему полномочия –х–х–х. Это не просто грабли, это грабли без зубьев. Все подобные версии уже были рассмотрены и отброшены

tig1818
() автор топика
Ответ на: комментарий от pfg

Добавлю, что все правки и изменения возможны только В ТЕЛЕ СКРИПТА. Любые изменения системных настроек, списка юзеров, цвета изоляции сетевого кабеля и т.д НЕДОПУСТИМЫ

tig1818
() автор топика

автоматизирующий процесс обновления и конфигурирования некоторого софта на солидной группе удаленных хостов

bash-скрипт

А почему не система управления конфигурациями?

vvn_black ★★★★★
()

Кажется человеку нужен ansible

keir ★★
()
Ответ на: комментарий от vvn_black

почему не система управления конфигурациями?

Потому что речь идет не о системной конфигурации, а о конфигурации специализированного софта, который имеет кучу своих конфиг-файлов и только чуть-чуть использует системные (сетевые)

tig1818
() автор топика
Ответ на: комментарий от tig1818

Я его не использовал, но там вроде была какая-то проверка на вывод. И если он stderr не парсит, можно выводить в него.

xaizek ★★★★★
()
Ответ на: комментарий от slowpony

Проверять $? от sudo :

Я уточню: проблему составляет проверка правильности введенного по read пароля рута при запуске скрипта от рута. При запуске от не-рута проблем нет. А sudo от рута всегда Ок

tig1818
() автор топика
Ответ на: комментарий от tig1818

при запуске от рута судо не смотрит на пароль, сколь помню, ему достаточно правила root ALL=(ALL:ALL) ALL в /etc/sudoers

pfg ★★★★★
()

Возиться с shadow слишком муторно

А надо. Всё остальное, в данном случае - костыли.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Возможный вариант

Поэкспериментировав остановился на следующем ''' if [ -z ${RPASS} ] ; then echo -n "Enter ROOT passwd: " read -s RPASS echo fi

check RPASS

if [ «${UID}» -ne 0 ]; then MKDIRS=${USER}$(date +%F) f_run «su -c "> /var/${MKDIRS}"» «${RPASS}» if [ ! -f «/var/${MKDIRS}» ] ; then echo «Invalid ROOT passwd» exit 0 else f_run «su -c "rm -f /var/${MKDIRS}"» «${RPASS}» fi else MKDIRS=$(grep -E «:x:1[0-9]{3}:» /etc/passwd | cut -d: -f1) CH_SUMT=$(date +%s) expect -c «spawn su -c "su -c exit" - ${MKDIRS} while 1 { expect { "*:" { send "${RPASS}\r" } break }} interact» &>/dev/null ((CH_SUME = $(date +%s) - ${CH_SUMT})) if ((CH_SUME > 1)) ; then echo «Invalid ROOT passwd» exit 0 fi fi ''' В основе алгоритма тот факт, что при неправильном пароле отклик системы идет с задержкой 3-4 сек, а при правильном реакция наступает сразу. 100% гарантии как страховой полис это не дает, но уже что-то в противовес мытарствам с shadow. Спасибо всем кто приложил мозг и руку к теме. Отдельное СПАСИБО xaizek-у, думаю он сразу узнает свои строки в тексте. Буду рад ознакомиться с конструктивной критикой, в этом мире ничто не идеально. Всем удачи!

tig1818
() автор топика
Ответ на: комментарий от tig1818

Как-то форматирование не заладилось

tig1818
() автор топика
Ответ на: комментарий от deadNightTiger

От рута вместо su вызывай setpriv --reuid 1000 su

Нету setpriv, и допоставить нельзя

tig1818
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.