Скзи удаленная аутентификация пользователя linux. Исправление ошибки ‘Authentication Token Manipulation Error’ в Ubuntu Linux. Создание ключей на токене

17.05.2020 Новости 

  1. Подключите USB-токен к компьютеру.
  2. Для определения названия модели USB-токена откройте Терминал и введите команду:
$ lsusb

В результате в окне Терминала отобразится название модели USB-токена:

Убедитесь, что используете: Aktiv Rutoken ECP

Введение

Pluggable Authentication Modules (PAM, подключаемые модули аутентификации) - это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API. Это позволяет предоставить единые механизмы для управления, встраивания прикладных программ в процесс аутентификации.

Общий порядок действий для настройки PAM следующий:

  1. Сгенерировать на токене ключевую пару RSA (проверено, что работает для длины ключа 2048 бит, с 1024 были проблемы)
  2. Если требуется сертификат, то с помощью OpenSSL или другого ПО сгенерировать сертификат и записать его на токен
  3. Записать открытый ключ или сертификат в необходимый каталог

В итоге выглядит это так:



Предварительная подготовка

Демонстрация работы проводится на Ubuntu 18.04. Описанная последовательность действий актуальна также для других версий Ubuntu и систем, основанных на Debian.

Для конфигурации модуля PAM необходимо установить пакеты:

  • pcscd
  • OpenSC
  • OpenSSL
  • libpam-p11
  • libengine-pkcs11-openssl

Sudo apt-get install pcscd opensc openssl libpam-p11 libengine-pkcs11-openssl

Пользователям Рутокен S также необходимо установить драйвер с нашего сайта.

Общий порядок действий

Настройка pam_p11

До начала работы с токеном стоит настроить модуль pam_p11:

    Создать файл /usr/share/pam-configs/p11 со следующим содержанием:

    Name: Pam_p11 Default: yes Priority: 800 Auth-Type: Primary Auth: sufficient pam_p11_opensc.so /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

    Если вы используете не Ubuntu 18.04, вам необходимо проверить местонахождение opensc-pkcs11.so. Он может находится, например, в

    /usr/lib/opensc-pkcs11.so. Если его найти не удается воспользуйтесь командой find

    Обновить конфигурацию PAM:

    Sudo pam-auth-update

  1. В появившемся диалоге необходимо удостовериться, что выбран pam_p11. Если вы хотите отключить аутентификацию по паролям, то можно отключить Unix authentication.

    Создание ключей на токене

  2. Подготовим токен.

    $ pkcs15-init -E $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize

    В параметрах pin и so-pin можно указать желаемые пин-коды пользователя и администратора.

    Создаем ключевую пару RSA длины 2048 бит c ID "45" (id стоит запомнить, он понадобится при создании сертификата). Аутентификация на токене происходит под сущностью пользователя.

    $ pkcs15-init --generate-key rsa/2048 --auth-id 02 --id 45 <вводим PIN пользователя>

    Проверим сгенерированный ключ:

    $ pkcs15-tool --list-keys Using reader with a card: Aktiv Rutoken ECP 00 00 Private RSA Key Object Flags: , private, modifiable Usage: , sign Access Flags: , sensitive, alwaysSensitive, neverExtract, local ModLength: 2048 Key ref: 1 (0x1) Native: yes Path: 3f001000100060020001 Auth ID: 02 ID: 45

    Создание сертификата и импорт его на токен

  3. Запускаем openssl

    Подгружаем модуль поддержки pkcs11:

    OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so (dynamic) Dynamic engine loading support : SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so : ID:pkcs11 : LIST_ADD:1 : LOAD : MODULE_PATH:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL>

    Если вы используете не Ubuntu 18.04, вам необходимо проверить местонахождение pkcs11.so. Он может располагаться, например, в /usr/lib/openssl/engines/ . Если его найти не удается воспользуйтесь командой find

    Создаем самоподписанный сертификат в PEM-формате:

    OpenSSL> req -engine pkcs11 -new -key 0:45 -keyform engine -x509 -out cert.pem -text

    Где 0:45 - это пара slot:id (который мы указывали в п.5). OpenSSL предложит ввести PIN-код и заполнить информацию о сертификате. Если у вас возникла ошибка, проверьте, не подключены ли другие USB-токены или считыватели смарт-карт к компьютеру.

    Проверяем созданный сертификат. В текущем каталоге должен создаться файл самоподписанного сертификата с именем cert.pem.
    Примечание: если при создании сертификата в OpenSSL убрать ключ -x509, то на выходе получим заявку на сертификат.

    Примечание

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

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

