Cum se configurează autentificarea cu mai mulți factori pentru SSH pe CentOS 7

Introducere

Un factor de autentificare este o singură informație utilizată pentru a dovedi că aveți drepturile de a efectua o acțiune, cum ar fi conectarea la un sistem. Un canal de autentificare este modul în care un sistem de autentificare livrează un factor utilizatorului sau solicită utilizatorului să răspundă. Parolele și token-urile de securitate sunt exemple de factori de autentificare; computerele și telefoanele sunt exemple de canale.

SSH utilizează în mod implicit parolele pentru autentificare, iar majoritatea instrucțiunilor de întărire SSH recomandă în schimb utilizarea unei chei SSH. Cu toate acestea, acesta este totuși doar un singur factor. Dacă un actor rău v-a compromis calculatorul, atunci vă poate folosi cheia pentru a vă compromite și serverele.

În acest tutorial, vom configura autentificarea cu mai mulți factori pentru a combate acest lucru. Autentificarea cu mai mulți factori (MFA) necesită mai mult de un factor pentru a se autentifica, sau pentru a se conecta. Acest lucru înseamnă că un actor rău ar trebui să compromită mai multe lucruri, cum ar fi atât calculatorul, cât și telefonul, pentru a intra. Diferitele tipuri de factori sunt adesea rezumate astfel:

1. Ceva pe care îl știți, cum ar fi o parolă sau o întrebare de securitate
2. Ceva pe care îl aveți, cum ar fi o aplicație de autentificare sau un token de securitate
3. Ceva care sunteți, cum ar fi amprenta dvs. digitală sau vocea

Un factor comun este o aplicație OATH-TOTP, cum ar fi Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) este un protocol deschis care generează o parolă cu utilizare unică, de obicei un număr de 6 cifre care se reciclează la fiecare 30 de secunde.

Acest articol va trece în revistă modul în care se poate activa autentificarea SSH folosind o aplicație OATH-TOTP în plus față de o cheie SSH. Conectarea la serverul dvs. prin SSH va necesita atunci doi factori pe două canale, făcându-l astfel mai sigur decât o parolă sau o cheie SSH singură. În plus, vom trece în revistă câteva cazuri de utilizare suplimentare pentru MFA și câteva sfaturi și trucuri utile.

Precondiții

Pentru a urma acest tutorial, veți avea nevoie de:

• Un server CentOS 7 cu un utilizator sudo non-root și o cheie SSH, pe care îl puteți configura urmând acest tutorial de configurare inițială a serverului.
• Un smartphone sau o tabletă cu o aplicație OATH-TOTP instalată, cum ar fi Google Authenticator (iOS, Android).

Pasul 1 – Instalarea PAM de la Google

În acest pas, vom instala și configura PAM de la Google.

PAM, care înseamnă Pluggable Authentication Module, este o infrastructură de autentificare utilizată pe sistemele Linux pentru a autentifica un utilizator. Deoarece Google a realizat o aplicație OATH-TOTP, a realizat și un PAM care generează TOTP-uri și este complet compatibil cu orice aplicație OATH-TOTP, cum ar fi Google Authenticator sau Authy.

În primul rând, trebuie să adăugăm repo-ul EPEL (Extra Packages for Enterprise Linux).

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

În continuare, instalați PAM-ul. Este posibil să vi se ceară să acceptați cheia EPEL dacă este prima dată când folosiți repo-ul. Odată acceptată, nu vi se va mai solicita din nou să acceptați cheia.

sudo yum install google-authenticator

Cu PAM-ul instalat, vom folosi o aplicație ajutătoare care vine cu PAM pentru a genera o cheie TOTP pentru utilizatorul căruia doriți să îi adăugați un al doilea factor. Această cheie este generată pentru fiecare utilizator în parte, nu la nivelul întregului sistem. Acest lucru înseamnă că fiecare utilizator care dorește să utilizeze o aplicație de autentificare TOTP va trebui să se conecteze și să ruleze aplicația ajutătoare pentru a-și obține propria cheie; nu o puteți rula o singură dată pentru a o activa pentru toată lumea (dar există câteva sfaturi la sfârșitul acestui tutorial pentru a configura sau a solicita MFA pentru mai mulți utilizatori).

Rulați aplicația de inițializare.

google-authenticator

După ce veți rula comanda, vi se vor pune câteva întrebări. Prima întreabă dacă jetoanele de autentificare ar trebui să fie bazate pe timp.

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

