Наскоро променяхме паролата на потребител в Linux, когато се натъкнахме на грешка: „Грешка при манипулиране на маркер за удостоверяване“.

Използвахме нормалната команда passwd за промяна на паролата и тя ни даде тази грешка и паролата не беше променена.

Sudo passwd my_user_name Промяна на парола за потребител my_user_name Промяна на парола за tecmint (текуща) UNIX парола: passwd: Грешка при манипулиране на маркер за удостоверяване passwd: парола непроменена

Коригиране на грешка при манипулиране на маркер за удостоверяване в Ubuntu

„Грешка при манипулиране на токена за удостоверяване“ означава, че по някаква причина промяната на паролата е неуспешна.

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

Няма подадена парола passwd: Грешка при манипулиране на токена за удостоверяване passwd: паролата не е променена

По същия начин, ако повторното въвеждане на парола не съвпада, ще покаже и тази информация:

Съжаляваме, паролите не съвпадат passwd: Грешка при манипулирането на токена за удостоверяване passwd: паролата не е променена

Това е лесно, защото знаете какво е причинило проблема и можете да предприемете коригиращи действия въз основа на това. Но невинаги може да имате късмет, защото в някои случаи няма да видите никакви полезна информация, само грешка.

Нека да разгледаме някои от тези случаи и да отстраним този проблем.

Метод 1

Ако сте запознати със структурата на директорията на Linux, знаете, че директорията /etc/shadow съхранява паролата в криптиран формат, заедно с друга информация за потребителите и техните пароли.

Ето защо трябва да се уверите, че имате разрешение да четете и пишете в този файл. Тъй като ще промените паролата като root, този файл трябва да има разрешения за четене и запис за root.

Ако не е, трябва да зададете правилното разрешение:

sudo chmod 640 /etc/shadow

Метод 2

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

Монтиране -rw -o повторно монтиране /

В някои редки случаи вашият диск може да се напълни толкова, че да не можете да правите промени във файла /etc/shadow. Но ако случаят е такъв, тогава ще се натъкнете на много други проблеми.

Подейства ли ти?

Споделихме какво е проработило при нас и можем само да се надяваме, че е проработило и при вас. Го направи? Кой метод работи за вас? Споменете го в коментарите.

linux- това е многопотребителска среда и за да може потребителят да започне работа в системата, той трябва да премине през процедурата за удостоверяване. PAM (Плъгируеми модули за удостоверяване) е система (механизъм), която се грижи за изпълнението на процедурите за удостоверяване. Преди появата PAM, разработчиците на програми, които по някакъв начин са свързани с удостоверяване, трябваше да адаптират програмата си към съществуващите механизми за удостоверяване. Съответно, ако механизмите за удостоверяване се променят, тогава е необходимо да се променят програмите, които ги използват. Затова беше разработена система PAM, което е „слой“ между програмите и механизмите за удостоверяване. Тоест, сега програмите за удостоверяване (например програмата Влизам) трябва да може да работи само със системата PAM. Програмата предава PAMпараметри (например вход и парола) и тя (програмата) вече не се „интересува“ какъв метод за удостоверяване е внедрен в системата - парола или удостоверяване на смарт карта или друг метод. Допълнителни работи PAMи връща програмата или успех, или неуспех.

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

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

група сметка- Това са действия, свързани с управление на акаунта. Например, дори ако сте удостоверени в системата, тогава вашият сметкаМожете да поставите забрана за работа в определени часове на деня. Или разрешете влизането в конзолен режим, но забранете влизането в графичен режим. и т.н.

група сесия- действията на тази група осигуряват на потребителя необходимите ресурси за работа. Най-простият пример е разрешение за монтиране на директории.

група парола- действия, които прилагат промяна в данните за удостоверяване на потребителя. Най-често това са действия за управление на потребителски пароли.

