Скзи удаленная аутентификация пользователя linux. CryptoPro JCP на Linux

Главная / Мобильные устройства

Н едавно мы меняли пароль пользователя в Linux, когда столкнулись с ошибкой: Authentication Token Manipulation Error’.

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

Sudo passwd my_user_name Changing password for user my_user_name Changing password for tecmint (current) UNIX password: passwd: Authentication token manipulation error passwd: password unchanged

Исправление ошибки манипуляции токеном аутентификации в Ubuntu

«Authentication Token Manipulation Error’» означает, что по некоторым причинам смена пароля не удалась.

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

No password supplied passwd: Authentication token manipulation error passwd: password unchanged

Точно так же, если повторный ввод пароля не совпадает, он также покажет эту информацию:

Sorry, passwords do not match passwd: Authentication token manipulation error passwd: password unchanged

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

Давайте посмотрим на некоторые из этих случаев и исправим эту проблему.

Способ 1

Если вы знакомы со структурой каталогов Linux , вы знаете, что каталог/etc/shadow хранит пароль в зашифрованном формате вместе с другой информацией о пользователях и их паролях.

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

Если это не так, вы должны установить правильное разрешение:

Sudo chmod 640 /etc/shadow

Способ 2

Метод 1 будет работать в большинстве случаев. Но в нашем случае нам пришлось перемонтировать корневой раздел с правами на чтение и запись. Мы пытались сбросить пароль администратора в Ubuntu.

Mount -rw -o remount /

В некоторых редких случаях ваш диск может быть настолько заполнен, что вы не сможете внести какие-либо изменения в файл /etc/shadow. Но если это так, то вы столкнетесь и со многими другими проблемами.

Это сработало для вас?

Мы поделились тем, что сработало для нас, и мы можем только надеяться, что это сработало и для вас. Сделали это? Какой метод работал для вас? Упоминайте это в комментариях.

С 2020 года использование шифрования по ГОСТ Р 34.10-2001 окажется под запретом, а значит, все организации, которые взаимодействуют с госструктурами, вынуждены срочно внедрять следующий стандарт - 2012 года. Если ты работаешь в одной из них, то не проходи мимо: в этой статье мы поговорим о том, как решить проблему, используя сервер на CentOS 7 и пакет CryptoPro JCP.

Если же ты впервые слышишь обо всем этом, то вот небольшая историческая справка.

В 1994 году в ФСБ разработали ряд стандартов и мер, призванных защитить обмен документами между организациями и другими участниками этого процесса. Одной из таких мер безопасности стала электронная цифровая подпись документов, а одним из стандартов - ГОСТ Р 34.10-94, где описан алгоритм формирования и проверки электронной цифровой подписи. Принятый и введенный в действие постановлением Госстандарта России от 23 мая 1994 года за номером 154, он проработал до 2001 года.

На смену пришел всем известный ГОСТ Р 34.10-2001 - улучшенный стандарт, разработанный для обеспечения большей стойкости алгоритма. Но время не стоит на месте, меняются алгоритмы и методы криптозащиты, и спустя одиннадцать лет ГОСТ Р 34.10-2001 меняют на ГОСТ Р 34.10-2012.

В новом стандарте первый вариант требований к параметрам остался прежним. Длина секретного ключа составляет порядка 256 бит, и предусмотрено использование хеш-функции с длиной хеш-кода 256 или 512 бит. Главное же отличие нового стандарта - варианты с дополнительными параметрами и схемами, в том числе хешированием по стандарту ГОСТ Р 34.11-2012 «Стрибог».

INFO

Стрибог - бог древних славян, который покровительствует ветрам, погоде и всему, что связано с воздушным пространством. Возможно, и облачным технологиям тоже. Подробнее об этом шифре читай в статьях « » и « ».

В феврале 2014 года ФСБ объявила о начале перехода на использование нового национального стандарта ГОСТ Р 34.10-2012 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну. В свет вышел документ за номером 149/7/1/3-58 от 31 января 2014 года «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», он устанавливал следующие требования.

  1. После 31 декабря 2013 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утвержденным приказом ФСБ России от 27.12.2011 года №796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10-2012.
  2. После 31 декабря 2018 года запретить использование ГОСТ Р 34.10-2001 для формирования электронной подписи.

Министерство связи даже создало план по переходу на стандарт (PDF). Однако на практике оказалось, что все не так просто, и переход пришлось отложить аж до 31 декабря 2019 года. Причины следующие.

  1. Многие государственные и муниципальные органы не готовы перейти на использование нового стандарта электронной подписи ГОСТ-2012 из-за отсутствия поддержки на уровне ПО.
  2. Чтобы выпускать сертификаты нового образца, необходимо оборудование, которое поддерживает новый ГОСТ, и сертификат Головного удостоверяющего центра, сформированный с использованием ГОСТ-2012. Удостоверяющие центры получили его только летом 2018 года. Необходимо дополнительное время, чтобы выпустить сертификаты для всех пользователей.