Acest PAM permite jetoane bazate pe timp sau secvențiale. Folosind jetoane bazate pe secvențialitate înseamnă că codul începe de la un anumit punct și apoi îl incrementează după fiecare utilizare. Utilizarea jetoanelor bazate pe timp înseamnă că codul se schimbă aleatoriu după ce trece un anumit interval de timp. Vom rămâne la varianta bazată pe timp, deoarece aceasta este cea pe care o anticipează aplicații precum Google Authenticator, așa că răspundeți y pentru da.

După ce ați răspuns la această întrebare, vor defila o mulțime de rezultate, inclusiv un cod QR mare. În acest moment, utilizați aplicația Authenticator de pe telefon pentru a scana codul QR sau introduceți manual cheia secretă. Dacă codul QR este prea mare pentru a fi scanat, puteți utiliza URL-ul de deasupra codului QR pentru a obține o versiune mai mică. După ce este adăugat, veți vedea un cod din șase cifre care se schimbă la fiecare 30 de secunde în aplicația dumneavoastră.

Nota: Asigurați-vă că înregistrați cheia secretă, codul de verificare și codurile de recuperare într-un loc sigur, cum ar fi un manager de parole. Codurile de recuperare sunt singura modalitate de a redobândi accesul în cazul în care, de exemplu, pierdeți accesul la aplicația TOTP.

Întrebările rămase informează PAM despre modul de funcționare. Le vom parcurge pe rând.

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

Aceasta scrie cheia și opțiunile în fișierul .google_authenticator. Dacă spuneți nu, programul se oprește și nu se scrie nimic, ceea ce înseamnă că autentificatorul nu va funcționa.

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

Răspunzând da aici, preveniți un atac prin reluare, făcând ca fiecare cod să expire imediat după utilizare. Acest lucru împiedică un atacator să captureze un cod pe care tocmai l-ați folosit și să se logheze cu el.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Răspunzând da aici permite până la 8 coduri valide într-o fereastră mobilă de patru minute. Răspunzând nu, îl limitați la 3 coduri valide într-o fereastră mobilă de 1:30 minute. Cu excepția cazului în care găsiți probleme cu fereastra de 1:30 minute, răspunsul nu este alegerea mai sigură.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin 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

Limitarea ratei înseamnă că un atacator de la distanță poate încerca doar un anumit număr de încercări înainte de a fi blocat. Dacă nu ați configurat anterior limitarea vitezei direct în SSH, a face acest lucru acum este o tehnică excelentă de întărire.

Nota: După ce ați terminat această configurare, dacă doriți să faceți o copie de siguranță a cheii secrete, puteți copia fișierul ~/.google-authenticator într-o locație de încredere. De acolo, îl puteți implementa pe sisteme suplimentare sau îl puteți redistribui după o copie de rezervă.

Acum că PAM de la Google este instalat și configurat, următorul pas este să configurați SSH pentru a utiliza cheia dvs. TOTP. Va trebui să îi spunem lui SSH despre PAM și apoi să configurăm SSH pentru a-l utiliza.

Pasul 2 – Configurarea OpenSSH

Pentru că vom face modificări SSH prin SSH, este important să nu închideți niciodată conexiunea SSH inițială. În schimb, deschideți o a doua sesiune SSH pentru a face teste. Acest lucru este pentru a evita să vă blocați din server dacă a existat o greșeală în configurația SSH. Odată ce totul funcționează, atunci puteți închide în siguranță orice sesiune.

Pentru a începe, vom edita fișierul de configurare sshd. Aici, folosim nano, care nu este instalat în mod implicit pe CentOS. Îl puteți instala cu sudo yum install nano, sau puteți folosi editorul de text alternativ preferat.

sudo nano /etc/pam.d/sshd

Adaugați următoarea linie în partea de jos a fișierului.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Vorba nullok de la sfârșitul ultimei linii îi spune lui PAM că această metodă de autentificare este opțională. Acest lucru permite utilizatorilor care nu au un token OATH-TOTP să se conecteze în continuare folosind cheia SSH. Odată ce toți utilizatorii au un token OATH-TOTP, puteți elimina nullok de pe această linie pentru a face MFA obligatorie.

Salvați și închideți fișierul.

În continuare, vom configura SSH pentru a suporta acest tip de autentificare. Deschideți fișierul de configurare SSH pentru editare.

sudo nano /etc/ssh/sshd_config

Cercetați liniile ChallengeResponseAuthentication. Comentați linia no și decomentați linia no.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Salvați și închideți fișierul, apoi reporniți SSH pentru a reîncărca fișierele de configurare. Repornirea serviciului sshd nu va închide conexiunile deschise, așa că nu veți risca să vă blocați cu această comandă.

sudo systemctl restart sshd.service

