Neljän kuukauden kehitystyön jälkeen vapauta , avoin asiakas- ja palvelintoteutus SSH 2.0- ja SFTP-protokollien kautta työskentelemiseen.
Keskeinen parannus OpenSSH 8.2 -julkaisussa oli mahdollisuus käyttää kaksivaiheista todennusta protokollaa tukevien laitteiden kanssa. , jonka on kehittänyt allianssi U2F mahdollistaa edullisten laitteistotunnusten luomisen käyttäjän fyysisen läsnäolon varmentamiseksi ja vuorovaikutuksessa hänen kanssaan USB:n, Bluetoothin tai NFC:n kautta. Näitä laitteita mainostetaan kaksivaiheisen todennuksen keinona verkkosivustoilla, niitä tukevat jo suuret selaimet, ja niitä valmistavat useat valmistajat, kuten Yubico, Feitian, Thetis ja Kensington.
Jotta OpenSSH voisi olla vuorovaikutuksessa käyttäjän läsnäolon vahvistavien laitteiden kanssa, se on lisännyt uusia avaintyyppejä, "ecdsa-sk" ja "ed25519-sk", jotka käyttävät ECDSA- ja Ed25519-digitaalisia allekirjoitusalgoritmeja yhdessä SHA-256-hajautuksen kanssa. Tunnusten kanssa vuorovaikutukseen käytettävät proseduurit on siirretty välikirjastoon, joka ladataan samalla tavalla kuin PKCS#11-tukikirjasto ja toimii kirjaston ympärillä olevana kääreenä. , joka tarjoaa keinot tokeneiden kanssa kommunikointiin USB:n kautta (FIDO U2F/CTAP 1- ja FIDO 2.0/CTAP 2 -protokollia tuetaan). OpenSSH-kehittäjien valmistama libsk-libfido2-välikirjasto libfido2:n ydinkoostumukseen sekä OpenBSD:lle.
Avaimen todentamiseksi ja luomiseksi sinun on määritettävä asetuksissa "SecurityKeyProvider"-parametri tai asetettava SSH_SK_PROVIDER-ympäristömuuttuja, joka määrittää polun ulkoiseen kirjastoon libsk-libfido2.so (vienti SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). OpenSSH voidaan rakentaa sisäänrakennetulla tuella välikirjastolle (--with-security-key-builtin); tässä tapauksessa sinun on asetettava parametri "SecurityKeyProvider=internal".
Suorita seuraavaksi komento "ssh-keygen -t ecdsa-sk" tai, jos avaimet on jo luotu ja konfiguroitu, muodosta yhteys palvelimeen "ssh":n avulla. Kun suoritat komennon ssh-keygen, luotu avainpari tallennetaan kansioon "~/.ssh/id_ecdsa_sk" ja sitä voidaan käyttää kuten muitakin avaimia.
Julkinen avain (id_ecdsa_sk.pub) tulee kopioida palvelimen authorized_keys-tiedostoon. Palvelin tarkistaa vain digitaalisen allekirjoituksen, kun taas tunnuksen vuorovaikutus tapahtuu asiakasohjelmassa (libsk-libfido2:n ei tarvitse olla asennettuna palvelimelle, mutta palvelimen on tuettava "ecdsa-sk"-avaintyyppiä). Luotu yksityinen avain (id_ecdsa_sk) on pohjimmiltaan avainkuvaaja, joka muodostaa todellisen avaimen vain yhdistettynä U2F-tunnukseen tallennettuun salaiseen sekvenssiin. Jos hyökkääjä saa haltuunsa id_ecdsa_sk-avaimen, hän tarvitsee myös pääsyn laitteistotunnukseen todennusta varten, jota ilman id_ecdsa_sk-tiedostoon tallennettu yksityinen avain on hyödytön.
Lisäksi oletusarvoisesti kaikki avaintoiminnot (sekä luonti että todennus) vaativat paikallisen vahvistuksen käyttäjän fyysisestä läsnäolosta, kuten tokenin anturin koskettamisen, mikä vaikeuttaa etähyökkäysten suorittamista järjestelmiin, joihin on yhdistetty token. Lisäturvakerroksena ssh-keygenin käynnistyksen yhteydessä voidaan asettaa myös salasana avaintiedoston käyttämiseksi.
OpenSSH:n uusi versio ilmoitti myös SHA-1-tiivisteitä käyttävien algoritmien tulevasta vanhenemisesta johtuen törmäyshyökkäysten tehokkuus tietyllä etuliitteellä (törmäyksen valinnan hinta on arviolta noin 45 tuhatta dollaria). Yhdessä tulevassa julkaisussa he suunnittelevat poistavansa oletusarvoisesti käytöstä julkisen avaimen digitaalisen allekirjoitusalgoritmin ”ssh-rsa”, joka mainitaan alkuperäisessä RFC:ssä SSH-protokollalle ja on edelleen laajalle levinnyt käytännössä (käytön testaamiseksi). ssh-rsa:sta järjestelmissäsi, voit yrittää muodostaa yhteyden ssh:n kautta vaihtoehdolla "-oHostKeyAlgorithms=-ssh-rsa").
Uusiin OpenSSH-algoritmeihin siirtymisen helpottamiseksi tulevassa julkaisussa UpdateHostKeys-asetus otetaan oletusarvoisesti käyttöön, mikä siirtää asiakkaat automaattisesti luotettavampiin algoritmeihin. Suositeltuja siirtoalgoritmeja ovat rsa-sha2-256/512, joka perustuu RFC8332 RSA SHA-2:een (tuettu OpenSSH 7.2:sta lähtien ja käytössä oletuksena), ssh-ed25519 (tuettu OpenSSH 6.5:stä lähtien) ja ecdsa-sha2-nistp256/384-pohjainen521/5656/5.7. RFCXNUMX ECDSA:ssa (tuettu OpenSSH XNUMX:stä lähtien).
OpenSSH 8.2 tukee edelleen yhteyden muodostamista "ssh-rsa"-algoritmilla, mutta tämä algoritmi on poistettu CASignatureAlgorithms-luettelosta, joka määrittelee uusien varmenteiden digitaaliseen allekirjoittamiseen sallitut algoritmit. Vastaavasti diffie-hellman-group14-sha1-algoritmi on poistettu tuettujen oletusarvoisten avaintenvaihtoalgoritmien joukosta. On huomattava, että SHA-1:n käyttö varmenteissa tuo mukanaan lisäriskin, koska hyökkääjällä on rajattomasti aikaa löytää olemassa olevan varmenteen törmäys, kun taas isäntäavaimiin kohdistuvia hyökkäyksiä rajoittaa yhteyden aikakatkaisu (LoginGraceTime).
Kun ssh-keygen-komentoa käytetään, OpenSSH 7.2:sta lähtien tuettu rsa-sha2-512-algoritmi on nyt oletusarvoisesti käytössä. Tämä voi aiheuttaa yhteensopivuusongelmia yritettäessä käsitellä OpenSSH 8.2:lla allekirjoitettuja varmenteita järjestelmissä, joissa on vanhempia OpenSSH-versioita (voit kiertää tämän ongelman määrittämällä nimenomaisesti "ssh-keygen -t ssh-rsa" allekirjoitusta luotaessa tai käyttämällä OpenSSH 5.7:stä lähtien tuettuja ecdsa-sha2-nistp256/384/521-algoritmeja).
Muut muutokset:
- sshd_config-tiedostoon on lisätty Include-direktiivi, jonka avulla muiden tiedostojen sisältö voidaan sisällyttää asetustiedoston nykyiseen sijaintiin (tiedostonimeä määritettäessä voidaan käyttää glob-maskeja);
- ssh-keygeniin on lisätty "no-touch-required" -vaihtoehto, joka poistaa käytöstä tokenin käyttöoikeuden fyysisen vahvistuksen tarpeen avainta luotaessa;
- PubkeyAuthOptions-direktiivi on lisätty sshd_config-tiedostoon, mikä yhdistää useita julkisen avaimen todennukseen liittyviä asetuksia. Tällä hetkellä tuetaan vain "no-touch-required"-lippua, jonka avulla fyysisen läsnäolon tarkistus voidaan ohittaa token-todennuksen aikana. Vastaavasti "no-touch-required"-asetus on lisätty authorized_keys-tiedostoon.
- ssh-keygen-käskyyn on lisätty asetus "-O write-attestation=/path", jonka avulla avaimia luotaessa voidaan kirjoittaa lisää FIDO-todennusvarmenteita. OpenSSH ei tällä hetkellä käytä näitä varmenteita, mutta niitä voidaan käyttää tulevaisuudessa sen varmistamiseen, että avain on tallennettu luotettavaan laitteistotallennustilaan.
- SSH- ja sshd-asetuksissa liikenteen priorisointitila voidaan nyt asettaa IPQoS-direktiivin avulla. (Pienemmän vaivannäön hyppykohtainen käyttäytyminen);
- SSH:ssa, kun arvoksi asetetaan "AddKeysToAgent=yes" ja avaimessa ei ole kommenttikenttää, se lisätään ssh-agenttiin ja avaimen polku määritetään kommenttina.
ssh-keygen ja ssh-agent käyttävät nyt myös PKCS#11-tunnisteita ja X.509-aiheen nimeä kommentteina avaimessa kirjastopolun sijaan; - Lisätty mahdollisuus viedä DSA- ja ECDSA-avainten PEM-tiedostot ssh-keygeniin;
- Lisätty uusi suoritettava tiedosto ssh-sk-helper, jota käytetään eristämään kirjaston käyttöoikeus FIDO/U2F-tokeniin;
- Lisätty ssh:lle ja sshd:lle käännösoptio "--with-zlib" zlib-kirjastotuen käyttöä varten;
- RFC 4253:n mukaisesti yhteysbannerissa näkyy nyt varoitus käytön estämisestä MaxStartups-rajan ylittymisen vuoksi. Diagnostiikan yksinkertaistamiseksi sshd-prosessin otsikko, joka näkyy ps-apuohjelmalla, näyttää nyt tällä hetkellä todennettujen yhteyksien määrän ja MaxStartups-rajan tilan.
- SSH:ssa ja SSH-agentissa, kun ohjelmaa kutsutaan näyttämään kutsu näytöllä $SSH_ASKPASS-parametrilla määritetyn kutsun kautta, lähetetään nyt lisäksi kutsutyypin sisältävä lippu: ”vahvista” — vahvistusikkuna (kyllä/ei), ”ei mitään” — tiedottava viesti, ”tyhjä” — salasanan pyyntö;
- ssh-keygen-funktioon on lisätty uusi digitaalisen allekirjoituksen toiminto "find-principals", jolla voidaan etsiä allowed-signers-tiedostosta määritettyyn digitaaliseen allekirjoitukseen liittyvää käyttäjää.
- Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Lähde: opennet.ru