Сейчас в ходу два стандарта криптозащиты для работы ЭЦП, но тем, кто использует ГОСТ-2001, срочно нужно что-то предпринимать. Зима, как говорится, близко, а это значит, что нас ждет череда испытаний при внедрении поддержки ГОСТ-2012.

Я расскажу, как развернуть сертифицированное ФСБ средство СКЗИ (CryptoPro JCP) на сервере Linux под управлением Java JDK. Кстати, если ты до сих пор используешь ГОСТ-2001, на сайте CryptoPro есть замечательная , советую тебе ее прочесть, лишним не будет.

Весь документооборот между участниками обмена происходит по принципу СМЭВ (система межведомственного электронного взаимодействия). Приложение может быть участником такой системы, но может и не быть им вовсе, принцип обмена документами от этого не меняется. Для простоты понимания я нарисовал небольшую схему.


Цены

Как всегда, встает вопрос о лицензировании программного решения. CryptoPro JCP недешев, и если одна рабочая станция обойдется в 1200 рублей, то серверные лицензии стоят значительно дороже - порядка 30 000 за каждое ядро (или два ядра процессора Intel с отключенным Hyper Threading).

Установка и настройка криптопровайдера

В примерах я буду использовать виртуальную машину с CentOS 7, но ты не ограничен в выборе аппаратного обеспечения и дистрибутива Linux. Все действия и команды будут такими же.

Первым делом создадим локального пользователя, под которым будет работать ПО, использующее подпись документов.

$ sudo useradd -d /opt/user -p <Тут указываем пароль> -s /bin/bash user; sudo grep user /etc/passwd

Правильно установим Java JDK. Скачиваем необходимый дистрибутив.

$ wget --header "Cookie: oraclelicense=a" --content-disposition http://download.oracle.com/otn-pub/java/jdk/8u191-b12/2787e4a523244c269598db4e85c51e0c/jdk-8u191-linux-x64.tar.gz -O jdk-8u191-linux-x64.tar.gz

Распаковываем архив и проверяем, готова ли папка с Java для копирования.

$ tar zxvf jdk-8u191-linux-x64.tar.gz; ls -al;

Копируем папку в раздел для прикладного ПО. Я обычно использую /opt .

$ sudo cp -rf jdk1.8.0_191 /opt/

Проверяем, что скопировалось правильно. Если необходимо, меняем владельца папки на root.

$ ls -al /opt/jdk1.8.0_191/ $ sudo chown -R root:root /opt/jdk1.8.0_191/; cd /opt/jdk1.8.0_191/; ls -al;

Прописываем переменные окружения для Java JDK для всех пользователей по умолчанию.

$ sudo vi /etc/profile.d/oracle.sh

В файл пишем следующее:

Export JAVA_HOME=/opt/jdk1.8.0_191 export JRE_HOME=/opt/jdk1.8.0_191/jre export PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/bin

Если на сервере стоит несколько версий Java JDK, то необходимо зарегистрировать альтернативы для новой версии.

$ sudo alternatives --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ sudo alternatives --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ sudo alternatives --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ sudo alternatives --set jar /opt/jdk1.8.0_181/bin/jar $ sudo alternatives --set jar /opt/jdk1.8.0_191/bin/jar $ sudo alternatives --set javac /opt/jdk1.8.0_191/bin/javac $ sudo alternatives --config java

В меню выбираем опцию 2 (или ту, что приведет к использованию более новой версии Java). Не забываем поправить права на JRE systemPrefs.

$ sudo chmod 777 -R /opt/jdk1.8.0_191/jre/.systemPrefs

Проверяем установленную версию Java.

$ java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

Копируем папку с дистрибутивом CryptoPro JCP в раздел для прикладного ПО.

$ sudo cp -rf jcp-2.0.40035 /opt/

Проверяем, что все скопировалось корректно.

$ ls -al /opt/jcp-2.0.40035/

Выдаем права на запуск скриптов.

