Na vijf maanden ontwikkeling wordt de release van OpenSSH 8.5 gepresenteerd, een open implementatie van een client en server voor het werken via de SSH 2.0- en SFTP-protocollen.
De OpenSSH-ontwikkelaars herinnerden ons aan de aanstaande buitengebruikstelling van algoritmen die SHA-1-hashes gebruiken vanwege de toegenomen efficiëntie van botsingsaanvallen met een bepaald voorvoegsel (de kosten voor het selecteren van een botsing worden geschat op ongeveer $ 50). In een van de komende releases zijn ze van plan om standaard de mogelijkheid uit te schakelen om het “ssh-rsa” algoritme voor digitale handtekeningen met openbare sleutel te gebruiken, dat wordt genoemd in de oorspronkelijke RFC voor het SSH-protocol en in de praktijk wijdverbreid blijft.
Om het gebruik van ssh-rsa op uw systemen te testen, kunt u proberen verbinding te maken via ssh met de optie “-oHostKeyAlgorithms=-ssh-rsa”. Tegelijkertijd betekent het standaard uitschakelen van de “ssh-rsa” digitale handtekeningen niet dat het gebruik van RSA-sleutels volledig wordt stopgezet, aangezien het SSH-protocol naast SHA-1 het gebruik van andere hash-berekeningsalgoritmen toestaat. Met name naast “ssh-rsa” blijft het mogelijk om de bundels “rsa-sha2-256” (RSA/SHA256) en “rsa-sha2-512” (RSA/SHA512) te gebruiken.
Om de overgang naar nieuwe algoritmen te vergemakkelijken, heeft OpenSSH 8.5 de UpdateHostKeys-instelling standaard ingeschakeld, waardoor clients automatisch kunnen overschakelen naar betrouwbaardere algoritmen. Met deze instelling wordt een speciale protocolextensie ingeschakeld “[e-mail beveiligd]", waardoor de server, na authenticatie, de client kan informeren over alle beschikbare hostsleutels. De client kan deze sleutels weergeven in het bestand ~/.ssh/known_hosts, waardoor de hostsleutels kunnen worden bijgewerkt en het gemakkelijker wordt om sleutels op de server te wijzigen.
Het gebruik van UpdateHostKeys wordt beperkt door verschillende voorbehouden die in de toekomst mogelijk worden verwijderd: er moet naar de sleutel worden verwezen in de UserKnownHostsFile en mag niet worden gebruikt in de GlobalKnownHostsFile; de sleutel mag onder slechts één naam aanwezig zijn; er mag geen hostsleutelcertificaat worden gebruikt; in bekende_hosts mogen maskers op hostnaam niet worden gebruikt; de VerifyHostKeyDNS-instelling moet zijn uitgeschakeld; De parameter UserKnownHostsFile moet actief zijn.
Aanbevolen algoritmen voor migratie zijn onder meer rsa-sha2-256/512 gebaseerd op RFC8332 RSA SHA-2 (ondersteund sinds OpenSSH 7.2 en standaard gebruikt), ssh-ed25519 (ondersteund sinds OpenSSH 6.5) en ecdsa-sha2-nistp256/384/521 gebaseerd op RFC5656 ECDSA (ondersteund sinds OpenSSH 5.7).
Andere wijzigingen:
- Beveiligingswijzigingen:
- Een kwetsbaarheid veroorzaakt door het opnieuw vrijmaken van een reeds vrijgemaakt geheugengebied (dubbel vrij) is opgelost in ssh-agent. Het probleem is aanwezig sinds de release van OpenSSH 8.2 en kan mogelijk worden misbruikt als een aanvaller toegang heeft tot de ssh-agent socket op het lokale systeem. Wat de exploitatie moeilijker maakt, is dat alleen root en de oorspronkelijke gebruiker toegang hebben tot de socket. Het meest waarschijnlijke aanvalsscenario is dat de agent wordt omgeleid naar een account dat wordt beheerd door de aanvaller, of naar een host waar de aanvaller root-toegang heeft.
- sshd heeft bescherming toegevoegd tegen het doorgeven van zeer grote parameters met de gebruikersnaam aan het PAM-subsysteem, waardoor u kwetsbaarheden in de PAM-systeemmodules (Pluggable Authentication Module) kunt blokkeren. De wijziging voorkomt bijvoorbeeld dat sshd wordt gebruikt als een vector om misbruik te maken van een recent ontdekte root-kwetsbaarheid in Solaris (CVE-2020-14871).
- Mogelijk verbrekende compatibiliteitswijzigingen:
- In ssh en sshd is een experimentele sleuteluitwisselingsmethode opnieuw ontworpen die bestand is tegen gissen op een kwantumcomputer. Kwantumcomputers zijn radicaal sneller in het oplossen van het probleem van het ontbinden van een natuurlijk getal in priemfactoren, dat ten grondslag ligt aan moderne asymmetrische encryptie-algoritmen en niet effectief kan worden opgelost op klassieke processors. De gebruikte methode is gebaseerd op het NTRU Prime-algoritme, ontwikkeld voor post-kwantumcryptosystemen, en de X25519 elliptische curve-sleuteluitwisselingsmethode. In plaats van [e-mail beveiligd] de methode wordt nu geïdentificeerd als [e-mail beveiligd] (het sntrup4591761-algoritme is vervangen door sntrup761).
- In ssh en sshd is de volgorde waarin ondersteunde algoritmen voor digitale handtekeningen worden aangekondigd gewijzigd. ED25519 wordt nu als eerste aangeboden in plaats van ECDSA.
- In ssh en sshd wordt het instellen van TOS/DSCP quality of service-parameters voor interactieve sessies nu gedaan voordat een TCP-verbinding tot stand wordt gebracht.
- Cipher-ondersteuning is stopgezet in ssh en sshd [e-mail beveiligd], dat identiek is aan aes256-cbc en werd gebruikt voordat RFC-4253 werd goedgekeurd.
- Standaard is de parameter CheckHostIP uitgeschakeld, waarvan het voordeel verwaarloosbaar is, maar het gebruik ervan bemoeilijkt de sleutelrotatie aanzienlijk voor hosts achter load balancers.
- PerSourceMaxStartups- en PerSourceNetBlockSize-instellingen zijn toegevoegd aan sshd om de intensiteit van het starten van handlers te beperken op basis van het clientadres. Met deze parameters kunt u de limiet voor het starten van processen nauwkeuriger beheren, vergeleken met de algemene MaxStartups-instelling.
- Er is een nieuwe LogVerbose-instelling toegevoegd aan ssh en sshd, waarmee u het niveau van de foutopsporingsinformatie die in het logboek wordt gedumpt krachtig kunt verhogen, met de mogelijkheid om te filteren op sjablonen, functies en bestanden.
- In ssh worden bij het accepteren van een nieuwe hostsleutel alle hostnamen en IP-adressen weergegeven die aan de sleutel zijn gekoppeld.
- ssh staat de optie UserKnownHostsFile=none toe om het gebruik van het bestandknown_hosts uit te schakelen bij het identificeren van hostsleutels.
- Er is een KnownHostsCommand-instelling toegevoegd aan ssh_config voor ssh, waardoor u bekende_hosts-gegevens kunt ophalen uit de uitvoer van de opgegeven opdracht.
- Er is een PermitRemoteOpen-optie toegevoegd aan ssh_config voor ssh, zodat u de bestemming kunt beperken wanneer u de RemoteForward-optie met SOCKS gebruikt.
- In ssh voor FIDO-sleutels wordt een herhaald verzoek om een pincode verstrekt in het geval dat een digitale handtekening mislukt als gevolg van een onjuiste pincode en de gebruiker niet om een pincode wordt gevraagd (bijvoorbeeld wanneer de juiste biometrische gegevens niet konden worden verkregen en de gebruiker niet om een pincode werd gevraagd). apparaat viel terug op handmatige pincode-invoer).
- sshd voegt ondersteuning toe voor extra systeemaanroepen aan het op seccomp-bpf gebaseerde procesisolatiemechanisme op Linux.
- Het hulpprogramma contrib/ssh-copy-id is bijgewerkt.
Bron: opennet.ru