Как создать защиту паролей с несколькими уровнями для одного пользователя

Мне интересно, возможно ли иметь расширенную версию PAM которая реализует логин с несколькими уровнями паролей.

Например, мне интересно не обязательно вводить 1, а 3 разных пароля для запуска задачи sudo :

 [user@hostname][/home]# sudo echo ok [sudo] password 1 for user: [sudo] password 2 for user: [sudo] password 3 for user: ok 

3 Solutions collect form web for “Как создать защиту паролей с несколькими уровнями для одного пользователя”

Я бы предложил использовать ssh в качестве обходного пути.

Основная идея

Предположим, вы создали пользователей sudouser (разрешено выполнять команды sudo ) и промежуточного посредника пользователя. Ни оригинальному пользователю ( john ), ни middelman не разрешено выполнять команды sudo .

Мы теперь заменяем любой вызов sudo by john с помощью двухэтапного доступа ssh от john через middleman к sudouser с последним, выполняющим начальную команду sudo . Количество посредников, которые вы ввели в эту цепочку, определяет количество шагов пароля. Я буду придерживаться одного в моем примере.

Чтобы подорвать людей напрямую к sudouser или middleman , пароли этих учетных записей будут заблокированы. sudouser будет предоставлен пароль без права sudo , middleman существует для единственной цели добавления пароля.

Мы настроим его так, чтобы john мог ssh без пароля middleman а затем использовать парольную RSA-ключ для middleman для доступа к sudouser . Т.е. пароль будет ключевой фразой ключа RSA. (так что обратите внимание: каждый посредник нуждается в парольной фразе RSA)


1. Добавление sudouser в файл sudoers

Я предполагаю, что вы знаете об этом, но по причинам полноты я добавил его. Мы предоставим команды sudo без пароля через добавление строки в /etc/sudoers с visudo :

  sudouser ALL=(ALL) NOPASSWD: ALL 

Сейчас это очень опасный пользователь, поэтому отключите его пароль (с root ):

  passwd -l sudouser 

Мы делаем то же самое для любого посредника, чтобы подавить напрямую к последнему посреднику и тем самым пропустить шаги пароля.


2. Создание ssh-keypairs

Опять стандартная операция. Для john и ssk-keygen do ssk-keygen – обратите внимание, что middleman ДОЛЖЕН иметь кодовую фразу для своего RSA-ключа, поэтому мы добиваемся аутентификации пароля. Это не нужно для john но может быть сделано (возможно, только для определенного ключа RSA для этой цели, он просто добавляет еще один шаг пароля).


3. Настройка ssh -access с принудительными командами

Теперь это интересная часть: мы добавляем john к ~/.ssh/authorized_keys middleman с принудительной командой, то есть, когда мы обращаемся к middleman через ssh из john , эта и эта команда будут выполнены только:

 cat /home/middleman/.ssh/authorized_keys command="ssh -t sudouser@localhost $SSH_ORIGINAL_COMMAND" <john's public key> john@localhost 

Таким образом, это будет непосредственно инициировать ssh-session для sudouser перенаправляя команды, которые мы указали на первом шаге (через $SSH_ORIGINAL_COMMAND ).

Обратите внимание, что это разрешено для john только с localhost – все остальные права доступа запрещены по соображениям безопасности. Вы можете добавить ограничения на пересылку с помощью command"...",no-port-forwarding,no-x11-forwarding,no-agent-forwarding – снова для повышения безопасности.

И для sudouser authorized_keys мы разрешаем доступ только от middleman только от middleman :

 cat /home/middleman/.ssh/authorized_keys ssh-rsa <middleman's public key> middleman@localhost 

Теперь в /etc/ssh/sshd_config мы немного заблокируем доступ:

 Match User middleman,sudouser PasswordAuthentication no AuthenticationMethods publickey 

Таким образом, middleman и sudouser могут получить доступ только через ssh с помощью открытых ключей RAS с принудительными командами, указанными в файлах authorized_keys . Настройка PasswordAuthentication no может быть излишней, поскольку мы ранее закрывали пароли пользователей.


4. Псевдонимы sudo

Теперь команда sudo должна быть заменена на:

 ssh -t middleman@localhost "sudo <command>" 

Для этого будет выполняться простой скрипт оболочки и псевдоним:

 #sudo_alias_script.sh #!/bin/bash ssh -t middleman@localhost "sudo $@" 

и alias sudo='/home/john/.bin/sudo_alias_script.sh'


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

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

https://www.linux.com/learn/how-set-2-factor-authentication-login-and-sudo

Это не повышает безопасность. См. https://security.stackexchange.com/questions/89533/would-requiring-multiple-passwords-enhance-security и удвоенное шифрование повышает безопасность шифрования и bruteforce? , В двух словах, делать больше того же, не может повысить безопасность: либо то, что вы делали раньше, было хорошо, а делать больше, избыточно, или то, что вы делали раньше, было нехорошо, и это дважды не спасет вас. Кроме того, сложность всегда является врагом безопасности, так как она увеличивает риск ошибок в реализации и потому, что она снижает вероятность того, что пользователи будут вести себя так, как вы ожидаете, поэтому, если что-то не улучшит безопасность, затраты на это вредны к безопасности.

Просить двух паролей – это то же самое, что и запрос одного пароля, но сначала введите первую половину, а затем введите вторую половину. Разделив пароль, вы сделали его легче взломать, так как две половины могут быть взломаны независимо. Таким образом, вы снизили безопасность.

Это, как говорится, то, что вы просите, может быть сделано. Повторяю, это плохая идея, но если вы хотите стрелять в ногу, вот как это сделать. Просто имейте в виду, что это не заставит вас бежать быстрее.

В большинстве вариантов Unix аутентификация настраивается через PAM . Модуль PAM, который обрабатывает аутентификацию по паролю, – pam_unix . Вы можете добавить один или несколько вызовов к другим модулям проверки пароля, таким как pam_pwdfile которые pam_pwdfile к другой базе данных паролей (см. Можно ли изменить файл базы данных паролей (/ etc / passwd) в Linux? ).

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

  • grep с переменной
  • Это плохая идея добавить себя в группу sudo?
  • Ошибка Vim E138: не удается написать файл viminfo $ HOME / .viminfo!
  • sudo: «эффективный uid не равен 0, sudo установлен setuid root?» на малине Pi
  • HGRCPATH хранится в / etc / sudoers, но игнорируется hg?
  • Почему рискованно предоставлять sudo vim доступ к обычным пользователям?
  • Получение no tty присутствует и не запрашивать программу, указанную при использовании git over ssh
  • Использование sudoers для запуска команды php
  • Я не получаю привилегии, отредактировал / etc / sudoers
  • / etc / sudoers - Оскорбления - Как добавить список оскорблений?
  • ulimit PICKLE: «Операция не разрешена» и «Команда не найдена»
  • Linux и Unix - лучшая ОС в мире.