Autentificare utilizator la distanță SKZ Linux. Remedierea „Eroare de manipulare a simbolului de autentificare” pe Ubuntu Linux. Crearea cheilor pe un token

17.05.2020 Știri

  1. Conectați tokenul USB la computer.
  2. Pentru a determina numele modelului de token USB, deschideți Terminal si introduceti comanda:
$lsusb

Ca rezultat, numele modelului de token USB va fi afișat în fereastra Terminal:

Asigurați-vă că utilizați: Aktiv Rutoken ECP

Introducere

Modulele de autentificare conectabile (PAM) sunt un set de biblioteci partajate care vă permit să integrați diferite metode de autentificare de nivel scăzut într-un singur API de nivel înalt. Acest lucru ne permite să oferim mecanisme unificate de gestionare, încorporare programe de aplicațieîn procesul de autentificare.

Procedura generală pentru configurarea PAM este următoarea:

  1. Generați o pereche de chei RSA pe token (a fost testat că funcționează pentru o lungime a cheii de 2048 de biți, au existat probleme cu 1024)
  2. Dacă este necesar un certificat, atunci utilizați OpenSSL sau alt software pentru a genera un certificat și scrieți-l pe token
  3. Scrie cheie publică sau certificat în directorul necesar

Pana la urma arata asa:



Pregătirea preliminară

Demonstrația de lucru este efectuată pe Ubuntu 18.04. Secvența de acțiuni descrisă este, de asemenea, relevantă pentru alte versiuni ale sistemelor bazate pe Ubuntu și Debian.

Pentru a configura modulul PAM, trebuie să instalați următoarele pachete:

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

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

Utilizatorii Rutoken S trebuie, de asemenea, să instaleze driverul de pe site-ul nostru web.

Procedura generala

Configurarea pam_p11

Înainte de a începe să lucrați cu simbolul, ar trebui să configurați modulul pam_p11:

    Creați fișier /usr/share/pam-configs/p11 cu următorul conținut:

    Nume: Pam_p11 Implicit: da Prioritate: 800 Auth-Type: Primary Auth: suficient pam_p11_opensc.so /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

    Dacă nu utilizați Ubuntu 18.04, trebuie să verificați locația opensc-pkcs11.so. Poate fi situat, de exemplu, în

    /usr/lib/opensc-pkcs11.so. Dacă nu îl găsiți, utilizați comanda find

    Actualizați configurația PAM:

    Sudo pam-auth-update

  1. În caseta de dialog care apare, trebuie să vă asigurați că pam_p11 este selectat. Dacă doriți să dezactivați autentificarea prin parolă, puteți dezactiva autentificarea Unix.

    Crearea cheilor pe un token

  2. Să pregătim un jeton.

    $ 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

    În parametrii pin și so-pin puteți specifica codurile PIN dorite de utilizator și administrator.

    Creăm o pereche de chei RSA cu lungimea de 2048 de biți cu ID „45” (merită să ne amintim id-ul, va fi necesar la crearea unui certificat). Autentificarea cu jeton are loc sub entitatea utilizator.

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

    Să verificăm cheia generată:

    $ pkcs15-tool --list-keys Utilizarea cititorului cu un card: Aktiv Rutoken ECP 00 00 Private RSA Key Object Flags: , private, modifiable Utilizare: , sign Flag Access: , sensitive, alwaysSensitive, neverExtract, local ModLength: 2048 Ref. cheie : 1 (0x1) Nativ: da Calea: 3f001000100060020001 Auth ID: 02 ID: 45

    Crearea unui certificat și importarea acestuia pe un token

  3. Lansați openssl

    Încărcarea modulului de suport pkcs11:

    OpenSSL> dinamic motor -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 (dinamic) Suport de încărcare dinamică a motorului : 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 Încărcat: (pkcs11) motor pkcs11 OpenSSL>

    Dacă nu utilizați Ubuntu 18.04, trebuie să verificați locația pkcs11.so. Poate fi localizat, de exemplu, în /usr/lib/openssl/engines/. Dacă nu îl găsiți, utilizați comanda find

    Creați un certificat autosemnat în format PEM:

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

    Unde 0:45 este perechea slot:id (pe care am indicat-o la pasul 5). OpenSSL vă va solicita să introduceți codul PIN și să completați informațiile despre certificat. Dacă primiți o eroare, verificați dacă există alte jetoane USB sau cititoare de carduri inteligente conectate la computer.

    Verificăm certificatul creat. Un fișier de certificat autosemnat, numit cert.pem, ar trebui creat în directorul curent.
    Notă: dacă eliminați cheia -x509 când creați un certificat în OpenSSL, atunci rezultatul va fi o cerere pentru un certificat.

    Notă

    În timpul etapei de selecție a utilizatorului, este posibil ca informațiile despre tokenul conectat să nu fie actualizate dinamic. Dacă ați conectat un token și nu vedeți câmpul de introducere a codului PIN, poate fi necesar să schimbați focalizarea pe „sesiunea invitat” și înapoi la utilizator.

