Paglabas ng OpenSSH 8.2 na may suporta para sa FIDO/U2F two-factor authentication token

Pagkatapos ng apat na buwan ng pag-unlad ipinakita pakawalan OpenSSH 8.2, isang bukas na pagpapatupad ng kliyente at server para sa pagtatrabaho sa pamamagitan ng mga protocol ng SSH 2.0 at SFTP.

Ang isang pangunahing pagpapabuti sa paglabas ng OpenSSH 8.2 ay ang kakayahang gumamit ng two-factor authentication gamit ang mga device na sumusuporta sa protocol. U2F, binuo ng alyansa FIDO. Binibigyang-daan ng U2F ang paglikha ng mga murang token ng hardware upang i-verify ang pisikal na presensya ng user, na nakikipag-ugnayan sa kanila sa pamamagitan ng USB, Bluetooth o NFC. Ang mga naturang device ay pino-promote bilang isang paraan ng two-factor authentication sa mga website, sinusuportahan na ng mga pangunahing browser at ginawa ng iba't ibang manufacturer, kabilang ang Yubico, Feitian, Thetis at Kensington.

Upang makipag-ugnayan sa mga device na nagkukumpirma sa presensya ng user, ang mga bagong uri ng key na "ecdsa-sk" at "ed25519-sk" ay idinagdag sa OpenSSH, na gumagamit ng ECDSA at Ed25519 digital signature algorithm, na sinamahan ng SHA-256 hash. Ang mga pamamaraan para sa pakikipag-ugnayan sa mga token ay inilalagay sa isang intermediate na library, na na-load sa katulad na paraan sa library para sa suporta ng PKCS#11 at isang wrapper sa itaas ng library libfido2, na nagbibigay ng mga tool para sa pakikipag-ugnayan sa mga token gamit ang USB (FIDO U2F/CTAP 1 at FIDO 2.0/CTAP 2 protocol ay sinusuportahan). Intermediate library libsk-libfido2 na inihanda ng mga developer ng OpenSSH kasama sa core libfido2, pati na rin HID driver para sa OpenBSD.

Upang mapatotohanan at makabuo ng isang key, dapat mong tukuyin ang parameter na "SecurityKeyProvider" sa mga setting o itakda ang variable ng kapaligiran ng SSH_SK_PROVIDER, na nagsasaad ng path patungo sa external na library na libsk-libfido2.so (i-export ang SSH_SK_PROVIDER=/path/to/libsk-libfido2. kaya). Posibleng bumuo ng openssh na may built-in na suporta para sa layer library (--with-security-key-builtin), sa kasong ito kailangan mong itakda ang parameter na "SecurityKeyProvider=internal".
Susunod na kailangan mong patakbuhin ang "ssh-keygen -t ecdsa-sk" o, kung ang mga susi ay nagawa at na-configure na, kumonekta sa server gamit ang "ssh". Kapag nagpatakbo ka ng ssh-keygen, ang nabuong pares ng key ay ise-save sa “~/.ssh/id_ecdsa_sk” at maaaring magamit nang katulad sa iba pang mga key.

Ang pampublikong key (id_ecdsa_sk.pub) ay dapat makopya sa server sa authorized_keys file. Sa panig ng server, ang digital signature lamang ang na-verify, at ang pakikipag-ugnayan sa mga token ay ginagawa sa panig ng kliyente (hindi mo kailangang mag-install ng libsk-libfido2 sa server, ngunit dapat suportahan ng server ang uri ng key na "ecdsa-sk") . Ang nabuong pribadong key (id_ecdsa_sk) ay mahalagang hawakan ng susi, na bumubuo ng isang tunay na susi lamang kasama ang lihim na pagkakasunud-sunod na nakaimbak sa U2F token side. Kung ang id_ecdsa_sk key ay nahulog sa mga kamay ng isang attacker, para maipasa ang authentication kakailanganin din niyang makakuha ng access sa hardware token, kung wala ang pribadong key na nakaimbak sa id_ecdsa_sk file ay walang silbi.

