ProHoster >> Lëshimi i OpenSSH 8.2 me mbështetje për tokenët e autentifikimit dy-faktorësh FIDO/U2F

Lëshimi i OpenSSH 8.2 me mbështetje për tokenët e autentifikimit dy-faktorësh FIDO/U2F

Pas katër muajsh zhvillimi është paraqitur lëshimi OpenSSH 8.2, implementimi i hapur i klientit dhe serverit për të punuar me protokollet SSH 2.0 dhe SFTP.

Përmirësimi kryesor në lëshimin e OpenSSH 8.2 është mundësia e përdorimit të autentifikimit dy-faktosh nëpërmjet pajisjeve që mbështesin protokollin U2F, i zhvilluar nga aleanca FIDO. U2F lejon krijimin e tokeneve të lira harduerike për të konfirmuar praninë fizike të përdoruesit, me të cilat ndërveprohet përmes USB, Bluetooth ose NFC. Pajisje të tilla promovohen si një mjet për autentikim me dy faktorë në faqe, tashmë mbështeten nga shfletuesit kryesorë dhe lëshohen nga prodhues të ndryshëm, duke përfshirë Yubico, Feitian, Thetis dhe Kensington.

Për të ndërvepruar me pajisjet që konfirmojnë praninë e përdoruesit, OpenSSH ka shtuar lloje të reja çelësash "ecdsa-sk" dhe "ed25519-sk", të cilat përdorin algoritmet e nënshkrimit dixhital ECDSA dhe Ed25519, në kombinim me hash-in SHA-256. Procedurat e ndërveprimit me tokenët janë zhvendosur në një bibliotekë ndërmjetëse, e cila ngarkohet në mënyrë të ngjashme me bibliotekën për mbështetje PKCS#11 dhe është një mbështetje mbi bibliotekën. libfido2, që ofron mjete për komunikim me tokenet mbi USB (mbështet protokollet FIDO U2F/CTAP 1 dhe FIDO 2.0/CTAP 2). Biblioteka ndërmjetëse e përgatitur nga zhvilluesit e OpenSSH libsk-libfido2 u përfshi si pjesë thelbësore e libfido2, ashtu si drejtuesi HID për OpenBSD.

PĂ«r autentifikim dhe gjenerimin e çelĂ«sit, Ă«shtĂ« e nevojshme tĂ« specifikoni nĂ« configurim parametrin "SecurityKeyProvider" ose tĂ« vendosni variablĂ«n e ambientit SSH_SK_PROVIDER, duke caktuar rrugĂ«n pĂ«r bibliotekĂ«n e jashtme libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). ËshtĂ« e mundur tĂ« ndĂ«rtohet openssh me mbĂ«shtetje tĂ« integruar pĂ«r bibliotekĂ«n e ndĂ«rmjetme (—with-security-key-builtin), nĂ« kĂ«tĂ« rast Ă«shtĂ« e nevojshme tĂ« vendosni parametrin "SecurityKeyProvider=internal".
Më pas, është e nevojshme të ekzekutoni «ssh-keygen -t ecdsa-sk» ose, nëse çelësat janë krijuar dhe konfiguruar tashmë, të lidheni me serverin duke përdorur «ssh». Kur ekzekutoni ssh-keygen, çifti i krijuar i çelësave do të ruhet në «~/.ssh/id_ecdsa_sk» dhe mund të përdoret në mënyrë të ngjashme me çelësat e tjerë.

ÇelĂ«si publik (id_ecdsa_sk.pub) duhet tĂ« kopjohet nĂ« server nĂ« skedarin authorized_keys. NĂ« anĂ«n e serverit, kontrollohet vetĂ«m nĂ«nshkrimi digjital, ndĂ«rsa ndĂ«rveprimi me tokenĂ«t kryhet nĂ« anĂ«n e klientit (nĂ« server nuk Ă«shtĂ« e nevojshme tĂ« instalohet libsk-libfido2, por serveri duhet tĂ« mbĂ«shtesĂ« tipin e çelĂ«save «ecdsa-sk»). ÇelĂ«si privat i krijuar (id_ecdsa_sk) nĂ« thelb Ă«shtĂ« njĂ« pĂ«rshkrues i çelĂ«sit, qĂ« formon çelĂ«sin real vetĂ«m nĂ« kombinim me sekuencĂ«n e fshehtĂ«, e cila ruhet nĂ« anĂ«n e tokenit U2F. NĂ« rast se çelĂ«si id_ecdsa_sk bie nĂ« duar tĂ« njĂ« sulmuesi, pĂ«r tĂ« kaluar autentikimin, atij do t'i nevojitet gjithashtu qasja nĂ« tokenin harduerik, pa tĂ« cilin çelĂ«si privat i ruajtur nĂ« skedarin id_ecdsa_sk Ă«shtĂ« i padobishĂ«m.