Pentru a testa dacă totul funcționează până acum, deschideți un alt terminal și încercați să vă conectați prin SSH. Dacă ați creat anterior o cheie SSH și o utilizați, veți observa că nu a trebuit să introduceți parola utilizatorului dvs. sau codul de verificare MFA. Acest lucru se datorează faptului că o cheie SSH anulează în mod implicit toate celelalte opțiuni de autentificare. În caz contrar, ar fi trebuit să primiți o solicitare de parolă și cod de verificare.

Dacă doriți să vă asigurați că ceea ce ați făcut până acum funcționează, în sesiunea SSH deschisă navigați la ~/.ssh/ și redenumiți fișierul authorized_keys, temporar, și deschideți o nouă sesiune și conectați-vă cu parola și codul nostru de verificare.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

După ce ați verificat că token-ul TOTP funcționează redenumiți fișierul ‘authorized_keys.bak’ înapoi la ceea ce a fost.

mv authorized_keys.bak authorized_keys

În continuare, trebuie să activăm o cheie SSH ca un factor și codul de verificare ca al doilea și să îi spunem lui SSH ce factori să folosească și să împiedicăm cheia SSH să prevină ca cheia SSH să prevaleze asupra tuturor celorlalte tipuri.

Pasul 3 – A face ca SSH să fie conștient de MFA

Deschideți din nou fișierul de configurare sshd.

sudo nano /etc/ssh/sshd_config

Adaugați următoarea linie în partea de jos a fișierului. Aceasta indică SSH ce metode de autentificare sunt necesare. Această linie îi spune lui SSH că avem nevoie de o cheie SSH și fie o parolă, fie un cod de verificare (sau toate trei).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Salvați și închideți fișierul.

În continuare, deschideți din nou fișierul de configurare PAM sshd.

sudo nano /etc/pam.d/sshd

Găsiți linia auth substack password-auth spre partea de sus a fișierului. Comentați-o adăugând un caracter # ca prim caracter pe linie. Acest lucru îi spune lui PAM să nu solicite o parolă.

. . .#auth substack password-auth. . .

Salvați și închideți fișierul, apoi reporniți SSH.

sudo systemctl restart sshd.service

Acum încercați să vă conectați din nou la server cu o sesiune diferită. Spre deosebire de data trecută, SSH ar trebui să vă ceară codul de verificare. După ce îl introduceți, veți fi conectat. Chiar dacă nu vedeți nicio indicație că a fost folosită cheia dvs. SSH, încercarea dvs. de conectare a folosit doi factori. Dacă doriți să verificați, puteți adăuga -v (pentru verbose) după comanda SSH:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Pe la sfârșitul ieșirii, veți vedea unde SSH utilizează cheia dvs. SSH și apoi vă cere codul de verificare. Acum puteți să vă conectați prin SSH cu o cheie SSH și o parolă unică. Dacă doriți să aplicați toate cele trei tipuri de autentificare, puteți urma următorul pas.

Etapa 4 – Adăugarea unui al treilea factor (opțional)

În etapa 3, am enumerat tipurile de autentificare aprobate în fișierul sshd_config:

1. publickey (cheie SSH)
2. password publickey (parolă)
3. keyboard-interactive (cod de verificare)

Deși am enumerat trei factori diferiți, cu opțiunile pe care le-am ales până acum, acestea permit doar o cheie SSH și codul de verificare. Dacă doriți să aveți toți cei trei factori (cheie SSH, parolă și cod de verificare), o modificare rapidă îi va activa pe toți trei.

Deschideți fișierul de configurare PAM sshd.

sudo nano /etc/pam.d/sshd

Localizați linia pe care ați comentat-o anterior, #auth substack password-auth, și decomentați linia prin eliminarea caracterului #. Salvați și închideți fișierul. Acum, încă o dată, reporniți SSH.

sudo systemctl restart sshd.service

Prin activarea opțiunii auth substack password-auth, PAM va solicita acum o parolă în plus față de verificarea unei chei SSH și solicitarea unui cod de verificare, care au funcționat anterior. Acum putem folosi ceva ce știm (parola) și două tipuri diferite de lucruri pe care le avem (cheia SSH și codul de verificare) pe două canale diferite.

Până acum, acest articol a subliniat cum să activăm MFA cu o cheie SSH și o parolă unică bazată pe timp. Dacă acest lucru este tot ce aveți nevoie, puteți încheia aici. Cu toate acestea, aceasta nu este însă singura modalitate de a face autentificare multifactorială. Mai jos sunt prezentate câteva modalități suplimentare de utilizare a acestui modul PAM pentru autentificarea multifactorială și câteva sfaturi și trucuri pentru recuperare, utilizare automată și multe altele.

