Etter fem måneders utvikling presenteres utgivelsen av OpenSSH 8.5, en åpen implementering av en klient og server for arbeid over SSH 2.0- og SFTP-protokollene.
OpenSSH-utviklerne minnet oss om den kommende avviklingen av algoritmer som bruker SHA-1-hasher på grunn av den økte effektiviteten til kollisjonsangrep med et gitt prefiks (kostnaden for å velge en kollisjon er estimert til omtrent $50 tusen). I en av de kommende utgivelsene planlegger de som standard å deaktivere muligheten til å bruke "ssh-rsa" offentlig nøkkel digital signaturalgoritme, som er nevnt i den originale RFC for SSH-protokollen og fortsatt er utbredt i praksis.
For å teste bruken av ssh-rsa på systemene dine, kan du prøve å koble til via ssh med alternativet "-oHostKeyAlgorithms=-ssh-rsa". Samtidig betyr ikke deaktivering av "ssh-rsa" digitale signaturer som standard en fullstendig oppgivelse av bruken av RSA-nøkler, siden i tillegg til SHA-1, tillater SSH-protokollen bruk av andre hash-beregningsalgoritmer. Spesielt, i tillegg til "ssh-rsa", vil det fortsatt være mulig å bruke "rsa-sha2-256" (RSA/SHA256) og "rsa-sha2-512" (RSA/SHA512) bunter.
For å jevne overgangen til nye algoritmer har OpenSSH 8.5 UpdateHostKeys-innstillingen aktivert som standard, som lar klienter automatisk bytte til mer pålitelige algoritmer. Ved å bruke denne innstillingen blir en spesiell protokollutvidelse aktivert "[e-postbeskyttet]", slik at serveren, etter autentisering, kan informere klienten om alle tilgjengelige vertsnøkler. Klienten kan reflektere disse nøklene i filen ~/.ssh/known_hosts, som gjør at vertsnøklene kan oppdateres og gjør det enklere å endre nøkler på serveren.
Bruken av UpdateHostKeys er begrenset av flere forbehold som kan fjernes i fremtiden: nøkkelen må refereres til i UserKnownHostsFile og ikke brukes i GlobalKnownHostsFile; nøkkelen må være til stede under bare ett navn; et vertsnøkkelsertifikat skal ikke brukes; i kjente_verter skal masker etter vertsnavn ikke brukes; VerifyHostKeyDNS-innstillingen må være deaktivert; UserKnownHostsFile-parameteren må være aktiv.
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).
Andre endringer:
- Sikkerhetsendringer:
- En sårbarhet forårsaket av re-frigjøring av et allerede frigjort minneområde (dobbeltfritt) har blitt fikset i ssh-agent. Problemet har vært tilstede siden utgivelsen av OpenSSH 8.2 og kan potensielt utnyttes hvis en angriper har tilgang til ssh-agent-kontakten på det lokale systemet. Det som gjør utnyttelse vanskeligere er at bare root og den opprinnelige brukeren har tilgang til stikkontakten. Det mest sannsynlige angrepsscenarioet er at agenten blir omdirigert til en konto som kontrolleres av angriperen, eller til en vert der angriperen har root-tilgang.
- sshd har lagt til beskyttelse mot å sende veldig store parametere med brukernavnet til PAM-delsystemet, som lar deg blokkere sårbarheter i PAM-systemmodulene (Pluggable Authentication Module). For eksempel forhindrer endringen at sshd brukes som en vektor for å utnytte en nylig oppdaget rotsårbarhet i Solaris (CVE-2020-14871).
- Potensielt brytende kompatibilitetsendringer:
- В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [e-postbeskyttet] метод теперь идентифицируется как [e-postbeskyttet] (sntrup4591761-algoritmen er erstattet av sntrup761).
- I ssh og sshd er rekkefølgen som støttede digitale signaturalgoritmer annonseres i, endret. ED25519 tilbys nå først i stedet for ECDSA.
- I ssh og sshd er innstilling av TOS/DSCP-kvalitet på tjenesteparametere for interaktive økter nå gjort før en TCP-forbindelse etableres.
- В ssh и sshd прекращена поддержка шифра [e-postbeskyttet], som er identisk med aes256-cbc og ble brukt før RFC-4253 ble godkjent.
- Som standard er CheckHostIP-parameteren deaktivert, fordelen med dette er ubetydelig, men bruken kompliserer nøkkelrotasjon betydelig for verter bak lastbalansere.
- Innstillinger for PerSourceMaxStartups og PerSourceNetBlockSize er lagt til sshd for å begrense intensiteten til å starte behandlere basert på klientadressen. Disse parametrene lar deg kontrollere grensen for prosessstarter mer detaljert sammenlignet med den generelle MaxStartups-innstillingen.
- En ny LogVerbose-innstilling er lagt til ssh og sshd, som lar deg øke nivået av feilsøkingsinformasjon som dumpes inn i loggen, med muligheten til å filtrere etter maler, funksjoner og filer.
- I ssh, når du godtar en ny vertsnøkkel, vises alle vertsnavn og IP-adresser knyttet til nøkkelen.
- ssh lar alternativet UserKnownHostsFile=ingen deaktivere bruken av filen known_hosts når vertsnøkler identifiseres.
- En KnownHostsCommand-innstilling er lagt til ssh_config for ssh, slik at du kan hente known_hosts-data fra utdataene til den angitte kommandoen.
- La til et PermitRemoteOpen-alternativ til ssh_config for ssh for å tillate deg å begrense destinasjonen når du bruker alternativet RemoteForward med SOCKS.
- I ssh for FIDO-nøkler gis en gjentatt PIN-forespørsel i tilfelle en digital signatur-operasjonsfeil på grunn av feil PIN-kode og brukeren ikke blir bedt om en PIN-kode (for eksempel når de riktige biometriske dataene ikke kunne skaffes og enheten falt tilbake til manuell PIN-inntasting).
- sshd legger til støtte for ytterligere systemanrop til den seccomp-bpf-baserte prosessisolasjonsmekanismen på Linux.
- Contrib/ssh-copy-id-verktøyet har blitt oppdatert.
Kilde: opennet.ru