Etter fire måneder med utvikling utgivelse , en åpen klient- og serverimplementering for arbeid via SSH 2.0- og SFTP-protokollene.
En viktig forbedring i utgivelsen av OpenSSH 8.2 var muligheten til å bruke tofaktorautentisering ved å bruke enheter som støtter protokollen , utviklet av alliansen . U2F gjør det mulig å lage billige maskinvaretokens for å verifisere brukerens fysiske tilstedeværelse, og samhandle med dem via USB, Bluetooth eller NFC. Slike enheter markedsføres som et middel for tofaktorautentisering på nettsteder, støttes allerede av store nettlesere og produseres av forskjellige produsenter, inkludert Yubico, Feitian, Thetis og Kensington.
For å samhandle med enheter som bekrefter brukerens tilstedeværelse, er nye nøkkeltyper «ecdsa-sk» og «ed25519-sk» lagt til OpenSSH, som bruker ECDSA og Ed25519 digitale signaturalgoritmer, kombinert med SHA-256 hash. Prosedyrer for samhandling med tokens plasseres i et mellombibliotek, som lastes på lignende måte som biblioteket for PKCS#11-støtte og er en innpakning på toppen av biblioteket , som gir verktøy for å kommunisere med tokens over USB (protokollene FIDO U2F/CTAP 1 og FIDO 2.0/CTAP 2 støttes). Mellombibliotek libsk-libfido2 utarbeidet av OpenSSH-utviklere inn i kjernen libfido2, så vel som for OpenBSD.
For å autentisere og generere en nøkkel, må du spesifisere "SecurityKeyProvider"-parameteren i innstillingene eller angi miljøvariabelen SSH_SK_PROVIDER, som indikerer banen til det eksterne biblioteket libsk-libfido2.so (eksporter SSH_SK_PROVIDER=/path/to/libsk-libfido2. så). Det er mulig å bygge openssh med innebygd støtte for lagbiblioteket (--with-security-key-builtin), i dette tilfellet må du sette parameteren "SecurityKeyProvider=intern".
Deretter må du kjøre "ssh-keygen -t ecdsa-sk" eller, hvis nøklene allerede er opprettet og konfigurert, koble til serveren med "ssh". Når du kjører ssh-keygen, vil det genererte nøkkelparet bli lagret i "~/.ssh/id_ecdsa_sk" og kan brukes på samme måte som andre nøkler.
Den offentlige nøkkelen (id_ecdsa_sk.pub) skal kopieres til serveren i filen authorized_keys. På serversiden er kun den digitale signaturen verifisert, og interaksjon med tokens utføres på klientsiden (du trenger ikke installere libsk-libfido2 på serveren, men serveren må støtte nøkkeltypen "ecdsa-sk") . Den genererte private nøkkelen (id_ecdsa_sk) er i hovedsak et nøkkelhåndtak, og danner en ekte nøkkel bare i kombinasjon med den hemmelige sekvensen som er lagret på U2F-tokensiden. Hvis id_ecdsa_sk-nøkkelen faller i hendene på en angriper, vil han for å bestå autentisering også måtte få tilgang til maskinvaretokenet, uten hvilket den private nøkkelen som er lagret i id_ecdsa_sk-filen er ubrukelig.
I tillegg, som standard, når du utfører operasjoner med nøkler (både under generering og under autentisering), kreves lokal bekreftelse av brukerens fysiske tilstedeværelse, for eksempel foreslås det å berøre sensoren på tokenet, noe som gjør det vanskelig å utføre eksterne angrep på systemer med tilkoblet token. Som en annen forsvarslinje kan et passord også spesifiseres under oppstartsfasen av ssh-keygen for å få tilgang til nøkkelfilen.
Den nye versjonen av OpenSSH annonserte også den kommende avskrivningen av algoritmer som bruker SHA-1-hasher pga. effektiviteten av kollisjonsangrep med et gitt prefiks (kostnaden for å velge en kollisjon er estimert til omtrent 45 tusen dollar). I en av de kommende utgivelsene planlegger de som standard å deaktivere muligheten til å bruke offentlig nøkkel digital signaturalgoritme "ssh-rsa", som er nevnt i den originale RFC for SSH-protokollen og fortsatt er utbredt i praksis (for å teste bruken av ssh-rsa i systemene dine, kan du prøve å koble til via ssh med alternativet "-oHostKeyAlgorithms=-ssh-rsa").
For å jevne overgangen til nye algoritmer i OpenSSH, i en fremtidig utgivelse vil UpdateHostKeys-innstillingen være aktivert som standard, som automatisk vil migrere klienter til mer pålitelige algoritmer. Anbefalte algoritmer for migrering inkluderer rsa-sha2-256/512 basert på RFC8332 RSA SHA-2 (støttet siden OpenSSH 7.2 og brukt som standard), ssh-ed25519 (støttet siden OpenSSH 6.5) og ecdsa-sha2-nistp256/384 basert på RFC521 ECDSA (støttet siden OpenSSH 5656).
I OpenSSH 8.2 er muligheten til å koble til ved hjelp av "ssh-rsa" fortsatt tilgjengelig, men denne algoritmen er fjernet fra CASignatureAlgorithms-listen, som definerer algoritmene som er tillatt for digital signering av nye sertifikater. På samme måte har diffie-hellman-group14-sha1-algoritmen blitt fjernet fra standard nøkkelutvekslingsalgoritmer som støttes. Det bemerkes at bruk av SHA-1 i sertifikater er forbundet med ytterligere risiko, siden angriperen har ubegrenset tid til å søke etter en kollisjon for et eksisterende sertifikat, mens tidspunktet for angrep på vertsnøkler er begrenset av tilkoblingstidsavbruddet (LoginGraceTime ).
Å kjøre ssh-keygen er nå standard til rsa-sha2-512-algoritmen, som støttes siden OpenSSH 7.2, som kan skape kompatibilitetsproblemer når man forsøker å behandle sertifikater signert i OpenSSH 8.2 på systemer som kjører eldre OpenSSH-utgivelser (for å omgå problemet når når når Når du genererer en signatur, kan du spesifisere "ssh-keygen -t ssh-rsa" eller bruke ecdsa-sha2-nistp256/384/521-algoritmene, støttet siden OpenSSH 5.7).
Andre endringer:
- Et Inkluder-direktiv er lagt til sshd_config, som lar deg inkludere innholdet i andre filer på gjeldende posisjon til konfigurasjonsfilen (globmasker kan brukes når du spesifiserer filnavnet);
- Alternativet "no-touch-required" er lagt til ssh-keygen, som deaktiverer behovet for fysisk å bekrefte tilgang til tokenet når nøkkelen genereres;
- Et PubkeyAuthOptions-direktiv er lagt til sshd_config, som kombinerer ulike alternativer relatert til offentlig nøkkelautentisering. Foreløpig er det bare "no-touch-required"-flagget som støttes for å hoppe over fysiske tilstedeværelseskontroller for token-autentisering. I analogi er alternativet "no-touch-required" lagt til filen authorized_keys;
- Lagt til "-O write-attestation=/path"-alternativet til ssh-keygen for å tillate at ytterligere FIDO-attestasjonssertifikater skrives når nøkler genereres. OpenSSH bruker ennå ikke disse sertifikatene, men de kan senere brukes til å verifisere at nøkkelen er plassert i en klarert maskinvarebutikk;
- I ssh- og sshd-innstillingene er det nå mulig å stille inn trafikkprioriteringsmodus via IPQoS-direktivet (Lavere innsats per hop-atferd);
- I ssh, når du angir verdien "AddKeysToAgent=yes", hvis nøkkelen ikke inneholder et kommentarfelt, vil den bli lagt til ssh-agent som indikerer banen til nøkkelen som en kommentar. I
ssh-keygen og ssh-agent bruker nå også PKCS#11-etiketter og X.509-emnenavnet i stedet for bibliotekbanen som kommentarer i nøkkelen; - Lagt til muligheten til å eksportere PEM for DSA- og ECDSA-nøkler til ssh-keygen;
- Lagt til en ny kjørbar, ssh-sk-helper, brukt til å isolere FIDO/U2F-tokentilgangsbiblioteket;
- Lagt til "--with-zlib" byggealternativ til ssh og sshd for kompilering med zlib-bibliotekstøtte;
- I samsvar med kravet til RFC4253 er det gitt en advarsel om blokkering av tilgang på grunn av overskridelse av MaxStartups-grensene i banneret som vises under tilkobling. For å forenkle diagnostikken viser sshd-prosesshodet, som er synlig når du bruker ps-verktøyet, nå antallet autentiserte tilkoblinger og statusen til MaxStartups-grensen;
- I ssh og ssh-agent, når du ringer et program for å vise en invitasjon på skjermen, spesifisert via $SSH_ASKPASS, sendes det nå i tillegg et flagg med typen invitasjon: "bekreft" - bekreftelsesdialog (ja/nei), "ingen " - informasjonsmelding, "tom" - passordforespørsel;
- Lagt til en ny digital signatur-operasjon "find-principals" til ssh-keygen for å søke i filen for tillatte signaturer for brukeren knyttet til en spesifisert digital signatur;
- Forbedret støtte for sshd-prosessisolering på Linux ved å bruke seccomp-mekanismen: deaktivering av IPC-systemanrop, tillater clock_gettime64(), clock_nanosleep_time64 og clock_nanosleep().
Kilde: opennet.ru