Bilang karagdagan, bilang default, kapag nagsasagawa ng anumang mga operasyon na may mga susi (kapwa sa panahon ng pagbuo at sa panahon ng pagpapatunay), kinakailangan ang lokal na kumpirmasyon ng pisikal na presensya ng user, halimbawa, iminumungkahi na hawakan ang sensor sa token, na nagpapahirap sa magsagawa ng malayuang pag-atake sa mga system na may konektadong token. Bilang isa pang linya ng depensa, maaari ding tukuyin ang isang password sa yugto ng pagsisimula ng ssh-keygen upang ma-access ang key file.

Inanunsyo din ng bagong bersyon ng OpenSSH ang paparating na paghinto ng paggamit ng mga algorithm gamit ang SHA-1 na mga hash dahil sa promosyon ang pagiging epektibo ng mga pag-atake ng banggaan na may isang naibigay na prefix (ang halaga ng pagpili ng isang banggaan ay tinatantya sa humigit-kumulang 45 libong dolyar). Sa isa sa mga paparating na release, plano nilang i-disable bilang default ang kakayahang gamitin ang public key digital signature algorithm na "ssh-rsa", na binanggit sa orihinal na RFC para sa SSH protocol at nananatiling laganap sa pagsasanay (upang subukan ang paggamit ng ssh-rsa sa iyong mga system, maaari mong subukang kumonekta sa pamamagitan ng ssh gamit ang opsyong “-oHostKeyAlgorithms=-ssh-rsa”).

Upang pabilisin ang paglipat sa mga bagong algorithm sa OpenSSH, sa susunod na release ang UpdateHostKeys setting ay paganahin bilang default, na awtomatikong maglilipat ng mga kliyente sa mas maaasahang mga algorithm. Kasama sa mga inirerekomendang algorithm para sa paglipat ang rsa-sha2-256/512 batay sa RFC8332 RSA SHA-2 (sinusuportahan mula noong OpenSSH 7.2 at ginamit bilang default), ssh-ed25519 (sinusuportahan mula noong OpenSSH 6.5) at ecdsa-sha2-nistp256/384/521 based sa RFC5656 ECDSA (sinusuportahan mula noong OpenSSH 5.7).

Sa OpenSSH 8.2, ang kakayahang kumonekta gamit ang "ssh-rsa" ay magagamit pa rin, ngunit ang algorithm na ito ay inalis mula sa listahan ng CASignatureAlgorithms, na tumutukoy sa mga algorithm na pinapayagan para sa digitally signing ng mga bagong certificate. Katulad nito, ang diffie-hellman-group14-sha1 algorithm ay inalis mula sa default na key exchange algorithm na sinusuportahan. Napansin na ang paggamit ng SHA-1 sa mga certificate ay nauugnay sa karagdagang panganib, dahil ang umaatake ay may walang limitasyong oras upang maghanap ng banggaan para sa isang umiiral nang certificate, habang ang oras ng pag-atake sa mga host key ay limitado ng timeout ng koneksyon (LoginGraceTime ).

Ang pagpapatakbo ng ssh-keygen ay nagde-default na ngayon sa rsa-sha2-512 algorithm, na sinusuportahan mula noong OpenSSH 7.2, na maaaring lumikha ng mga isyu sa compatibility kapag sinusubukang iproseso ang mga certificate na naka-sign sa OpenSSH 8.2 sa mga system na nagpapatakbo ng mas lumang OpenSSH release (upang ayusin ang isyu kapag Kailan pagbuo ng isang lagda, maaari mong tahasang tukuyin ang "ssh-keygen -t ssh-rsa" o gamitin ang ecdsa-sha2-nistp256/384/521 na mga algorithm, na suportado mula noong OpenSSH 5.7).

Iba pang mga pagbabago:

