#linux #debian #ssh #sudo #ssh_key
Суть вот в чем:
Сделал юзера, дал ему sudo, запретил парольную авторизацию, запретил
логин root
Каждый раз при запросе sudo спрашивает пароль
Если пароль
убрать или сделать ненадежным (сейчас более 20 символов), это, как
говорят, дырка, но а вообще, зачем козе баян, и зачем при отказе от
пароля при авторизации на сервере теперь мне нужно вводить пароль для
подтверждения прав рута? Логика неконсистентная более чем полностью.
Должно быть что-то одно:
Или отказ от авторизации по паролям и авторизация только по ключу —
мера достаточная, и root убирать никуда не надо
Или необходимо сделать
консистентную авторизацию, т.е. sudo должно спрашивать не пароль у
пользователя, а RSA ключ у ssh-клиента.
Есть еще вариант убрать полностью пароль у sudo, но тогда какой вообще в нем смысл?
Это по сути будет тот же root со ступенькой (необходимость каждый чих вводить через sudo).
Я решил пойти вторым путем и сделать авторизацию через ssh-ключи, и использовать
pam_ssh_agent_auth.
Делал согласно этой инструкции:
http://mike.depalatis.net/ssh-agent-for-sudo-authentication-with-a-passwordless-account.html
Результат нулевой - все равно требует пароль. Есть немаленькая вероятность, что я
где-то накосячил, ибо инструкция совершенно зажевана в конце - мне не совсем понятно
что там и как.
Какие мысли?
Ответы
Ответ 1
Чтобы в sudo не требовался пароль, добавьте нужную строку в файл (новый или существующий) в /etc/sudoers.d. Как правило, на каждую учетку создается свой файл с настройками. (Вместо username - ваше имя пользователя.) echo "username ALL=(ALL:ALL) NOPASSWD:ALL" >> /etc/sudoers.d/username авторизация только по ключу мера достаточная и root убирать никуда не надо Авторизация по ключу обычно более надёжна, чем по паролю. Авторизацию по паролю для root вообще желательно запретить. зачем при отказе от пароля при авторизации на сервере теперь мне нужно вводить пароль для подтверждения прав рута? Логика неконсистентная более чем полностью. Программы ssh(d) и sudo связаны между собой чуть более, чем никак. Одной нет никакого дела до того, как настроена авторизация в другой.Ответ 2
Если вам требуется получение рут-доступа по ключу - так разрешите его по ключу. Создайте отдельный ключ ssh, защитите его паролем (опционально) и разрешите руту входить по этому ключу. Программа sudo больше предназначена для локальных пользователей, а не для удаленных. На сервере sudo вообще не требуется. Возможно, для утверждения "на сервере sudo вообще не требуется" нужно дополнительное обоснование, ведь оно идет вразрез со стандартной рекомендацией "не сидите под рутом!". Поясняю. Рут - это пользователь, который выполняет администрирование компьютера. При локальной работе, пользователь не все время занят администрированием своего компьютера - он еще за ним иногда работает :) Отсюда и требование разделения - работать под одним пользователем, администрировать - под рутом. А отсюда - и sudo, su... На сервере никто не работает через ssh, его только администрируют. А потому обычный пользователь и не нужен.Ответ 3
зачем при отказе от пароля при авторизации на сервере теперь мне нужно вводить пароль для подтверждения прав рута? программа sudo предназначена для выполнения (любых или указанных) команд от имени другого указанного пользователя (по умолчанию — пользователя root). по умолчанию запрашивается пароль текущего пользователя, для подтверждения, что программу sudo запустил именно этот пользователь (а не для «подтверждения прав рута»). кстати, данное поведение может быть переопределено: см. описание флагов rootpw, targetpw и runaspw в man 5 sudoers. Должно быть что-то одно: - Или отказ от авторизации по паролям и авторизация только по ключу мера достаточная и root убирать никуда не надо - Или необходимо сделать консистентную авторизацию, т/е sudo должно спрашивать не пароль у пользователя, а RSA ключ у ssh клиента. запрос пароля на удалённом сервере, куда пользователь получает доступ только по ключу, может послужить дополнительным барьером для случаев компрометации секретного ключа или машины пользователя. Есть еще вариант убрать полностью пароль у sudo но тогда какой вообще в нем смысл? Это по сути будет тот же root со ступенькой (необходимость каждый чих вводить через sudo) даже если пользователь, которому разрешено использовать программу sudo, всего один, и даже если ему разрешено выполнять любые команды от имени любого пользователя, автоматическое логирование всех запусков программы sudo может оказать существенную помощь при устранении ситуации «что-то пошло не так». если же таких пользователей несколько, логирование ещё более полезно. Делал согласно этой инструкции вероятно, лучше использовать уже готовый пакет. если вы используете стабильный выпуск (jessie, версия 8) или новее, в репозиториях есть необходимые зависимости. если более старый выпуск, возможно, потребуется пересборка пакета с указанием более старых версий зависимостей. в любом случае, лучше использовать пакет (пусть даже пересобранный), чем загрязнять систему не контролируемыми пакетным менеджером программами. Какие мысли? pam-аутентификация по ключу, с моей точки зрения, не сможет послужить полноценной заменой вводу пароля в случае компрометации секретного ключа или машины пользователя. разве что частично: если для аутентификации используется другой ключ (не тот же, что и для доступа по ssh), защищённый кодовой фразой. пару слов по поводу ответа от Pavel Mayorov На сервере никто не работает через ssh, его только администрируют. А потому обычный пользователь и не нужен. ситуация, когда «пользователь» у сервера всего один — встречается, думаю, довольно часто. но и ситуация, когда «пользователей» больше одного — тоже далеко не редкость. и вряд ли редкостью можно назвать ситуацию, когда пользователи выполняют именно пользовательские задачи, не связанные с администрированием. та же веб-разработка, например. для которой может потребоваться выполнение некоторых административных задач (например, конфигурирование и управление http-сервером), в чём программа sudo, несомненно, способна послужить незаменимым подспорьем. За веб-разработку на сервере надо бить по рукам. Для этой цели виртуалки есть. да, «сервер» вполне может быть и виртуальной машиной. способы же использования машины (как виртуальной, так и «железной», как выполняющей роль «сервера», так и выполняющей любую иную роль), вероятно, определяет её владелец, а не мы с вами. к тому же веб-разработка была приведена лишь в качестве иллюстрации. неплохим семейством иллюстраций может быть использование сервера(-ов) для ресурсоёмких задач: компиляции, сборки пакетов, рендеринга, конвертации видео, data-mining-а, той же виртуализации и т.д. и т.п. обновление по поводу «неработоспособности» пакета как написано в man pam_ssh_agent_auth (страница идёт в комплекте с пакетом), надо добавить в /etc/pam.d/sudo строку примерно такого содержания: auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys она должна идти до строк с include-ами. в указанный файл с ключами /etc/security/authorized_keys надо добавить тот публичный ключ, по которому и будет происходить pam-аутентификация. в принципе, расположение этого файла — произвольное, и может быть даже привязано к домашнему каталогу пользователя: см. секцию примеров в упомянутой man-странице. перед использованием такой аутентификации, вероятно, лучше завершить все процессы пользователя и перелогиниться. при подключении надо, естественно, пропускать соединение с вашим ssh-agent-ом с «сервера». либо с помощью соответствующей опции в ~/.ssh/config, либо с помощью опции -A программы ssh. если всё перечисленное не помогает, добавьте в конце той же строки (в файле /etc/pam.d/sudo) директиву debug. тогда в /var/log/auth.log будет более подробное описание.
Комментариев нет:
Отправить комментарий