Dacă sunteți administrator Linux și doriți să maximizați securitatea serverelor dvs. și computere desktop, probabil că v-ați gândit să utilizați autentificarea cu doi factori. În general, este foarte recomandat pentru toată lumea să-l configureze, deoarece autentificarea cu doi factori face mult mai dificil pentru atacatori să obțină acces la mașinile tale.

Linux vă permite să configurați computerul astfel încât să nu vă puteți conecta la consolă, desktop sau prin Secure Shell fără un cod de autentificare cu doi factori asociat cu această mașină. Să ne uităm la întregul proces de configurare a sistemului Ubuntu Server 16.04.

Introducere

Înainte de a începe, trebuie să luați în considerare un fapt - odată ce ați configurat autentificarea cu doi factori, nu veți putea accesa computerul fără coduri generate de terți. De fiecare dată când doriți să vă conectați, veți avea nevoie fie de smartphone-ul dvs., fie de coduri de urgență, care pot fi configurate în timpul procesului.

Vom avea nevoie de un server sau desktop Linux. Asigurați-vă că sistemul este actualizat și că datele dumneavoastră sunt copiate de rezervă în cazul unor circumstanțe neprevăzute. Pentru a crea coduri cu doi factori vom folosi aplicație terță parte, cum ar fi Authy sau Google Authenticator. În mod convențional, vom folosi Google Authenticator, care trebuie instalat mai întâi.

Instalare

Conectați-vă la sistem și urmați acești pași:

  1. Deschide o fereastră de terminal.
  2. Rulați comanda: sudo apt install libpam-google-authenticator.
  3. Introduceți parola sudo și apăsați Enter.
  4. Dacă vi se solicită confirmarea, tastați „y” și apăsați Enter.
  5. Așteptați finalizarea instalării.

Acum este timpul să vă configurați computerul pentru autentificarea cu doi factori.

Configurare

Reveniți la fereastra terminalului și introduceți comanda: sudo nano /etc/pam.d/common-auth. Adăugați următoarea linie la sfârșitul fișierului:

Salvați și închideți acest fișier.

Acum trebuie să configuram Google Authenticator pentru fiecare utilizator care ar trebui să aibă acces la sistem. Pentru a face acest lucru, trebuie să reveniți la fereastra terminalului și, în numele utilizatorului căruia intenționați să-i acordați acces, rulați comanda google-authenticator. Aici va trebui să răspundeți la câteva întrebări.

Prima întrebare este: „Doriți ca tokenurile de autentificare să fie bazate pe timp (da/n)”. Răspundeți „y” și vi se va da un cod QR. Deschideți aplicația cu doi factori pe smartphone, adăugați contși scanați acest cod QR.

Figura 1. Cod QR primit