• May idinagdag na direktiba ng Include sa sshd_config, na nagpapahintulot sa iyo na isama ang mga nilalaman ng iba pang mga file sa kasalukuyang posisyon ng file ng pagsasaayos (maaaring gamitin ang mga glob mask kapag tinukoy ang pangalan ng file);
• Ang opsyon na "no-touch-required" ay idinagdag sa ssh-keygen, na hindi pinapagana ang pangangailangang pisikal na kumpirmahin ang access sa token kapag bumubuo ng key;
• Ang isang PubkeyAuthOptions na direktiba ay idinagdag sa sshd_config, na pinagsasama ang iba't ibang mga opsyon na nauugnay sa pampublikong key authentication. Sa kasalukuyan, tanging ang flag na "no-touch-required" lang ang sinusuportahan upang laktawan ang mga pisikal na pagsusuri sa presensya para sa pagpapatunay ng token. Sa pamamagitan ng pagkakatulad, ang opsyong "no-touch-required" ay naidagdag sa authorized_keys file;
• Idinagdag ang opsyong "-O write-attestation=/path" sa ssh-keygen upang payagan ang mga karagdagang FIDO attestation certificate na maisulat kapag bumubuo ng mga key. Hindi pa ginagamit ng OpenSSH ang mga certificate na ito, ngunit magagamit ang mga ito sa ibang pagkakataon upang i-verify na ang susi ay inilagay sa isang pinagkakatiwalaang tindahan ng hardware;
• Sa ssh at sshd na mga setting, posible na ngayong itakda ang traffic prioritization mode sa pamamagitan ng IPQoS directive LE DSCP (Lower-Effort Per-Hop Behavior);
• Sa ssh, kapag nagtatakda ng value na "AddKeysToAgent=yes", kung ang key ay hindi naglalaman ng field ng komento, idaragdag ito sa ssh-agent na nagpapahiwatig ng path sa key bilang isang komento. SA
  Gumagamit na rin ang ssh-keygen at ssh-agent ng mga label na PKCS#11 at ang X.509 na pangalan ng paksa sa halip na ang path ng library bilang mga komento sa key;

• Nagdagdag ng kakayahang mag-export ng PEM para sa mga DSA at ECDSA key sa ssh-keygen;
• Nagdagdag ng bagong executable, ssh-sk-helper, na ginamit para ihiwalay ang FIDO/U2F token access library;
• Idinagdag ang "--with-zlib" build option sa ssh at sshd para sa compilation na may suporta sa zlib library;
• Alinsunod sa kinakailangan ng RFC4253, isang babala tungkol sa pag-block sa pag-access dahil sa paglampas sa mga limitasyon ng MaxStartups ay ibinibigay sa banner na ipinapakita habang kumonekta. Upang pasimplehin ang mga diagnostic, ang sshd process header, na makikita kapag ginagamit ang ps utility, ay ipinapakita na ngayon ang bilang ng kasalukuyang napatotohanan na mga koneksyon at ang katayuan ng limitasyon ng MaxStartups;
• Sa ssh at ssh-agent, kapag tumatawag sa isang programa upang magpakita ng isang imbitasyon sa screen, na tinukoy sa pamamagitan ng $SSH_ASKPASS, ang isang bandila na may uri ng imbitasyon ay naipapadala na ngayon: "kumpirmahin" - dialog ng kumpirmasyon (oo/hindi), "wala ” - mensaheng pang-impormasyon, “blangko” — kahilingan sa password;
• Nagdagdag ng bagong digital signature na operasyon na "find-principals" sa ssh-keygen para hanapin ang file na pinapayagang pumirma para sa user na nauugnay sa isang tinukoy na digital signature;
• Pinahusay na suporta para sa sshd process isolation sa Linux gamit ang seccomp mechanism: hindi pagpapagana ng IPC system calls, na nagpapahintulot sa clock_gettime64(), clock_nanosleep_time64 at clock_nanosleep().

Pinagmulan: opennet.ru