$ sudo chmod +x /opt/jcp-2.0.40035/*.sh

Проверяем владельца и права на папку, должен быть root. Переходим в нее.

$ ls -al /opt/jcp-2.0.40035/; cd /opt/jcp-2.0.40035/;

Чтобы избежать проблем при инсталляции, проверь количество ядер на процессоре и сверься с лицензией. Узнать число ядер можно командой nproc .

Переходим к установке криптопровайдера JCP. Во время установки необходимо будет ответить на ряд вопросов.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

  • Установленная система ROSA Enterprise Linux Server версии не ниже 6.8 в конфигурации «Стандартный сервер РОСА»
  • Доступ к репозиториям
  • Устройство Рутокен ЭЦП/Рутокен ЭЦП Flash/Рутокен ЭЦП SC вместе с ридером. На устройство должен быть записан сертификат

Для получения доступа к репозиториям получите у службы поддержки ключ и выполните следующую команду с правами администратора:

Echo <ключ> > /etc/rosa-support-id-server

Применимость

В инструкции описаны установка и настройка утилит ROSA Enterprise Linux Server, необходимых для аутентификации с использованием Рутокен ЭЦП. В примере используется архитектура AMD64; для 32-разрядной системы все действия будут аналогичны с точностью до названий папок.

После выполнения нижеприведённой процедуры аутентификация по Рутокен ЭЦП станет возможной, но не будет являться обязательной.

Установка компонентов

Установите требуемые и удалите конфликтующие утилиты (требуются права администратора):

Su yum install ccid opensc pam_pkcs11 gdm-plugin-smartcard yum remove coolkey

Установите библиотеку PKCS#11 для Рутокен ЭЦП (важно устанавливать библиотеку после установки утилит):

  • Перейдите на сайт Рутокен: https://www.rutoken.ru/support/download/pkcs/ .
  • Откройте вкладку «Пользователям GNU/Linux» и нажмите на ссылку «Библиотека rtPKCS11ecp для GNU/Linux RPM 64-bit (x64)».
  • Скачайте и установите пакет (требуется пароль администратора).

Настройка

Проверка отображения устройства в системе и наличия на нём нужной информации

  • Запустите pcscd (требуются права администратора):
su
  • Завершите существующий процесс pcscd , если таковой имелся:
killall pcscd

С этого момента токен должен быть вставлен в соответствующий разъём.

  • Выполните:
pcscd -adfffff
  • Откройте отдельную вкладку или окно терминала и выполните в ней следующую команду:
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -T

В выводе должны быть видны параметры и название устройства. Пример вывода приведён ниже.

  • Проверьте наличие на токене нужной информации при помощи следующей команды (требуется пароль от токена):
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l

В выводе обязан присутствовать Certificate Object . Такие параметры, как ID и label , могут отличаться от приведённых ниже.

Добавление сертификата в доверенные

  • Создайте базу данных доверенных сертификатов (требуются права администратора):
su mkdir /etc/pam_pkcs11/nssdb chmod 0644 /etc/pam_pkcs11/nssdb certutil -d /etc/pam_pkcs11/nssdb -N (создание базы данных) modutil -dbdir /etc/pam_pkcs11/nssdb/ -add p11-kit-trust -libfile /usr/lib64/pkcs11/p11-kit-trust.so (утилита потребует отключить браузер)

  • Скопируйте сертификат с токена (требуется пароль токена. Параметр ID можно взять из вывода команды pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l) :
pkcs11-tool --module=/usr/lib64/librtpkcs11ecp.so -l -r -y cert -d -o cert.crt (команда запишет сертификат в текущую директорию как cert.crt)

  • Добавьте сертификат в доверенные (требуются права администратора):
su cp cert.crt /etc/pki/ca-trust/source/anchors/ (команда вводится из директории, в которую был помещён сертификат) update-ca-trust force-enable update-ca-trust extract (может занять некоторое время)

Изменение конфигурационных файлов

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

pam_pkcs11.conf

  • Создайте (например, на рабочем столе) текстовый файл pam_pkcs11.conf со следующим содержимым:
pam_pkcs11 { nullok = false; debug = true; use_first_pass = false; use_authtok = false; card_only = false; wait_for_card = false; use_pkcs11_module = rutokenecp; # Aktiv Rutoken ECP pkcs11_module rutokenecp { module = /usr/lib64/librtpkcs11ecp.so; slot_num = 0; support_thread = true; ca_dir = /etc/pam_pkcs11/cacerts; crl_dir = /etc/pam_pkcs11/crls; cert_policy = signature; } use_mappers = subject; mapper_search_path = /usr/lib64/pam_pkcs11; mapper subject { debug = true; module = internal; ignorecase = false; mapfile = file:///etc/pam_pkcs11/subject_mapping ; } }
  • Поместите файл в каталог /etc/pam_pkcs11/:
cd /etc/pam_pkcs11/ su mv pam_pkcs11.conf pam_pkcs11.conf.default (резервное копирование) mkdir cacerts crls cp /home/<имя_пользователя>/Desktop/pam_pkcs11.conf /etc/pam_pkcs11/

system-auth

  • Подключите модуль к системе авторизации PAM:
su (получение прав администратора)
  • Откройте файл system-auth в редакторе nano или mcedit :
nano /etc/pam.d/system-auth
  • Добавьте вверху следующую строку:
auth sufficient pam_pkcs11.so pkcs11_module=/usr/lib64/librtpkcs11ecp.so debug

  • Сохраните файл () и закройте редактор ().

subject_mapping

  • Выполните команды:
su pkcs11_inspect

  • Скопируйте вывод предыдущей команды в файл /etc/pam_pkcs11/subject_mapping и укажите, какому пользователю принадлежит сертификат.

Строка конфигурации имеет вид:

Вывод команды pkcs11_inspect -> <имя_пользователя>

Проверка аутентификации через консоль

  • Откройте новое окно или вкладку консоли.
  • Выполните команду su <имя_пользователя> (имя пользователя указано в subject_mapping).

Пример вывода:

После проверки работы аутентификации через консоль можно убрать режим отладки. Для этого в файле /etc/pam.d/sysauth в добавленной строке уберите слово debug , а в файле /etc/pam_pkcs11/pam_pkcs11.conf поставьте напротив debug false вместо true .

Настройка блокировки экрана

  • Откройте для редактирования файл pkcs11_eventmgr (требуются права администратора):
su cd /etc/pam_pkcs11/ mv pkcs11_eventmgr.conf pkcs11_eventmgr.conf.default (резервное копирование) nano pkcs11_eventmgr.conf

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

Pkcs11_eventmgr { # Run in background? Implies debug=false if true daemon = true; # show debug messages? debug = false; # polling time in seconds polling_time = 1; # expire time in seconds # default = 0 (no expire) expire_time = 0; # pkcs11 module to use pkcs11_module = /usr/lib64/librtpkcs11ecp.so; # # list of events and actions # Card inserted event card_insert { # what to do if an action fail? # ignore: continue to next action # return: end action sequence # quit: end program on_error = ignore ; } # Card has been removed event card_remove { on_error = ignore; action = "gdmflexiserver"; } # Too much time card removed event expire_time { on_error = ignore; action = "/bin/false"; } }

  • Добавьте утилиту pkcs11_eventmgr в автозагрузку. Для этого отредактируйте файл.bash_profile пользователя, проходящего аутентификацию:
nano /home/<имя_пользователя>/.bash_profile
  • Добавьте в конец файла строку, запускающую pkcs11_eventmgr .

Пример файла.bash_profile после редактирования:

При выборе аутентификации при помощи токена экран будет выглядеть примерно так.

Двухфакторная аутентификация (2FA) — это метод аутентификации, который для входа в учетную запись или на устройство требует несколько фрагментов информации. Кроме комбинации имени пользователя и пароля, 2FA требует, чтобы пользователь вводил дополнительную информацию, такую как одноразовый пароль (OTP, например шестизначный проверочный код).

В целом, 2FA требует от пользователя ввода информации разных типов:

  • Что-то, что пользователь знает (например, пароль)
  • Что-то, что у пользователя есть (например, код подтверждения, сгенерированный специальным приложением – аутентификатором).

2FA – это подвид многофакторной аутентификации (MFA). Метод MFA в дополнение к тому, что пользователь знает, и тому, что у него есть, требует чего-то, чем он является. Это биометрические данные: распознавание отпечатков пальцев или голоса и т. д.

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

В этом мануале вы узнаете, как настроить 2FA с помощью модуля Google PAM для пользователя без привилегий root в Ubuntu 18.04. Поскольку вы настраиваете 2FA для не-root пользователя, в случае блокировки вы все равно сможете получить доступ к компьютеру из своей учетной записи root. Инструкции мануала достаточно общие, потому их можно применить как к серверам, так и к настольным установкам, как локальным, так и удаленным.

Требования

  • Сервер Ubuntu 18.04 или настольная рабочая среда. Сервер Ubuntu 18.04 нужно настроить по .
  • Аутентификатор, установленный на мобильное устройство (например, Google Authenticator или Authy). С его помощью вы будете сканировать QR-коды безопасности.

1: Установка модуля Google PAM

Чтобы настроить 2FA в Ubuntu 18.04, вам нужно установить модуль Google PAM для Linux. Pluggable Authentication Module (PAM) – это механизм аутентификации, используемый Linux. Модуль Google PAM позволит вашему пользователю проходить аутентификацию 2FA, используя сгенерированные Google коды OTP.

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

ssh 8host@your_server_ip

Обновите индекс пакетов Ubuntu, чтобы получить последнюю версию аутентификатора:

sudo apt-get update

Обновив репозитории, установите последнюю версию модуля PAM:

sudo apt-get install libpam-google-authenticator

Это очень маленький пакет без каких-либо зависимостей, поэтому установка займет несколько секунд. В следующем разделе мы настроим 2FA для пользователя sudo.

2: Настройка двухфакторной аутентификации

Теперь, когда вы установили модуль PAM, запустите его, чтобы сгенерировать QR-код для вошедшего в систему пользователя. Это создаст код, но среде Ubuntu не потребуется 2FA, пока вы не включите ее.

Запустите команду google-authenticator, чтобы запустить и настроить модуль PAM:

google-authenticator

Команда задаст вам несколько вопросов о конфигурации. Сначала она спросит, хотите ли вы, чтобы токены были ограничены по времени. Токены аутентификации, ограниченные по времени, истекают через определенный интервал (он по умолчанию составляет 30 секунд в большинстве систем). Токены с ограниченным временем действия более безопасны, чем токены без такого ограничения, и большинство реализаций 2FA используют их. Вы можете выбрать здесь любой вариант, но мы рекомендуем выбрать Yes и использовать токены аутентификации, ограниченные по времени:

Do you want authentication tokens to be time-based (y/n) y

Ответив y на этот вопрос, вы увидите несколько строчек вывода в консоли:

  • QR-код: это код, который необходимо сканировать с помощью приложения-аутентификатора. После того, как вы отсканировали его, приложение будет создавать новый OTP каждые 30 секунд.
  • Секретный ключ: это альтернативный способ настройки приложения аутентификации. Если вы используете приложение, которое не поддерживает сканирование QR, вы можете ввести секретный ключ, чтобы настроить аутентификатор.
  • Проверочный код: это первый шестизначный код, который генерирует этот конкретный QR-код.
  • Аварийные скретч-коды. это одноразовые токены (также они называются резервными кодами), они позволят вам пройти аутентификацию 2FA, если вы потеряете устройство-аутентификатор. Храните эти коды в надежном месте, чтобы избежать блокировки учетной записи.

После того, как вы настроили свое приложение-аутентификатор и сохранили свои резервные коды в безопасном месте, программа спросит, хотите ли вы обновить файл конфигурации. Если вы выберете n, вам нужно будет снова запустить программу настройки. Введите y, чтобы сохранить изменения и продолжить:

Do you want me to update your "~/.google_authenticator" file (y/n) y

Далее программа спросит, хотите ли вы запретить использование кодов аутентификации более одного раза. По умолчанию вы можете использовать каждый код только один раз, даже если еще не прошло 30 секунд с момента его создания. Это самый безопасный выбор, потому что он предотвращает атаки повторного воспроизведения от злоумышленника, которому каким-то образом удалось получить ваш использованный код подтверждения. По этой причине лучше запретить использование кодов более одного раза. Ответьте y, чтобы запретить многократное использование одного и того же токена:

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

Затем нужно указать, хотите ли вы, чтобы токены аутентификации принимались некоторое время после истечения их обычного срока действия. Коды очень чувствительны ко времени, а потому они могут не сработать, если ваши устройства не синхронизированы. Эта опция позволяет обойти эту проблему, увеличив время действия кодов проверки по умолчанию, чтобы коды аутентификации были приняты в любом случае (даже если ваши устройства временно не синхронизированы). Лучше всего убедиться в том, что время на всех ваших устройствах синхронизировано, так как ответ yes немного снизит безопасность системы. Ответьте n на этот вопрос, чтобы не увеличивать срок действия токена:

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n

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

If the computer that you are logging into isn"t hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Вы настроили и сгенерировали коды 2FA с помощью модуля PAM. Теперь нужно включить 2FA в вашей среде.

3: Активация 2FA в Ubuntu

Модуль Google PAM теперь генерирует коды 2FA для вашего пользователя, но система Ubuntu еще не знает, что ей нужно использовать коды в процессе аутентификации. На этом этапе нужно обновить конфигурацию Ubuntu, чтобы настроить поддержку токенов 2FA в дополнение к обычной аутентификации.

Здесь есть два пути:

  1. Вы можете требовать двухфакторной аутентификации каждый раз, когда пользователь входит в систему, и каждый раз, когда пользователь запрашивает права sudo.
  2. Вы можете требовать 2FA только во время входа в систему, тогда при запросе прав sudo потребуется только пароль пользователя.

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

Примечание : Если вы включаете 2FA на удаленной машине, к которой вы получаете доступ по SSH, вам необходимо выполнить шаги два и три из мануала , прежде чем продолжать работу. Остальные шаги в этом мануале применимы ко всем установкам Ubuntu, но удаленные среды нуждаются в дополнительных настройках, чтобы сервис SSH знал о 2FA.

Если вы не используете SSH для доступа к установке Ubuntu, вы можете сразу же перейти к остальным шагам в этом мануале.

Запрос 2FA при входе в систему и повышении прав sudo

Чтобы система использовала 2FA во время входа и последующих запросов на повышение привилегий, вам необходимо отредактировать файл /etc/pam.d/common-auth, добавив строку в конец существующего файла.

Файл common-auth применяется ко всем механизмам аутентификации в системе, независимо от используемой среды. Он также применяется к запросам аутентификации, которые происходят после входа пользователя в систему, например, во время запроса прав sudo при установке нового пакета из терминала.

Откройте файл:

sudo nano /etc/pam.d/common-auth

В конец файла добавьте:

...
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so


Эта строка включает в системе аутентификации Ubuntu поддержку 2FA при входе через модуль Google PAM. Опция nullok позволяет существующим пользователям войти в систему, даже если они не настроили аутентификацию 2FA для своей учетной записи. Другими словами, пользователи, которые настроили 2FA, должны будут ввести код аутентификации при следующем входе в систему, в то время как пользователи, которые не запустили команду google-authenticator, смогут войти в систему по своим стандартным учетным данным, пока они не настроят 2FA.

Сохраните и закройте файл.

Запрос 2FA только при входе в систему

Если вы хотите, чтобы 2FA запрашивалась только при входе в систему в среде рабочего стола, вам нужно отредактировать конфигурационный файл используемого вами менеджера рабочего стола. Имя конфигурационного файла обычно совпадает с именем среды рабочего стола. Например, файл конфигурации для gdm (среды Ubuntu по умолчанию, начиная с Ubuntu 16.04), — /etc/pam.d/gdm.

В случае headless сервера (каким является виртуальный сервер), вместо этого вам нужно отредактировать файл /etc/pam.d/common-session. Откройте соответствующий файл в зависимости от вашей среды:

sudo nano /etc/pam.d/common-session

Добавьте выделенные строки в конец файла:

#
# /etc/pam.d/common-session - session-related modules common to all services
#
...
# # and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_systemd.so
# end of pam-auth-update config
auth required pam_google_authenticator.so nullok

Теперь Ubuntu будет требовать 2FA, когда пользователь подключается к системе через командную строку (локально или удаленно через SSH), но на запуск команд с sudo это распространяться не будет.

Вы настроили Ubuntu для поддержки 2FA. Теперь пора протестировать конфигурацию и убедиться, что при входе в вашу систему Ubuntu вам будет предложено ввести код безопасности.

4: Тестирование двухфакторной аутентификации

Ранее вы настроили 2FA для генерации кодов каждые 30 секунд. Теперь попробуйте войти в свою среду Ubuntu.

Сначала выйдите из системы и снова войдите в свою среду Ubuntu:

ssh 8host@your_server_ip

Если вы используете аутентификацию на основе пароля, вам будет предложено ввести пароль пользователя:

Примечание : Если на удаленном сервере вы используете аутентификацию по сертификатам, пароль запрошен не будет. Ключ будет передан и принят автоматически. Вам нужно будет ввести только код подтверждения.

Введите пароль, после чего вам будет предложено ввести код 2FA:

Verification code:

После этого вы попадете в систему:

8host@your_server_ip: ~#

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

Если вы включили 2FA через файл common-auth, вам будет предложено указать его также при каждом запросе привилегий sudo:

8host@your_server_ip: ~# sudo -s
sudo password for 8host:
Verification code:
root@your_server_ip:

Вы убедились, что конфигурация 2FA работает должным образом. Если что-то пошло не так и система не запросила у вас коды подтверждения, вернитесь к третьему разделу руководства и убедитесь, что вы отредактировали правильный файл аутентификации Ubuntu.

5: Предотвращение блокировки 2FA

На случай утери или уничтожения мобильного устройства важно предусмотреть методы резервного копирования для восстановления доступа к вашей учетной записи с поддержкой 2FA. Когда вы настраиваете 2FA в первый раз, у вас есть несколько вариантов восстановления доступа после блокировки:

  • Сохраните резервную копию ваших секретных кодов конфигурации в безопасном месте. Вы можете сделать это вручную, но некоторые приложения аутентификации, такие как Authy, предоставляют функции резервного копирования кода.
  • Сохраните коды восстановления в безопасном месте за пределами среды с поддержкой 2FA, к которому можно получить доступ в случае необходимости.

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

6: Восстановление доступа к локальной среде (опционально)

Если у вас есть физический доступ к машине, вы можете загрузиться в режиме восстановления, чтобы отключить 2FA. Режим восстановления – это целевой тип (подобный уровню выполнения) в Linux, который используется для выполнения административных задач. Вам нужно будет отредактировать некоторые настройки в GRUB, чтобы войти в режим восстановления.

Чтобы получить доступ к GRUB, сначала перезагрузите компьютер:

Когда появится меню GRUB, убедитесь, что запись Ubuntu выделена. Это имя установки 18.04 по умолчанию, но оно может отличаться, если вы вручную изменили его после установки.

Затем нажмите клавишу e на клавиатуре, чтобы отредактировать конфигурацию GRUB перед загрузкой вашей системы.

Перейдите в конец появившегося файла и найдите строку, которая начинается с linux и заканчивается $vt_handoff. Перейдите в конец этой строки и добавьте systemd.unit=rescue.target. Убедитесь, что вы оставляете пробел между $vt_handoff и systemd.unit=rescue.target. Это позволит машине Ubuntu загрузиться в режиме восстановления.

После внесения изменений сохраните файл с помощью комбинации клавиш Ctrl + X. Ваша машина перезагрузится, и вы окажетесь в командной строке. Нажмите Enter, чтобы перейти в режим восстановления.

Оказавшись в командной строке, откройте конфигурационный файл Google Authenticator, который расположен в домашнем каталоге заблокированного пользователя.

nano /home/8host/.google-authenticator

Первая строка в этом файле – секретный ключ пользователя, который используется для настройки аутентификатора.

Теперь у вас есть два варианта:

  1. Вы можете скопировать секретный ключ и настроить аутентификатор.
  2. Если вы хотите начать с чистого листа, вы можете полностью удалить файл ~/.google-authenticator, чтобы отключить 2FA для этого пользователя. После повторного входа в систему вы сможете еще раз настроить 2FA и получить новый секретный ключ.

В любом случае вы можете восстановить систему после блокировки 2FA в локальной среде с помощью загрузчика GRUB. Далее мы расскажем, как восстановить доступ к заблокированной удаленной среде.

7: Восстановление доступа к удаленной среде (опционально)

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

Войдите в систему как пользователь root:

ssh root@your_server_ip

После входа в систему откройте файл настроек Google Authenticator, который находится в домашнем каталоге заблокированного пользователя:

sudo nano /home/8host/.google_authenticator

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

Теперь у вас есть два пути:

  1. Если вы хотите настроить новое или стертое устройство, вы можете использовать секретный ключ для перенастройки приложения-аутентификатора.
  2. Если вы хотите начать с чистого листа, вы можете полностью удалить файл /home/8host/.google_authenticator, чтобы отключить 2FA для этого пользователя. После входа в систему как пользователь sudo вы сможете еще раз настроить 2FA и получить новый секретный ключ.

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

Заключение

В этом мануале вы настроили 2FA на машине Ubuntu 18.04. Двухфакторная аутентификация обеспечивает дополнительный уровень защиты учетной записи и системы в целом. Помимо стандартных учетных данных вам также потребуется ввести дополнительный код подтверждения для входа в систему. Это делает невозможным получить несанкционированный доступ к вашему аккаунту, даже если злоумышленнику удастся получить ваши учетные данные.

Tags: ,

Linux - это многопользовательская среда и чтобы пользователь мог начать работу в системе ему нужно пройти процедуру аутентификации. PAM (Pluggable Authentication Modules ) - это система (механизм), которая берет на себя работу по реализации процедур аутентификации. До появления PAM , разработчикам программ, которые были так или иначе связаны с аутентификацией, приходилось подстраивать свою программу под существующие механизмы аутентификации. Соответственно если менялись механизмы аутентификации, значит нужно было менять и программы которые использовали их. Поэтому была разработана система PAM , которая является “прослойкой” между программами и механизмами аутентификации. То есть теперь программы аутентификации (например, программа login ) должны всего лишь уметь работать с системой PAM . Программа передает PAM параметры (например логин и пароль) и ее (программу) уже не “интересует” какой способ аутентификации реализован в системе - аутентификация по паролу или смарт-карте или другой способ. Дальше работает PAM и возвращает программе или успех или отказ.

Посмотрим на систему PAM подробнее. Основные функции, или действия, или задачи которые выполняет система PAM - разбиты на четыре группы которые имеют определенные названия:

группа auth - это действия связанные непосредственно с аутентификацией. То есть действия или функции которые позволяют определить, что вы это вы. Это может быть аутентификация по паролю, по смарт-карте, биометрическая аутентификация (отпечаток пальца и т.д.) и другие.

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

группа session - действия этой группы осуществляют выделение пользователю необходимых для работы ресурсов. Самый простой пример - это разрешение на монтирование каталогов.

группа password - действия, которые реализуют изменение аутентификационных данных пользователя. Чаще всего это действия по управлению паролями пользователя.

Все эти действия или процедуры (функции) реализованы в виде отдельных модулей, которые расположены в каталоге /lib/security/ . То есть можно сказать, есть модули группы auth , модули группы account и т.д. Соответственно система PAM является модульной и если вам необходимо реализовать биометрическую аутентификацию, то необходимо просто установить модуль, которых может это процедуру выполнить.

Основной конфигурационный файл системы PAM - это файл /etc/pam.conf . Кроме файла /etc/pam.conf , настройки PAM хранятся в файлах каталога /etc/pam.d/ . Внутри каталога находятся текстовые файлы которые содержат в себе последовательность действий (некий алгоритм) для программ которые используют PAM . Например, файл /etc/pam.d/login содержит алгоритм работы системы PAM для программы login , а файл /etc/pam.d/passwd для программы passwd .

Рассмотрим сначала формат файла /etc/pam.conf . Файл состоит из строк. Файл может состоять из одной строки, а может из нескольких строк складываясь в цепочку последовательных действий. Каждая строка описывает одно правило или один шаг такой цепочки (алгоритма). Строка состоит из четырех полей. Первое поле это имя программы к которой относится данный шаг. Второе поле, это тип действия (auth , account , session , password ). Третье поле это поле в котором задается поведение системы PAM после завершения этого шага на этом шаге алгоритма (чуть ниже остановимся подробнее на этом вопросе). Четвертое поле - это имя файла модуля. Также в строке могут присутствовать некоторые параметры передаваемые модулю.

Структура файлов находящихся в каталоге /etc/pam.d/ , такая же. Отличие только в отсутствии первого поля - имени. Так как имя программы берется из имени самого файла. Посмотрим на пример такого файла. Назовем его testpam .

auth sufficient pam_rootok.so
auth required pam_unix.so
account required pam_unix.so

Рассмотрим первую строку. Поле auth говорит, что первым шагом будет аутентификация. Третье поле - это модуль, который будет выполнять аутентификацию и возвращать результат выполнения. В данном примере модуль pam_rootok.so проверяет является ли учетная запись рутом (root ). Если, да то будет возвращен успех (true), если нет, то будет возвращена ошибка или отказ (false). Второе поле - это реакция или влияние полученного результата на цепочку в целом.

Реакция может быть четырех типов: required , requisite , optional , sufficient . На примере строки auth sufficient pam_rootok.so рассмотрим, что означают эти значения.

Если во втором поле установлено значение requisite , то это означает, что если модуль pam_rootok.so завершился с ошибкой, то дальнейшее выполнение файла testpam прерывается и система PAM возвращает приложению ошибку. Если модуль вернул положительные результат, то выполнение цепочки продолжается.

required похож на requisite . Если модуль pam_rootok.so завершился с ошибкой, то PAM также вернет, ошибку, но после того как будут выполнены остальные модули, то есть цепочка не прерывается. Если модуль вернул положительные результат, то выполнение цепочки продолжается.

sufficient - если модуль pam_rootok.so вернул успех, то система PAM возвращает приложению успех, и дальнейшее выполнение цепочки прерывается. Если неудача, то продолжается выполнение цепочки.

optional - этот параметр никак не влияет на ход цепочки. Указывается для тех модулей которые не выполняют никаких проверочных действий. Если в файле будут только строки с параметром optional , то PAM вернет приложению успех.

Более подробно о системе PAM и назначении той или иной библиотеки можно прочитать на сайте http://kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html . Сейчас выполним небольшое практическое упражнение которое позволить лучше понять как работает система PAM и как составлять конфигурационные файлы.

Перейдите в каталог /etc/pam.d/ . Скопируйте файл su в домашнюю директорию (чтобы можно было восстановить его) и удалите файл в su из директории /etc/pam.d/ . Попробуйте теперь выполнить команду su в терминале чтобы перейти в режим суперпользователя. После ввода пароля система выдаст ошибку аутентификации, так как отсутствует конфигурационный файл для программы su .

Создаем файл /etc/pam.d/su и пишем в нем такую строку:

Модуль pam_deny.so всегда возвращает ошибку. Какой будет результат? Проверьте. А если заменить requisite на required ?
Теперь напишем в файле следующее правило:

Модуль pam_wheel.so возвращает успех если учетная запись пользователя принадлежит группе wheel . Если попробовать сейчас выполнить команду su , то она тут же завершиться с ошибкой. То есть сейчас команду su смогут выполнить только пользователи, который входят в группу wheel и знают пароль учетной записи root . Если создать группу wheel и добавить туда свою учетную запись, то команда su сработает.

Вот еще пример:

auth requisite pam_wheel.so
auth required pam_permit.so

Попробуйте ответить кто сможет успешно выполнить команду su и, что для этого нужно будет сделать?
На этом завершим практическое упражнение (не забудьте вернуть на место оригинальный файл su).

Хочу еще раз подчеркнуть, что конфигурационные файлы в каталоге /etc/pam.d/ можно создавать только для файлов которые используют систему PAM . Например, если создать файл /etc/pam.d/ls со строкой auth requisite pam_deny.so , то команда ls все равно будет выполнятся так как она не использует систему PAM . Чтобы проверить использует ли команда систему PAM можно использовать команду ldd , которой в качестве параметра передается полный путь к файлу команды. Например:

Ключевое слово compat как раз и “говорит” о том что в качестве системы аутентификации, будет использована система PAM .

И еще. Будьте осторожны в экспериментах с PAM . По незнанию или неосторожности можно запросто заблокировать свою систему. Поэтому перед тем как что-то менять обязательно сохраните исходные конфигурационные файлы, чтобы в случае проблем можно было их быстро восстановить.

© 2024 ermake.ru -- Про ремонт ПК - Информационный портал