După ce adăugați codul, mai sunt câteva întrebări de răspuns:

  • Doriți să vă actualizez fișierul „/home/jlwallen/.google_authenticator” (y/n) - Doriți să actualizez fișierul /home/jlwallen/.google_authenticator;
  • Doriți să interziceți mai multe utilizări ale aceluiași simbol de autentificare (da/n)? - Doriți să dezactivați capacitatea de a reutiliza un simbol de mai multe ori? Această setare permite o singură conectare la fiecare 30 de secunde. Dacă această opțiune este activată, șansele tale de a observa sau chiar de a preveni un atac de tip man-in-the-middle cresc.
  • Deoarece valoarea implicită este de 30 de secunde și timpii server și client pot diferi ușor, este posibil să utilizați un simbol suplimentar. Prin urmare, dacă aveți probleme cu sincronizarea, puteți crește durata ferestrei la aproximativ 4 minute. Vrei să faci asta? - Doriți să faceți acest lucru (da/n).
  • Dacă nu sunteți sigur că vă protejați computerul împotriva atacurilor de forță brută, puteți activa limitarea ratei pentru modulul de autentificare. În mod implicit, acesta este un maxim de 3 încercări de conectare la fiecare 30 de secunde. Doriți să activați limitarea vitezei? - Doriți să activați limitarea ratei (da/n)

Răspundeți afirmativ la fiecare întrebare introducând „y” și apăsând Enter.

Configurarea SSH

Următorul pas este să configurați SSH pentru a lucra autentificare cu doi factori. Dacă omiteți acest pas, nu vă veți putea conecta prin SSH.

Mai întâi trebuie să activați modulul PAM. Pentru a face acest lucru, tastați comanda: sudo nano /etc/pam.d/sshd. După deschiderea fișierului, adăugați următoarea linie la sfârșitul fișierului:

auth required pam_google_authenticator.so nullok

Salvați acest fișier și apoi executați comanda: sudo nano /etc/ssh/sshd_config. În acest fișier găsim:

ChallengeResponseAuthentication nr

Și schimbați-l în:

ChallengeResponseAuthentication da

Salvați acest fișier și reporniți sshd - sudo systemctl restart sshd.

Log in

Înainte de a vă deconecta, vă recomandăm insistent să deschideți o nouă fereastră de terminal și să încercați să vă conectați prin SSH. Dacă acest lucru nu reușește, repetați toți pașii de mai sus, asigurându-vă că nu ați ratat nimic. După ce v-ați conectat cu succes prin SSH, vă puteți deconecta și vă puteți conecta din nou.

concluzii

Am schimbat recent o parolă de utilizator în Linux când am întâlnit o eroare: Eroare de manipulare a simbolului de autentificare.

Am folosit comanda normală passwd pentru a schimba parola și ne-a dat această eroare și parola nu a fost schimbată.

Sudo passwd my_user_name Schimbarea parolei pentru utilizator my_user_name Schimbarea parolei pentru tecmint (actuala) Parola UNIX: passwd: Eroare de manipulare a simbolului de autentificare passwd: parola neschimbată

Remedierea erorii de manipulare a simbolului de autentificare în Ubuntu

„Eroare de manipulare a simbolului de autentificare” înseamnă că, dintr-un motiv oarecare, schimbarea parolei a eșuat.

Pot exista mai multe motive pentru aceasta. În cazuri simple, veți vedea cauza principală a problemei în rezultatul în sine. De exemplu, dacă nu ați furnizat o parolă, ar trebui să o vedeți într-o eroare:

Nicio parolă furnizată passwd: Eroare de manipulare a simbolului de autentificare passwd: parola neschimbată

De asemenea, dacă reintroducerea parolei nu se potrivește, va afișa și aceste informații:

Ne pare rău, parolele nu se potrivesc passwd: Eroare de manipulare a simbolului de autentificare passwd: parola neschimbată

Este ușor pentru că știți ce a cauzat problema și puteți lua măsuri corective pe baza acesteia. Dar s-ar putea să nu fii întotdeauna norocos pentru că în unele cazuri nu vei vedea niciunul Informatii utile, doar o eroare.

Să ne uităm la unele dintre aceste cazuri și să remediem această problemă.

Metoda 1

Dacă sunteți familiarizat cu structura de directoare Linux, știți că directorul /etc/shadow stochează parola într-un format criptat împreună cu alte informații despre utilizatori și parolele acestora.

Acesta este motivul pentru care trebuie să vă asigurați că aveți permisiunea de a citi și scrie în acest fișier. Deoarece veți schimba parola ca superutilizator, acest fișier trebuie să aibă permisiuni de citire și scriere pentru root.

Dacă nu este, trebuie să setați rezoluția corectă:

Sudo chmod 640 /etc/shadow

Metoda 2