Tip 1 – Recuperarea accesului

Ca și în cazul oricărui sistem pe care îl întăriți și securizați, deveniți responsabil pentru gestionarea acestei securități. În acest caz, asta înseamnă să nu vă pierdeți cheia SSH sau cheia secretă TOTP și să vă asigurați că aveți acces la aplicația TOTP. Cu toate acestea, uneori se întâmplă lucruri și puteți pierde controlul asupra cheilor sau aplicațiilor de care aveți nevoie pentru a intra.

Pierderea unei chei SSH sau a unei chei secrete TOTP

Dacă vă pierdeți cheia SSH sau cheia secretă TOTP, recuperarea poate fi împărțită în câțiva pași. Primul este de a intra din nou fără a cunoaște codul de verificare și al doilea este de a găsi cheia secretă sau de a o regenera pentru o autentificare MFA normală.

Pentru a intra după ce ați pierdut cheia secretă care generează codul de verificare pe un Droplet DigitalOcean, puteți folosi pur și simplu consola virtuală din tabloul dvs. de bord pentru a vă autentifica folosind numele de utilizator și parola.

În caz contrar, veți avea nevoie de un utilizator administrativ care are acces sudo; asigurați-vă că nu activați MFA pentru acest utilizator, ci folosiți doar o cheie SSH. Dacă dvs. sau un alt utilizator își pierde cheia secretă și nu se poate conecta, atunci utilizatorul administrativ se poate conecta și poate ajuta la recuperarea sau regenerarea cheii pentru orice utilizator care utilizează sudo.

După ce v-ați conectat, există două modalități de a ajuta la obținerea secretului TOTP:

1. Recuperarea cheii existente
2. Generarea unei chei noi

În directorul principal al fiecărui utilizator, cheia secretă și setările Google Authenticator sunt salvate în ~/.google-authenticator. Prima linie din acest fișier este o cheie secretă. O modalitate rapidă de a obține cheia este de a executa următoarea comandă, care afișează prima linie a fișierului google-authenticator (adică cheia secretă). Apoi, luați acea cheie secretă și tastați-o manual într-o aplicație TOTP.

head -n 1 /home/sammy/.google_authenticator

Dacă există un motiv pentru a nu utiliza cheia existentă (de exemplu, neputând partaja cu ușurință și în siguranță cheia secretă cu utilizatorul afectat sau cheia existentă a fost compromisă), puteți elimina complet fișierul ~/.google-authenticator. Acest lucru va permite utilizatorului să se conecteze din nou folosind un singur factor, presupunând că nu ați impus MFA prin eliminarea lui „nullok” din fișierul „/etc/pam.d/sshd”. Aceștia pot rula apoi google-authenticator pentru a genera o nouă cheie.

Pierderea accesului la aplicația TOTP

Dacă aveți nevoie să vă conectați la serverul dvs. dar nu aveți acces la aplicația TOTP pentru a obține codul de verificare, vă puteți conecta în continuare folosind codurile de recuperare care au fost afișate atunci când ați creat prima dată cheia secretă. Rețineți că aceste coduri de recuperare se utilizează o singură dată. Odată ce unul este folosit pentru a vă conecta, nu mai poate fi folosit din nou ca și cod de verificare.

Tip 2 – Modificarea setărilor de autentificare

Dacă doriți să vă modificați setările MFA după configurarea inițială, în loc să generați o nouă configurație cu setările actualizate, puteți edita pur și simplu fișierul ~/.google-authenticator. Acest fișier este structurat în felul următor:

<secret key><options><recovery codes>

Opțiunile care sunt setate în acest fișier au o linie în secțiunea opțiuni; dacă ați răspuns „nu” la o anumită opțiune în timpul configurării inițiale, linia corespunzătoare este exclusă din fișier.

Iată care sunt modificările pe care le puteți face în acest fișier:

• Pentru a permite coduri secvențiale în loc de coduri bazate pe timp, modificați linia " TOTP_AUTH în " HOTP_COUNTER 1.
• Pentru a permite utilizări multiple ale unui singur cod, eliminați linia " DISALLOW_REUSE.
• Pentru a extinde fereastra de expirare a codurilor la 4 minute, adăugați linia " WINDOW_SIZE 17.
• Pentru a dezactiva autentificările multiple eșuate (limitarea ratei), eliminați linia " RATE_LIMIT 3 30.
• Pentru a modifica pragul de limitare a ratei, găsiți linia " RATE_LIMIT 3 30 și ajustați numerele. 3 din original indică numărul de încercări pe o perioadă de timp, iar 30 indică perioada de timp în secunde.
• Pentru a dezactiva utilizarea codurilor de recuperare, eliminați cele cinci coduri de 8 cifre din partea de jos a fișierului.

