Na vijf maanden ontwikkeling is de release van OpenSSH 8.5 gepresenteerd, een open implementatie van de client en server voor werken met de SSH 2.0 en SFTP-protocollen.
De ontwikkelaars van OpenSSH herinnerden eraan dat de algoritmes die gebruikmaken van SHA-1 hashes binnenkort tot de verouderde algoritmes zullen behoren, vanwege de verhoogde effectiviteit van collision attacks met een gegeven prefix (de kosten van het vinden van een collision worden geschat op ongeveer 50 duizend dollar). In een van de komende versies is het plan om standaard de mogelijkheid om het retrieval algoritme voor digitale handtekeningen met de publieke sleutel 'ssh-rsa' te gebruiken, uit te schakelen; dit algoritme werd genoemd in de originele RFC voor het SSH-protocol en is nog steeds wijdverspreid in de praktijk.
Om te controleren of ssh-rsa in uw systemen wordt toegepast, kunt u proberen verbinding te maken via ssh met de optie "-oHostKeyAlgorithms=-ssh-rsa". Het standaard uitschakelen van digitale handtekeningen "ssh-rsa" betekent echter niet dat RSA-sleutels volledig worden afgewezen, aangezien het SSH-protocol naast SHA-1 ook andere hash-algoritmen toestaat. In het bijzonder blijft naast "ssh-rsa" de mogelijkheid om de koppelingen "rsa-sha2-256" (RSA/SHA256) en "rsa-sha2-512" (RSA/SHA512) te gebruiken.
Om de overgang naar nieuwe algoritmes te versoepelen, is in OpenSSH 8.5 standaard de instelling UpdateHostKeys ingeschakeld, waarmee clients automatisch kunnen overstappen op veiligere algoritmes. Met deze instelling wordt een speciale protocoluitbreiding 'hostkeys@openssh.com' ingeschakeld, waardoor de server de client na de authenticatie kan informeren over alle beschikbare hostsleutels. De client kan deze sleutels opnemen in zijn bestand ~/ .ssh /known_hosts, wat helpt bij het organiseren van de update van de hostsleutels en het vereenvoudigen van sleutelswisseling. de server.
Het gebruik van UpdateHostKeys is beperkt tot enkele voorwaarden, die in de toekomst kunnen worden opgeheven: de sleutel moet worden vermeld in UserKnownHostsFile en mag niet worden gebruikt in GlobalKnownHostsFile; de sleutel moet slechts onder één naam aanwezig zijn; er mag geen hostkey-certificaat worden toegepast; er mogen geen hostnaammaskers in known_hosts worden gebruikt; de instelling VerifyHostKeyDNS moet uitgeschakeld zijn; de parameter UserKnownHostsFile moet actief zijn.
Onder de aanbevolen algoritmen voor migratie worden rsa-sha2-256/512 genoemd, 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 op basis van RFC5656 ECDSA (ondersteund sinds OpenSSH 5.7).
Andere wijzigingen:
- Veranderingen met betrekking tot beveiliging:
- In ssh-agent is een kwetsbaarheid opgelost die is veroorzaakt door het dubbel vrijgeven van al vrijgegeven geheugen (double-free). Dit probleem is waargenomen sinds de release van OpenSSH 8.2 en kan potentieel worden uitgebuit wanneer de aanvaller toegang heeft tot de ssh-agent socket op het lokale systeem. De exploitatie wordt bemoeilijkt omdat alleen root en de oorspronkelijke gebruiker toegang hebben tot de socket. Het meest waarschijnlijke aanvalsscenario is dat de agent wordt omgeleid naar een account die onder controle staat van de aanvaller, of naar een host waarop de aanvaller root-toegang heeft.
- In sshd is bescherming toegevoegd tegen het doorgeven van zeer grote parameters met de gebruikersnaam naar de PAM-subsystemen, wat kwetsbaarheden in de PAM (Pluggable Authentication Module) systeemmodules kan blokkeren. Deze wijziging helpt bijvoorbeeld te voorkomen dat sshd wordt gebruikt als een vector voor het exploiteren van een recent ontdekte root-kwetsbaarheid in Solaris (CVE-2020-14871).
- Wijzigingen die mogelijk de compatibiliteit verstoren:
- In ssh and sshd, an experimental key exchange method resilient to quantum computing attacks has been revamped. Quantum computers solve the problem of factoring natural numbers into prime factors much faster, which underpins modern asymmetric encryption algorithms and is effectively unsolvable on classical processors. The method used is based on the NTRU Prime algorithm, developed for post-quantum cryptosystems, and the key exchange method based on elliptic curves X25519. The method is now identified as sntrup761x25519-sha512@openssh.com instead of sntrup4591761x25519-sha512@tinyssh.org (the sntrup4591761 algorithm has been replaced with sntrup761).
- In ssh and sshd, the order of announcing supported digital signature algorithms has changed. ED25519 is now proposed first instead of ECDSA.
- In ssh and sshd, setting the TOS/DSCP quality of service parameters for interactive sessions is now done before establishing a TCP connection.
- Support for the rijndael-cbc@lysator.liu.se cipher in ssh and sshd has been discontinued, as it is identical to aes256-cbc and was used until the approval of RFC-4253.
- By default, the CheckHostIP parameter is disabled, as its benefits are minimal, but its use complicates key rotation for hosts behind load balancers.
- In sshd, PerSourceMaxStartups and PerSourceNetBlockSize settings have been added to limit the intensity of handler startups tied to the client’s address. These parameters allow for finer control of process launch limits compared to the global MaxStartups setting.
- In ssh and sshd, a new LogVerbose setting has been added, which allows for forcibly increasing the level of debug information logged, with filtering options by patterns, functions, and files.
- In ssh, when accepting a new host key, all host names associated with the key are displayed. IP-adressen, associated with the key.
- In ssh, the UserKnownHostsFile=none option is allowed to disable the use of the known_hosts file when identifying host keys.
- In ssh_config for ssh, the KnownHostsCommand setting has been added, allowing known_hosts data to be retrieved from the output of a specified command.
- In ssh_config for ssh, the PermitRemoteOpen option has been added, allowing the destination to be restricted when using the RemoteForward option with SOCKS.
- In SSH is voor FIDO-sleutels een herhaalde PIN-aanroep voorzien in geval van een fout bij de digitale handtekening door een onjuiste PIN en gebrek aan PIN-aanroep van de gebruiker (bijvoorbeeld wanneer het niet is gelukt om juiste biometrische gegevens te verkrijgen en het apparaat teruggevallen is op handmatige invoer van de PIN).
- In SSHD is ondersteuning voor extra systeemoproepen toegevoegd aan het seccomp-bpf-gebaseerde procesisolatiemechanisme op het Linux-platform.
- Het hulpprogramma contrib/ssh-copy-id is bijgewerkt.
Bron: opennet.ru