Metoda 1 va funcționa în majoritatea cazurilor. Dar, în cazul nostru, a trebuit să remontăm partiția rădăcină cu permisiuni de citire și scriere. Am încercat să resetam parola de administrator în Ubuntu.

Mount -rw -o remount /

În unele cazuri rare, discul dumneavoastră poate fi atât de plin încât nu veți putea face nicio modificare în fișierul /etc/shadow. Dar dacă acesta este cazul, atunci te vei confrunta cu multe alte probleme.

A funcționat asta pentru tine?

Am împărtășit ceea ce a funcționat pentru noi și nu putem decât să sperăm că funcționează și pentru tine. ai facut-o? Care metodă a funcționat pentru tine? Menționați-l în comentarii.

Din 2020, utilizarea criptării în conformitate cu GOST R 34.10-2001 va fi interzisă, ceea ce înseamnă că toate organizațiile care interacționează cu agențiile guvernamentale sunt obligate să implementeze de urgență următorul standard - 2012. Dacă lucrați într-unul dintre ele, atunci nu treceți: în acest articol vom vorbi despre cum să rezolvați problema folosind un server pe CentOS 7 și Pachetul CryptoPro JCP.

Dacă este prima dată când auziți despre toate acestea, atunci iată un mic context istoric.

În 1994, FSB a dezvoltat o serie de standarde și măsuri menite să protejeze schimbul de documente între organizații și alți participanți la acest proces. Una dintre aceste măsuri de securitate a fost semnătura digitală electronică a documentelor, iar unul dintre standarde a fost GOST R 34.10-94, care descrie algoritmul de generare și verificare electronică. semnatura digitala. Adoptată și pusă în aplicare prin decretul Standardului de stat al Rusiei din 23 mai 1994, numărul 154, a funcționat până în 2001.

A fost înlocuit cu bine-cunoscutul GOST R 34.10-2001 - un standard îmbunătățit conceput pentru a asigura o mai mare stabilitate a algoritmului. Dar timpul nu stă pe loc, algoritmii și metodele de protecție criptografică se schimbă, iar unsprezece ani mai târziu, GOST R 34.10-2001 este schimbat în GOST R 34.10-2012.

În noul standard, prima versiune a cerințelor parametrilor rămâne aceeași. Lungimea cheii secrete este de aproximativ 256 de biți și este posibil să utilizați o funcție hash cu o lungime a codului hash de 256 sau 512 biți. Principala diferență între noul standard este opțiunile cu parametri suplimentariși scheme, inclusiv hashing conform standardului GOST R 34.11-2012 „Stribog”.

INFO

Stribog este zeul vechilor slavi, care patronează vânturile, vremea și tot ce ține de spațiul aerian. Poate tehnologii cloud La fel. Citiți mai multe despre acest cifr în articolele „” și „”.

În februarie 2014, FSB a anunțat începerea tranziției la utilizarea noului standard național GOST R 34.10-2012 în mijloace semnatura electronica pentru informatiile care nu contin informatii care constituie secret de stat. A fost publicat documentul cu numărul 149/7/1/3-58 din 31 ianuarie 2014 „Cu privire la procedura de trecere la utilizarea noilor standarde de semnătură digitală și funcții de hashing” care stabilește următoarele cerințe.

  1. După 31 decembrie 2013, încetați certificarea instrumentelor de semnătură electronică pentru conformitatea cu cerințele pentru instrumentele de semnătură electronică aprobate prin Ordinul nr. 796 al FSB al Rusiei din 27 decembrie 2011, dacă aceste instrumente nu prevăd implementarea funcțiilor în conformitate cu cu GOST R 34.10-2012.
  2. După 31 decembrie 2018, interziceți utilizarea GOST R 34.10-2001 pentru generarea unei semnături electronice.

Ministerul Comunicațiilor a creat chiar și un plan pentru trecerea la standard (PDF). Cu toate acestea, în practică s-a dovedit că totul nu este atât de simplu, iar tranziția a trebuit să fie amânată până la 31 decembrie 2019. Motivele sunt următoarele.

  1. Multe autorități de stat și municipale nu sunt pregătite să treacă la noul standard de semnătură electronică GOST-2012 din cauza lipsei de suport la nivel de software.
  2. Pentru a emite noi certificate, aveți nevoie de echipamente care să accepte GOST nou, și un certificat de la Autoritatea de certificare principală, generat folosind GOST-2012. Centrele de certificare l-au primit abia în vara anului 2018. Este nevoie de timp suplimentar pentru a emite certificate pentru toți utilizatorii.