Linux позволяет настроить компьютер так, что войти в консоль, рабочий стол или через Secure Shell будет нельзя без кода двухфакторной аутентификации, привязанного к этой машине. Рассмотрим весь процесс настройки на системе Ubuntu Server 16.04.

Введение

Прежде чем начать, нужно учесть один факт - после настройки двухфакторной аутентификации вы не сможете получить доступ к вашему компьютеру без сгенерированных третьей стороной кодов. Каждый раз, когда вы захотите войти в систему, вам понадобится либо ваш смартфон, либо экстренные коды (emergency codes), которые можно настроить в процессе.

Нам понадобится сервер или десктоп Linux. Убедитесь, что система в актуальном состоянии, а ваши данные скопированы на случай непредвиденных обстоятельств. Для создания двухфакторных кодов будем использовать стороннее приложение, например, Authy или Google Authenticator. Условно будем пользоваться Google Authenticator, которое нужно предварительно установить.

Установка

Залогиньтесь в системе и выполните следующие шаги:

  1. Откройте окно терминала.
  2. Выполните команду: sudo apt install libpam-google-authenticator .
  3. Введите пароль sudo и нажмите Enter.
  4. Если появится запрос на подтверждение, введите «y» и нажмите Enter.
  5. Дождитесь конца установки.

Теперь пришло время настроить компьютер на двухфакторную аутентификацию.

Конфигурация

Вернитесь в окно терминала и введите команду: sudo nano /etc/pam.d/common-auth . Добавьте следующую строку в конец файла:

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

Теперь мы должны настроить Google Authenticator для каждого пользователя, кто должен иметь доступ в систему. Для этого нужно вернуться в окно терминала и от лица пользователя, которому планируется предоставить доступ, запустить команду google-authenticator. Здесь придется ответить на пару вопросов.

Первый вопрос: «Хотите ли вы, чтобы токены аутентификации были основаны на времени (y/n)» («Do you want authentication tokens to be time-based (y/n)»). Ответьте «y», вам будет предоставлен QR-код. Откройте на своем смартфоне двухфакторное приложение, добавьте учетную запись и отсканируйте этот QR-код.

Рисунок 1. Полученный QR-код

После того, как вы добавите код, останется ответить еще на несколько вопросов:

  • Do you want me to update your "/home/jlwallen/.google_authenticator" file (y/n) - Хотите ли вы обновить файл/home/jlwallen/.google_authenticator;
  • Do you want to disallow multiple uses of the same authentication token (y/n)? - Хотите ли вы отключить возможность многократного использования одного токена? Эта настройка позволяет выполнять только один вход в систему каждые 30 секунд. Если эта опция активирована, ваши шансы заметить или даже предотвратить атаку вида « » (man-in-the-middle) возрастают.
  • Поскольку значением по умолчанию является 30 секунд, а время сервера и клиента может незначительно отличаться, есть возможность использовать некий дополнительный токен. Следовательно, если у вас возникают проблемы с синхронизацией, вы можете увеличить время окна примерно до 4 минут. Хотите ли вы это сделать? - Do you want to do so (y/n).
  • Если вы сомневаетесь в защите вашего компьютера от атак типа брутфорс (brute-force), вы можете активировать ограничение скорости для модуля аутентификации. По умолчанию это не более 3 попыток входа в систему каждые 30 секунд. Хотите ли вы включить ограничение скорости? - Do you want to enable rate-limiting (y/n)

Ответим на каждый вопрос утвердительно, введя «y» и нажав Enter.

Настройка SSH

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

Сначала надо включить модуль PAM. Для этого набираем команду: sudo nano /etc/pam.d/sshd . Открыв файл, добавляем следующую строку в конец файла:

auth required pam_google_authenticator.so nullok

Сохраняем этот файл, а затем выполняем команду: sudo nano /etc/ssh/sshd_config . В этом файле находим:

ChallengeResponseAuthentication no

И меняем на:

ChallengeResponseAuthentication yes

Сохраняем этот файл и перезапускаем sshd - sudo systemctl restart sshd .

Вход в систему

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

Выводы

Н едавно мы меняли пароль пользователя в 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!