Всички тези действия или процедури (функции) са реализирани като отделни модули, които се намират в каталога /lib/сигурност/. Тоест можем да кажем, че има групови модули авт, групови модули сметкаи т.н. Съответно системата PAMе модулен и ако трябва да внедрите биометрично удостоверяване, тогава просто трябва да инсталирате модул, който може да изпълнява тази процедура.

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

Помислете първо за файловия формат /etc/pam.conf. Файлът се състои от редове. Файлът може да се състои от един ред или може да се състои от няколко реда, образувайки верига от последователни действия. Всеки ред описва едно правило или една стъпка от такава верига (алгоритъм). Линията се състои от четири полета. Първото поле е името на програмата, към която принадлежи тази стъпка. Второто поле е типа действие ( авт, сметка, сесия, парола). Третото поле е полето, в което се задава поведението на системата. PAMслед приключване на тази стъпка на тази стъпка от алгоритъма (ще се спрем на този въпрос по-подробно по-долу). Четвъртото поле е името на файла на модула. Освен това редът може да съдържа някои параметри, предадени на модула.

Структурата на файловете в директорията /etc/pam.d/, същото. Единствената разлика е липсата на първото поле - името. Тъй като името на програмата е взето от името на самия файл. Нека да разгледаме пример за такъв файл. Нека го наречем testpam.

Нека да разгледаме първия ред. Поле автказва, че първата стъпка ще бъде удостоверяване. Третото поле е модулът, който ще извърши удостоверяването и ще върне резултата от изпълнението. IN този примермодул pam_rootok.soпроверява дали акаунтът е root ( корен). Ако да, тогава ще бъде върнат успех (true), ако не, тогава ще бъде върната грешка или неуспех (false). Второто поле е реакцията или въздействието на резултата върху веригата като цяло.

Реакцията може да бъде от четири вида: изисква се, необходим, по желание, достатъчно. На примера на линията достатъчно удостоверение pam_rootok.soНека да видим какво означават тези стойности.

Ако второто поле е зададено на необходим, това означава, че ако модулът pam_rootok.soзавърши с грешка, след което по-нататъшно изпълнение на файла testpamпрекъснат и системата PAMвръща грешка на приложението. Ако модулът е върнал положителен резултат, тогава изпълнението на веригата продължава.

изисква сеизглежда като необходим. Ако модулът pam_rootok.soзавърши с грешка, тогава PAMсъщо ще върне грешка, но след завършване на останалите модули, тоест веригата не е прекъсната. Ако модулът е върнал положителен резултат, тогава изпълнението на веригата продължава.

достатъчно- ако модулът pam_rootok.soвърна успех, след това системата PAMвръща успех на приложението и по-нататъшното изпълнение на веригата се прекъсва. Ако не успее, веригата продължава.

по желание- този параметър не влияе по никакъв начин на хода на веригата. Посочено за онези модули, които не извършват никакви проверки. Ако файлът съдържа само редове с параметъра по желание, Че PAMще върне успеха на приложението.

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

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

Създайте файл /etc/pam.d/suи напишете следния ред в него:

Модул pam_deny.soвинаги връща грешка. Какъв ще бъде резултатът? Проверете. И ако замените необходимНа изисква се?
Сега нека напишем следното правило във файла:

Модул pam_wheel.soвръща успех, ако потребителският акаунт принадлежи към група колело. Ако опитате сега да изпълните командата су, тогава веднага завършва с грешка. Тоест сега командата суможе да се изпълнява само от потребители, които са членове на групата колелои знаете паролата на акаунта корен. Ако създадете група колелои добавете вашия акаунт там, след това командата суще работи.

Ето още един пример:

Опитайте се да отговорите кой може успешно да изпълни командата суИ какво ще трябва да се направи за това?
Това завършва практическото упражнение (не забравяйте да върнете оригиналния su файл).

Искам отново да подчертая, че конфигурационните файлове в директорията /etc/pam.d/ могат да бъдат създадени само за файлове, които използват системата PAM. Например, ако създадете файл /etc/pam.d/lsс низ реквизит за удостоверяване pam_deny.so, след това командата lsпак ще се изпълнява, защото не използва системата PAM. За да проверите дали дадена команда използва системата PAM, можете да използвате командата dd, който се предава като параметър пълен пъткъм командния файл. Например:

