Utgivelsen av OpenSSH 8.5

Etter fem måneder med utvikling presenteres OpenSSH 8.5, en åpen implementering av klient og server for bruk med SSH 2.0- og SFTP-protokoller.

Utviklerne av OpenSSH minner om den nært forestående overgangen av algoritmer som bruker SHA-1-hash til utdaterte, på grunn av økt effektivitet i kollisjonsangrep med forhåndsbestemt prefiks (kostnaden for å finne en kollisjon er estimert til omtrent 50 000 dollar). I en av de nærmeste utgivelsene planlegger de å deaktivere bruken av algoritmen for digitale signaturer med åpen nøkkel 'ssh-rsa' som nevnes i den originale RFC for SSH-protokollen og fremdeles er utbredt i praksis.

For å kontrollere bruken av ssh-rsa i systemene dine, kan du prøve å koble til via ssh med alternativet «-oHostKeyAlgorithms=-ssh-rsa». Deaktivering av digitale signaturer for «ssh-rsa» som standard betyr ikke fullstendig avvisning av RSA-nøkler, da SSH-protokollen tillater bruk av andre hash-algoritmer i tillegg til SHA-1. Spesielt vil det fortsatt være mulig å bruke bunter av «rsa-sha2-256» (RSA/SHA256) og «rsa-sha2-512» (RSA/SHA512).

For å lette overgangen til de nye algoritmene i OpenSSH 8.5 er innstillingen UpdateHostKeys som standard aktivert, som gjør det mulig å automatisk overføre klienter til mer pålitelige algoritmer. Denne innstillingen aktiverer en spesiell protokollutvidelse 'hostkeys@openssh.com', som tillater serveren å informere klienten om alle tilgjengelige vertsnøkler etter autentisering. Klienten kan reflektere disse nøklene i sin fil ~/ .ssh/known_hosts, noe som muliggjør oppdatering av vertsnøkler og forenkler nøkkelskiftet. serveren.

Bruken av UpdateHostKeys er begrenset av flere forbehold som kan bli opphevet i fremtiden: nøkkelen må nevnes i UserKnownHostsFile og ikke brukes i GlobalKnownHostsFile; nøkkelen må bare være til stede under ett navn; vertsnøkkelsertifikatet skal ikke brukes; det skal ikke brukes masker på vertsnavnet i known_hosts; innstillingen VerifyHostKeyDNS må være deaktivert; innstillingen UserKnownHostsFile må være aktivert.

Blant de anbefalte algoritmene for migrering er rsa-sha2-256/512 basert på RFC8332 RSA SHA-2 (støttet fra OpenSSH 7.2 og brukt som standard), ssh-ed25519 (støttet fra OpenSSH 6.5) og ecdsa-sha2-nistp256/384/521 basert på RFC5656 ECDSA (støttet fra OpenSSH 5.7).

Andre endringar:

• Sikkerhetsrelaterte endringer:
  • I ssh-agent er det rettet en sårbarhet som er forårsaket av dobbel frigjøring av allerede frigitt minne (double-free). Problemet viste seg med utgivelsen av OpenSSH 8.2 og kan potensielt utnyttes hvis en angriper har tilgang til ssh-agent-uttaksstedet på det lokale systemet. Utnyttelse kompliseres av at bare root og den originale brukeren har tilgang til sockets. Det mest sannsynlige angrepsszenariet er å omdirigere agenten til en konto som kontrolleres av angriperen, eller til en vert som angriperen har root-tilgang til.
  • I sshd er det lagt til beskyttelse mot overføring av svært store parametere med brukernavn til PAM-undermodulen, noe som gjør det mulig å blokkere sårbarheter i systemmoduler for PAM (Pluggable Authentication Module). For eksempel forhindrer endringen bruken av sshd som en vektor for utnyttelse av en nylig oppdaget root-sårbarhet i Solaris (CVE-2020-14871).
• Endringer som potensielt bryter kompatibiliteten:
  • I ssh og sshd er den eksperimentelle metoden for nøkkelutveksling, som er motstandsdyktig mot kvasarcomputere, omarbeidet. Kvasarcomputere løser problemet med å faktorere naturlige tall i primtall radikalt raskere, noe som ligger til grunn for moderne asymmetriske krypteringsalgoritmer og er effektivt uløselig på klassiske prosessorer. Den brukte metoden er basert på algoritmen NTRU Prime, utviklet for post-kvasarkryptosystemer, og nøkkelutvekslingsmetoden basert på elliptiske kurver X25519. I stedet for sntrup4591761x25519-sha512@tinyssh.org identifiseres metoden nå som sntrup761x25519-sha512@openssh.com (algoritmen sntrup4591761 er erstattet med sntrup761).
  • I ssh og sshd er rekkefølgen for annonsering av støttede digitale signaturalgoritmer endret. ED25519 tilbys nå først i stedet for ECDSA.
  • I ssh og sshd settes QoS TOS/DSCP-parametrene for interaktive økter nå før TCP-forbindelsen etableres.
  • I ssh og sshd er støtten for chiffret rijndael-cbc@lysator.liu.se, som er identisk med aes256-cbc og ble brukt før RFC-4253 ble godkjent, avviklet.
  • Parameteret CheckHostIP er som standard deaktivert, da fordelen av dette er ubetydelig, men bruken kompliserer betydelig rotasjonen av nøkler for verter bak lastbalansere.
• I sshd er innstillingene PerSourceMaxStartups og PerSourceNetBlockSize lagt til for å begrense intensiteten av oppstart av håndterere knyttet til klientens adresse. Disse parameterne gir mer presis kontroll over begrensningen av prosessoppstart sammenlignet med den generelle innstillingen MaxStartups.
• I ssh og sshd er en ny innstilling LogVerbose lagt til, som gjør det mulig å tvinge opp nivået av loggført feilmelding med mulighet for filtrering etter mønstre, funksjoner og filer.
• I ssh vises alle vertsnavn og IP-adresser, assosiert med nøkkelen, når et nytt verts nøkkel tas i bruk.
• I ssh er det tillatt å spesifisere alternativet UserKnownHostsFile=none for å deaktivere bruken av known_hosts-filen ved identifikasjon av verts nøkler.
• I ssh_config for ssh er innstillingen KnownHostsCommand lagt til, som lar deg få data fra known_hosts fra utdataene til den angitte kommandoen.
• I ssh_config for ssh er alternativet PermitRemoteOpen lagt til, som tillater å begrense destinasjonspunktet ved bruk av RemoteForward-alternativet med SOCKS.
• I ssh for FIDO keys, a request for the PIN is ensured in case of a failure in the digital signature operation due to an incorrect PIN and the absence of a PIN request from the user (for example, when it was not possible to obtain correct biometric data and the device reverted to manual PIN entry).
• In sshd, based on the seccomp-bpf process isolation mechanism on the Linux platform, support for additional system calls has been added.
• The contrib/ssh-copy-id utility has been updated.

Kilde: opennet.ru