Tip 3 – Evitarea MFA pentru unele conturi

Poate exista o situație în care un singur utilizator sau câteva conturi de servicii (adică conturi utilizate de aplicații, nu de oameni) au nevoie de acces SSH fără ca MFA să fie activat. De exemplu, este posibil ca unele aplicații care utilizează SSH, cum ar fi unii clienți FTP, să nu suporte MFA. Dacă o aplicație nu are o modalitate de a solicita codul de verificare, cererea se poate bloca până când conexiunea SSH se termină.

Atâta timp cât câteva opțiuni din /etc/pam.d/sshd sunt setate corect, puteți controla ce factori sunt utilizați pentru fiecare utilizator în parte.

Pentru a permite MFA pentru unele conturi și numai cheia SSH pentru altele, asigurați-vă că următoarele setări din /etc/pam.d/sshd sunt active.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Aici, auth substack password-auth este comentat deoarece parolele trebuie să fie dezactivate. MFA nu poate fi forțat dacă unele conturi sunt menite să aibă MFA dezactivat, așa că lăsați opțiunea nullok pe ultima linie.

După ce ați setat această configurație, rulați pur și simplu google-authenticator ca orice utilizator care are nevoie de MFA și nu o rulați pentru utilizatorii pentru care vor fi folosite doar chei SSH.

Tip 4 – Automatizarea instalării cu managementul configurației

Mulți administratori de sistem folosesc instrumente de management al configurației, cum ar fi Puppet, Chef sau Ansible, pentru a-și gestiona sistemele. Dacă doriți să folosiți un astfel de sistem pentru a instala configurarea unei chei secrete la crearea unui nou cont de utilizator, există o metodă pentru a face acest lucru.

google-authenticator suportă comutatoare de linie de comandă pentru a seta toate opțiunile într-o singură comandă, neinteractivă. Pentru a vedea toate opțiunile, puteți tasta google-authenticator --help. Mai jos este comanda care ar configura totul așa cum a fost prezentat în Pasul 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Aceasta răspunde la toate întrebările la care am răspuns manual, le salvează într-un fișier și apoi scoate cheia secretă, codul QR și codurile de recuperare. (Dacă adăugați stegulețul -q, atunci nu va exista nicio ieșire.) Dacă utilizați această comandă într-un mod automatizat, asigurați-vă că capturați cheia secretă și/sau codurile de recuperare și că le puneți la dispoziția utilizatorului.

Tip 5 – Forțarea MFA pentru toți utilizatorii

Dacă doriți să forțați MFA pentru toți utilizatorii chiar și la prima autentificare, sau dacă preferați să nu vă bazați pe faptul că utilizatorii dvs. își generează propriile chei, există o modalitate ușoară de a rezolva acest lucru. Puteți utiliza pur și simplu același fișier .google-authenticator pentru fiecare utilizator, deoarece în fișier nu sunt stocate date specifice fiecărui utilizator.

Pentru a face acest lucru, după ce fișierul de configurare este creat inițial, un utilizator privilegiat trebuie să copieze fișierul în rădăcina fiecărui director principal și să îi schimbe permisiunile la utilizatorul corespunzător. De asemenea, puteți copia fișierul în /etc/skel/ astfel încât acesta să fie copiat automat în directorul personal al unui nou utilizator la creare.

Atenție: Acest lucru poate fi un risc de securitate, deoarece toată lumea împarte același al doilea factor. Acest lucru înseamnă că, dacă este scăpat, este ca și cum fiecare utilizator ar avea un singur factor. Luați acest lucru în considerare dacă doriți să folosiți această abordare.

O altă metodă de a forța crearea cheii secrete a unui utilizator este de a folosi un script bash care:

1. Creează un token TOTP,
2. Îndeamnă utilizatorii să descarce aplicația Google Authenticator și să scaneze codul QR care va fi afișat și
3. Execută aplicația google-authenticator pentru ei după ce verifică dacă fișierul .google-authenticator există deja.

Pentru a vă asigura că scriptul rulează atunci când un utilizator se conectează, îl puteți numi .bash_login și îl puteți plasa la rădăcina directorului lor personal.

Concluzie

Acestea fiind spuse, având doi factori (o cheie SSH + un token MFA) pe două canale (computerul + telefonul), ați făcut foarte dificil pentru un agent extern să intre prin forță brută în mașina dvs. prin SSH și ați sporit foarte mult securitatea mașinii dvs.

.