Ключова дума компатпросто „казва“, че системата ще се използва като система за удостоверяване PAM.

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

Двуфакторното удостоверяване (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. PAM модулът на Google ще позволи на вашия потребител да се удостовери с 2FA, използвайки генерирани Google кодове OTP.

Първо влезте като потребител на sudo, който сте създали по време на първоначалната настройка на сървъра:

ssh [имейл защитен] _ip_server

Актуализирайте индекса на пакетите на Ubuntu, за да получите последна версияудостоверител:

sudo apt-get актуализация

След като актуализирате хранилищата, инсталирайте най-новата версия на PAM модула:

sudo apt-get инсталирайте libpam-google-удостоверител

Това е много малък пакет без никакви зависимости, така че инсталирането ще отнеме няколко секунди. В следващия раздел ще настроим 2FA за потребителя на sudo.

Стъпка 2: Настройване на двуфакторно удостоверяване

Сега, след като сте инсталирали PAM модула, стартирайте го, за да генерирате QR код за влезлия потребител. Това ще генерира кода, но средата на Ubuntu няма да се нуждае от 2FA, докато не го активирате.

Изпълнете командата google-authenticator, за да стартирате и конфигурирате PAM модула:

google-удостоверител

Командата ще ви зададе някои въпроси за конфигурацията. Тя първо ще попита дали искате жетоните да бъдат ограничени във времето. Токените за удостоверяване с време изтичат след определен интервал (по подразбиране е 30 секунди на повечето системи). Времевите токени са по-сигурни от невремевите токени и повечето реализации на 2FA ги използват. Можете да изберете всяка опция тук, но ние препоръчваме да изберете Да и да използвате ограничени във времето токени за удостоверяване:

Искате ли токените за удостоверяване да са базирани на времето (да/не) y

Като отговорите на y на този въпрос, ще видите няколко реда изход в конзолата:

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

След като сте конфигурирали вашето приложение за удостоверяване и сте запазили вашите резервни кодове на сигурно място, програмата ще ви попита дали искате да актуализирате конфигурационния файл. Ако изберете n, ще трябва да стартирате инсталационната програма отново. Въведете y, за да запазите промените и да продължите:

Искате ли да актуализирам вашия файл "~/.google_authenticator" (y/n) y

След това програмата ще ви попита дали искате да предотвратите използването на кодове за удостоверяване повече от веднъж. По подразбиране можете да използвате всеки код само веднъж, дори ако не са изминали 30 секунди от създаването му. Това е най-безопасният избор, тъй като предотвратява повторни атаки от нападател, който по някакъв начин е успял да получи използвания от вас код за потвърждение. Поради тази причина е по-добре да забраните използването на кодове повече от веднъж. Отговорете на y, за да предотвратите многократно използване на един и същ токен:

Искате ли да забраните многократно използване на едно и също удостоверяване
жетон? Това ви ограничава до едно влизане на всеки 30 секунди, но се увеличава
шансовете ви да забележите или дори да предотвратите атаки тип човек по средата (да/не) y

След това трябва да посочите дали искате токените за удостоверяване да бъдат приети известно време след нормалната им дата на изтичане. Кодовете са много чувствителни към времето и следователно може да не работят, ако устройствата ви не са синхронизирани. Тази опция заобикаля този проблем, като удължава времето за изтичане на кодовете за потвърждение по подразбиране, така че кодовете за удостоверяване да се приемат така или иначе (дори ако устройствата ви временно не са синхронизирани). Най-добре се уверете, че времето на всичките ви устройства е синхронизирано, тъй като положителният отговор леко ще намали сигурността на системата. Отговорете n на този въпрос, за да предпазите токена от изтичане:

По подразбиране токените са добри за 30 секунди и за компенсация
възможно времево изкривяване между клиента и сървъра, допускаме доп
токен преди и след текущия час. Ако имате проблеми с бедните
времева синхронизация, можете да увеличите прозореца от неговия по подразбиране
размер от 1:30мин до около 4мин. Искате ли да го направите (y/n) n

Последният въпрос е дали искате да активирате ограничение за броя на опитите за влизане. Това ще попречи на потребителя да направи повече от три неуспешни опита за влизане в рамките на 30 секунди, което ще увеличи сигурността на системата. Активирайте това ограничение, като отговорите на y:

Ако компютърът, в който влизате, не е защитен срещу груба сила
опити за влизане, можете да активирате ограничаване на скоростта за модула за удостоверяване.
По подразбиране това ограничава нападателите до не повече от 3 опита за влизане на всеки 30 секунди.
Искате ли да активирате ограничаване на скоростта (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, като добавите ред в края на съществуващия файл.

Общият файл за удостоверяване се прилага за всички механизми за удостоверяване в системата, независимо от използваната среда. Прилага се и за заявки за удостоверяване, които възникват, след като потребителят е влязъл, като например по време на подкана за sudo права при инсталиране на нов пакет от терминал.

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

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

Добавете в края на файла:

...
# и ето още модули за пакет (блокът „Допълнителни“)
изисква сесия pam_unix.so

Този ред позволява на системата за удостоверяване на Ubuntu да поддържа 2FA при влизане с модула Google PAM. Опцията nullok позволява на съществуващите потребители да влизат дори ако не са настроили 2FA удостоверяване за своя акаунт. С други думи, потребителите, които са настроили 2FA, ще трябва да въведат код за удостоверяване следващия път, когато влизат, докато потребителите, които не са изпълнили командата google-authenticator, ще могат да влизат с идентификационните си данни по подразбиране, докато не настроят 2FA.

Запазете и затворете файла.

2FA подкана само когато сте влезли

Ако искате 2FA да бъде заявен само при влизане в десктоп среда, трябва да редактирате конфигурационния файл на десктоп мениджъра, който използвате. Името на конфигурационния файл обикновено е същото като името на работната среда. Например конфигурационният файл за gdm (средата по подразбиране на Ubuntu от Ubuntu 16.04) е /etc/pam.d/gdm.

В случай на сървър без глава (който е виртуален сървър), вместо това трябва да редактирате файла /etc/pam.d/common-session. Отворете подходящия файл в зависимост от вашата среда:

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

Добавете маркираните редове в края на файла:

#
# /etc/pam.d/common-session - модули, свързани със сесията, общи за всички услуги
#
...
# # и ето още модули за пакет (блокът „Допълнителни“)
изисква сесия pam_unix.so
сесия по избор pam_systemd.so
# край на конфигурацията на pam-auth-update
изисква се удостоверяване pam_google_authenticator.so nullok

Ubuntu вече ще изисква 2FA, когато потребител се свърже към системата чрез командния ред (локално или отдалечено чрез SSH), но това няма да се отнася за изпълнение на команди със sudo.

Вие сте конфигурирали Ubuntu да поддържа 2FA. Сега е време да тествате конфигурацията и да се уверите, че когато влезете във вашата Ubuntu система, ще бъдете подканени да въведете код за сигурност.

Стъпка 4: Тестване на двуфакторно удостоверяване

Преди сте настройвали 2FA за генериране на кодове на всеки 30 секунди. Сега опитайте да влезете във вашата Ubuntu среда.

Първо, излезте и влезте отново във вашата Ubuntu среда:

ssh [имейл защитен] _ip_server

Ако използвате удостоверяване, базирано на парола, ще бъдете подканени да въведете паролата на потребителя:

Забележка: Ако използвате удостоверяване на сертификат на отдалечения сървър, няма да бъдете подканени за парола. Ключът ще бъде прехвърлен и приет автоматично. Ще трябва само да въведете код за потвърждение.

Въведете паролата, след което ще бъдете подканени да въведете 2FA кода:

Код за потвърждение:

След това ще влезете в системата:

[имейл защитен] _ip_server: ~#

Ако 2FA е активиран само за влизане, вече няма да е необходимо да въвеждате 2FA кодове за потвърждение, докато сесията ви не приключи или ръчно не излезете.

Ако сте активирали 2FA чрез общия файл за удостоверяване, ще бъдете подканени да го посочите и при всяка заявка за sudo привилегии:

[имейл защитен] _server_ip: ~# sudo -s
sudo парола за 8host:
Код за потвърждение:
[имейл защитен] _ip_server:

Уверихте се, че конфигурацията на 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-удостоверител

Първият ред в този файл е личният ключ на потребителя, който се използва за настройка на удостоверителя.

Сега имате две възможности:

1. Можете да копирате личния ключ и да настроите удостоверителя.
2. Ако искате да започнете от чист лист, можете да премахнете изцяло файла ~/.google-authenticator, за да деактивирате 2FA за този потребител. След като влезете отново, ще можете да настроите отново 2FA и да получите нов таен ключ.

Във всеки случай можете да възстановите системата след 2FA блокиране в локална среда с помощта на GRUB буутлоудъра. След това ще обясним как да възстановите достъпа до блокирана отдалечена среда.

Стъпка 7: Възстановяване на достъпа до изтритата среда (по избор)

Ако вашият sudoer акаунт е заключен в отдалечена среда, можете временно да деактивирате или преконфигурирате 2FA, като използвате root потребителя.

Влезте като root потребител:

ssh [имейл защитен] _ip_server

След като влезете, отворете файла Настройки на GoogleУдостоверител, който се намира в домашната директория на блокирания потребител:

sudo nano /home/8host/.google_authenticator

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

Сега имате два пътя:

1. Ако искате да настроите ново или изтрито устройство, можете да използвате секретния ключ, за да конфигурирате отново приложението за удостоверяване.
2. Ако искате да започнете от чист лист, можете напълно да изтриете файла /home/8host/.google_authenticator, за да деактивирате 2FA за този потребител. След като влезете като потребител на sudo, ще можете да настроите отново 2FA и да получите нов частен ключ.

С която и да е от тези опции ще можете да възстановите случайно блокиране на 2FA, като използвате root акаунта.

Заключение

В този урок вие настройвате 2FA на машина с Ubuntu 18.04. Двуфакторното удостоверяване осигурява допълнителен слой за сигурност на акаунта и системата. В допълнение към стандартните идентификационни данни, вие също ще трябва да въведете допълнителен кодпотвърждение за влизане. Това прави невъзможен неоторизиран достъп до вашия акаунт, дори ако нападател успее да получи вашите идентификационни данни.

1. Свържете USB токена към вашия компютър.
2. За да определите името на модела на USB токена, отворете Терминали въведете командата:

В резултат името на модела на USB токена ще се покаже в прозореца на терминала:

Уверете се, че използвате: Активен Rutoken ECP

Въведение

Pluggable Authentication Modules (PAM, Pluggable Authentication Modules) е набор от споделени библиотеки, които ви позволяват да интегрирате различни методи за удостоверяване на ниско ниво в един 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 инсталирате pcscd opensc openssl libpam-p11 libengine-pkcs11-openssl

Потребителите на Rutoken S също трябва да инсталират драйвера от нашия уебсайт.

Обща процедура

настройка pam_p11

Преди да започнете да работите с токена, трябва да конфигурирате модула pam_p11:

Създаване на файл /usr/share/pam-configs/p11 със следното съдържание:

Име: Pam_p11 По подразбиране: да Приоритет: 800 Тип удостоверяване: Основно удостоверяване: достатъчно 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.

   Създаване на ключове върху токен

Нека подготвим жетона.

$ pkcs15-init -E $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "Потребителски PIN" --auth- id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize

В параметрите pin и so-pin можете да посочите желаните потребителски и администраторски пин кодове.

Създаваме двойка ключове RSA с дължина 2048 бита с идентификатор "45" (струва си да запомните идентификатора, ще ви трябва, когато създавате сертификат). Удостоверяването на токен се извършва под потребителския обект.

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

Нека проверим генерирания ключ:

$ pkcs15-tool --list-keys Използване на четец с карта: Aktiv Rutoken ECP 00 00 Private RSA Key Object Флагове: , частен, модифицируем Употреба: , знак Флагове за достъп: , чувствителен, alwaysSensitive, neverExtract, локален ModLength: 2048 Key ref : 1 (0x1) Роден: да Път: 3f001000100060020001 ID на удостоверяване: 02 ID: 45

Създаване на сертификат и импортирането му в токен

2. Стартирайте openssl

   Зареждаме модула за поддръжка на pkcs11:

   OpenSSL> динамичен двигател -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 (динамичен) Поддръжка на динамично зареждане на двигателя: 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 Заредено: (pkcs11) pkcs11 двигател 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 е двойката слот:идентификатор (която посочихме в стъпка 5). OpenSSL ще ви подкани да въведете PIN и да попълните информацията за сертификата. Ако получите грешка, проверете дали други USB токени или четци на смарт карти са свързани към компютъра.

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

   Забележка

   На етапа на избор на потребител информацията за свързания токен може да не се актуализира динамично. Ако сте свързали токена и не виждате полето за въвеждане на ПИН код, може да се наложи да преместите фокуса към „сесията на гост“ и обратно към вашия потребител.

От 2020 г. използването на криптиране в съответствие с GOST R 34.10-2001 ще бъде забранено, което означава, че всички организации, които взаимодействат с държавни агенции, са принудени спешно да въведат следващия стандарт - 2012. Ако работите в един от тях, тогава не подминавайте: в тази статия ще говорим за това как да разрешим проблема с помощта на сървър на CentOS 7 и пакета CryptoPro JCP.

Ако чувате всичко това за първи път, ето малко историческа справка.

През 1994 г. FSB разработи редица стандарти и мерки, предназначени да защитят обмена на документи между организации и други участници в този процес. Една от тези мерки за сигурност беше електронният цифров подпис на документи и един от стандартите - GOST R 34.10-94, който описва алгоритъма за генериране и проверка на електронни цифров подпис. Приет и въведен в сила с решение на Държавния стандарт на Русия от 23 май 1994 г., номер 154, той работи до 2001 г.

Той беше заменен от добре познатия GOST R 34.10-2001 - подобрен стандарт, предназначен да осигури по-голяма стабилност на алгоритъма. Но времето не стои неподвижно, алгоритмите и методите за криптозащита се променят и след единадесет години GOST R 34.10-2001 се променя на GOST R 34.10-2012.

В новия стандарт първата версия на изискванията за параметрите остава същата. Дължина таен ключе от порядъка на 256 бита, като се предвижда използването на хеш функция с дължина на хеш кода 256 или 512 бита. Основната разлика на новия стандарт са опциите с допълнителни параметри и схеми, включително хеширане съгласно стандарта GOST R 34.11-2012 Stribog.

ИНФО

Стрибог е богът на древните славяни, който покровителства ветровете, времето и всичко, свързано с въздушното пространство. Може би и облачни технологииЕдин и същ. Прочетете повече за този шифър в статиите "" и "".

През февруари 2014 г. FSB обяви началото на прехода към използването на новия национален стандарт GOST R 34.10-2012 в електронен подписза информация, която не съдържа информация, представляваща държавна тайна. Публикуваният документ с номер 149/7/1/3-58 от 31 януари 2014 г. „Относно процедурата за преход към използването на нови стандарти на EDS и функции за хеширане“ установи следните изисквания.

1. След 31 декември 2013 г. прекратете сертифицирането на средствата за електронен подпис за съответствие с изискванията за средствата за електронен подпис, одобрени със Заповед на Федералната служба за сигурност на Русия от 27 декември 2011 г. № 796, ако тези инструменти не предвиждат прилагането функции в съответствие с GOST R 34.10-2012.
2. След 31 декември 2018 г. забранете използването на GOST R 34.10-2001 за генериране на електронен подпис.

Министерството на съобщенията дори създаде план за прехода към стандарта (PDF). На практика обаче се оказа, че всичко не е толкова просто и преходът трябваше да бъде отложен до 31 декември 2019 г. Причините са следните.

1. Много държавни и общински органи не са готови да преминат към новия стандарт за електронен подпис GOST-2012 поради липсата на поддръжка на софтуерно ниво.
2. За да издадете нови сертификати, ви е необходим хардуер, който поддържа нов GOST, и сертификата на главния сертифициращ орган, генериран с помощта на GOST-2012. Сертификационните центрове го получиха едва през лятото на 2018 г. Необходимо е допълнително време за издаване на сертификати на всички потребители.

Сега има два стандарта за криптозащита за работата на EDS, но тези, които използват GOST-2001, спешно трябва да направят нещо. Зимата, както се казва, идва, което означава, че ни очаква серия от тестове при прилагането на поддръжката на GOST-2012.

Ще ви кажа как да внедрите сертифициран от FSB криптографски инструмент за защита на информацията (CryptoPro JCP) на Linux сървър, работещ с Java JDK. Между другото, ако все още използвате GOST-2001, има чудесен на уебсайта на CryptoPro, съветвам ви да го прочетете, няма да е излишно.

Целият документооборот между участниците в обмена се осъществява на принципа на SMEV (система за междуведомствено електронно взаимодействие). Едно приложение може да е член на такава система, но може и да не е такова, принципът на обмен на документи не се променя от това. За по-лесно разбиране начертах малка диаграма.

цени

Както винаги, възниква въпросът за лицензирането. софтуерно решение. CryptoPro JCP не е евтин и ако една работна станция струва 1200 рубли, тогава сървърните лицензи са много по-скъпи - около 30 000 за всяко ядро ​​(или две ядра Процесор Intelс деактивиран Hyper Threading).

Инсталиране и конфигуриране на крипто доставчик

В примерите, които ще използвам виртуална машинас CentOS 7, но не сте ограничени в избора хардуерИ Linux дистрибуция. Всички действия и команди ще бъдат същите.

Първо, нека създадем локален потребител, под който ще работи софтуерът, който използва подписване на документи.

$ sudo useradd -d /opt/user -p<Тут указываем пароль>-s /bin/bash потребител; 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; лс-ал;

Копирайте папката в секцията за приложен софтуер. Обикновено използвам /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/; лс-ал;

Предписвайте променливи на средатаза Java JDK за всички потребители по подразбиране.

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

Записваме следното във файла:

Експорт JAVA_HOME=/opt/jdk1.8.0_191 експорт JRE_HOME=/opt/jdk1.8.0_191/jre експорт PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/bin

Ако сървърът има множество версии на Java JDK, трябва да се регистрират алтернативи нова версия.

$ sudo алтернативи --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ sudo алтернативи --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ sudo алтернативи --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ sudo алтернативи --set jar /opt/jdk1.8.0_181/bin/jar $ sudo алтернативи --set jar /opt/jdk1.8.0_191/bin/jar $ sudo алтернативи --set javac /opt/jdk1.8.0_191/bin/javac $ sudo алтернативи --config java

В менюто изберете опция 2 (или тази, която ще доведе до използването на по-нова Java версии). Не забравяйте да коригирате правата върху JRE systemPrefs.

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

Проверка инсталирана версия Java.

$ java-версия
java версия "1.8.0_191"
Java(TM) SE Runtime Environment (компилация 1.8.0_191-b12)
Java HotSpot(TM) 64-битов сървър VM (компилация 25.191-b12, смесен режим)

Копирайте папката с комплекта за разпространение на CryptoPro JCP в секцията за приложен софтуер.

$ sudo cp -rf jcp-2.0.40035 /опция/

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

$ 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!