Për më tepër, nga defaulti, gjatë çdo operacioni me çelësat (si gjatë gjenerimit, ashtu edhe gjatë identifikimit) kërkohet një konfirmim lokal i pranishëm fizikisht nga përdoruesi, për shembull, duke ofruar të preket sensori në token, e cila e bën më të vështirë kryerjen e sulmeve të largëta në sistemet me token të lidhur. Si një barrierë tjetër mbrojtëse në fazën e nisjes, ssh-keygen gjithashtu mund të kërkojë një fjalëkalim për akses në skedarin e çelësit.

Në versionin e ri të OpenSSH, gjithashtu u shpall kalimi i algoritmeve që përdorin hash SHA-1 në statusin e të vjetruarve, në lidhje me rritjen e efikasitetit të sulmeve të kolizionit me një prefiks të caktuar (kostoja e gjenerimit të një kolizioni vlerësohet rreth 45 mijë dollarë). Në një nga botimet e ardhshme, planifikohet të shkëputet për default mundësia e përdorimit të algoritmit të nënshkrimit digjital me çelës publik «ssh-rsa», i cili përmendet në RFC origjinal për protokollet SSH dhe mbetet i përhapur gjerësisht në praktikë (për të kontrolluar përdorimin e ssh-rsa në sistemet e tij, mund të provohet lidhja me ssh me opsionin «-oHostKeyAlgorithms=-ssh-rsa»).

Për të lehtësuar kalimin në algoritme të reja në OpenSSH, në një nga versionet e ardhshme do të aktivizohet si parazgjedhje konfigurimi UpdateHostKeys, i cili do të lejojë automatikisht kalimin e klientëve në algorithmat më të sigurta. Mes algoritmeve të rekomanduara për migrim janë përmendur rsa-sha2-256/512 në bazë të RFC8332 RSA SHA-2 (i mbështetur nga OpenSSH 7.2 dhe përdorur si parazgjedhje), ssh-ed25519 (i mbështetur nga OpenSSH 6.5) dhe ecdsa-sha2-nistp256/384/521 në bazë të RFC5656 ECDSA (i mbështetur nga OpenSSH 5.7).

Në versionin OpenSSH 8.2, mundësia për t'u lidhur duke përdorur «ssh-rsa» ende është lënë, por ky algoritëm është hequr nga lista CASignatureAlgorithms, e cila përcakton algoritmet e lejueshme për nënshkrimin dixhital të certifikatave të reja. Po ashtu, nga algoritmet e mbështetur si parazgjedhje për shkëmbimin e çelësave është hequr algoritmi diffie-hellman-group14-sha1. Vlen të theksohet se përdorimi i SHA-1 në certifikata është i lidhur me rreziqe të tjera, pasi një sulmues ka kohë të pakufizuar për të gjetur një kolizion për një certifikatë ekzistuese, ndërsa koha e sulmit ndaj çelësave të hostit është e kufizuar nga kohëzgjatja e lidhjes (LoginGraceTime).

Kur krijoni ssh-keygen, tani përdoret si parazgjedhje algoritmi rsa-sha2-512, i cili mbështetet që nga OpenSSH 7.2, gjë që mund të krijojë probleme me kompatibilitetin kur përpiqeni të përpunoni certifikatat e nënshkruara në OpenSSH 8.2, në sisteme me versione më të vjetra të OpenSSH (për të anashkaluar këtë problem gjatë formimit të nënshkrimit, mund ta specifikoni hapur "ssh-keygen -t ssh-rsa" ose mund të përdorni algoritmet e ecdsa-sha2-nistp256/384/521, të mbështetur që nga OpenSSH 5.7).