În prezent, sunt utilizate două standarde de protecție criptografică: Munca EDS, dar cei care folosesc GOST-2001 trebuie urgent să facă ceva. Iarna, după cum se spune, vine și asta înseamnă că ne așteaptă o serie de teste atunci când implementăm suportul pentru GOST-2012.

Vă voi spune cum să implementați un instrument CIPF certificat de FSB (CryptoPro JCP) pe un server Linux care rulează Java JDK. Apropo, dacă încă utilizați GOST-2001, există unul minunat pe site-ul web CryptoPro, vă sfătuiesc să îl citiți, nu va fi de prisos.

Tot fluxul de documente între participanții la schimb are loc conform principiului SMEV (sistem de interacțiune electronică interdepartamentală). O aplicație poate fi un participant la un astfel de sistem, dar poate să nu fie deloc un participant; acest lucru nu schimbă principiul schimbului de documente. Pentru ușurință de înțelegere, am desenat o diagramă mică.


Preturi

Ca întotdeauna, se pune problema licențierii unei soluții software. CryptoPro JCP nu este ieftin, iar dacă o stație de lucru costă 1.200 de ruble, atunci licențele de server sunt mult mai scumpe - aproximativ 30.000 pentru fiecare nucleu (sau două nuclee). procesor Intel cu Hyper Threading dezactivat).

Instalarea și configurarea unui furnizor de cripto

În exemplele pe care le voi folosi mașină virtuală cu CentOS 7, dar alegerea dvs. nu este limitată hardwareȘi distribuție Linux. Toate acțiunile și comenzile vor fi aceleași.

În primul rând, să creăm un utilizator local sub care va rula software-ul care utilizează semnarea documentelor.

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

Să instalăm corect Java JDK. Descărcați distribuția necesară.

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

Despachetați arhiva și verificați dacă folderul Java este gata pentru copiere.

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

Copiați folderul în secțiunea aplicației software. De obicei folosesc /opt .

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

Verificăm dacă a fost copiat corect. Dacă este necesar, schimbați proprietarul folderului în 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;

Ne înregistrăm variabile de mediu pentru Java JDK pentru toți utilizatorii în mod implicit.

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

Scriem în fișier următoarele:

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/jre

Dacă serverul are mai multe versiuni ale Java JDK, atunci este necesar să se înregistreze alternative pentru versiune noua.

$ 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 $ alternative sudo --set javac /opt/jdk1.8.0_191/bin/javac $ alternative sudo --config java

În meniu, selectați opțiunea 2 (sau cea care va duce la utilizarea unei mai noi versiuni Java). Nu uitați să corectați drepturile la JRE systemPrefs.

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

Control versiunea instalată Java.

$ java -versiune
versiunea java „1.8.0_191”
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
VM server Java HotSpot(TM) pe 64 de biți (build 25.191-b12, mod mixt)

Copiați folderul cu kitul de distribuție CryptoPro JCP în secțiunea de software de aplicație.

$ sudo cp -rf jcp-2.0.40035 /opt/

Verificăm dacă totul a fost copiat corect.

$ ls -al /opt/jcp-2.0.40035/

Acordăm drepturi de a rula scripturi.

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

Verificăm proprietarul și drepturile asupra folderului, acesta trebuie să fie root. Să intrăm în asta.

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

Pentru a evita problemele de instalare, verificați numărul de nuclee de pe procesor și verificați licența. Puteți afla numărul de nuclee cu comanda nproc.

Să trecem la instalarea furnizorului cripto JCP. În timpul instalării, va trebui să răspundeți la o serie de întrebări.

Continuarea este disponibilă numai pentru membri

Opțiunea 1. Alăturați-vă comunității „site” pentru a citi toate materialele de pe site

Calitatea de membru al comunității în perioada specificată vă va oferi acces la TOATE materialele Hacker, vă va crește discountul cumulat personal și vă va permite să acumulați un rating profesional Xakep Score!