Ndryshime të tjera:

  • NĂ« sshd_config Ă«shtĂ« shtuar direktiva Include, e cila lejon tĂ« pĂ«rfshihen pĂ«rmbajtjet e skedave tĂ« tjera nĂ« pozitat aktuale tĂ« skedarit tĂ« konfigurimit (kur pĂ«rcaktohet emri i skedarit, lejohet pĂ«rdorimi i maskave glob);
  • NĂ« ssh-keygen Ă«shtĂ« shtuar opsioni "no-touch-required", i cili çon nĂ« anulimin e nevojĂ«s pĂ«r konfirmimin fizik tĂ« aksesit nĂ« token gjatĂ« gjenerimit tĂ« çelĂ«sit;
  • NĂ« sshd_config Ă«shtĂ« shtuar direktiva PubkeyAuthOptions, e cila kombinon mundĂ«si tĂ« ndryshme qĂ« lidhen me autentifikimin pĂ«rmes çelĂ«save publik. Aktualisht mbĂ«shtetet vetĂ«m flamuri "no-touch-required" pĂ«r tĂ« anashkaluar verifikimin e pranishmĂ«risĂ« fizike gjatĂ« autorizimit pĂ«rmes tokenit. NĂ« mĂ«nyrĂ« analogjike, nĂ« skedarin authorized_keys Ă«shtĂ« shtuar opsioni "no-touch-required";
  • NĂ« ssh-keygen Ă«shtĂ« shtuar opsioni «-O write-attestation=/path», i cili lejon regjistrimin e certifikatave tĂ« tjera tĂ« vlerĂ«simit FIDO gjatĂ« gjenerimit tĂ« çelĂ«save. OpenSSH aktualisht nuk i pĂ«rdor kĂ«to certifikata, por ato mund tĂ« pĂ«rdoren nĂ« tĂ« ardhmen pĂ«r tĂ« verifikuar vendndodhjen e çelĂ«sit nĂ« njĂ« depo tĂ« besueshme harduerike;
  • NĂ« konfigurimet ssh dhe sshd, pĂ«rmes direktivĂ«s IPQoS tani Ă«shtĂ« e mundur tĂ« vendosni modin e prioritetit tĂ« trafikut. LE DSCP (Lower-Effort Per-Hop Behavior);
  • NĂ« ssh, kur vendosni vlerĂ«n «AddKeysToAgent=yes», nĂ«se çelĂ«si nuk pĂ«rmban njĂ« fushĂ« me koment, ai do tĂ« shtohet nĂ« ssh-agent me si koment rrugĂ«n e çelĂ«sit. NĂ«
    ssh-keygen dhe ssh-agent, si komente në çelës tashmë përdoren gjithashtu etiketat PKCS#11 dhe emri i subjektit X.509 në vend të rrugës së bibliotekës;
  • NĂ« ssh-keygen Ă«shtĂ« shtuar mundĂ«sia e eksportit PEM pĂ«r çelĂ«sat DSA dhe ECDSA;
  • ËshtĂ« shtuar njĂ« skedar i ri ekzekutues ssh-sk-helper, i pĂ«rdorur pĂ«r izolimin e bibliotekĂ«s pĂ«r qasje nĂ« tokenat FIDO/U2F;
  • NĂ« ssh dhe sshd Ă«shtĂ« shtuar opsioni i ndĂ«rtimit «—with-zlib» pĂ«r kompilim me mbĂ«shtetje pĂ«r bibliotekĂ«n zlib;
  • Sipas kĂ«rkesĂ«s RFC4253, banneri i shfaqur gjatĂ« lidhjes siguron njĂ« paralajmĂ«rim pĂ«r bllokimin e aksesit pĂ«r shkak tĂ« kalimit tĂ« kufijve MaxStartups. PĂ«r tĂ« thjeshtuar diagnostikimin, nĂ« titullin e procesit sshd, i dukshĂ«m kur pĂ«rdoret utilitari ps, Ă«shtĂ« siguruar shfaqja e numrit tĂ« lidhjeve aktualisht tĂ« autentikuara dhe gjendja e kufirit MaxStartups;
  • NĂ« ssh dhe ssh-agent, kur thirret programi pĂ«r tĂ« shfaqur njĂ« pyetje, e cila ceket pĂ«rmes $SSH_ASKPASS, tani transmetohet gjithashtu njĂ« flamur me llojin e pyetjes: «confirm» — dialog konfirmimi (po/jo), «none» — mesazh informues, «blank» — kĂ«rkesĂ« pĂ«r fjalĂ«kalim;
  • NĂ« ssh-keygen Ă«shtĂ« shtuar njĂ« operacion i ri me nĂ«nshkrime digjitale «find-principals» pĂ«r tĂ« kĂ«rkuar nĂ« skedarin allowed-signers tĂ« pĂ«rdoruesit, i lidhur me nĂ«nshkrimin digjital tĂ« specifikuar;
  • ËshtĂ« pĂ«rmirĂ«suar mbĂ«shtetja pĂ«r izolimin e procesit sshd nĂ« Linux pĂ«rmes mekanizmit seccomp: janĂ« ndaluar thirrjet sistemore IPC, janĂ« lejuar clock_gettime64(), clock_nanosleep_time64 dhe clock_nanosleep().

Burimi: opennet.ru

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster