Na vier maande se ontwikkeling is die vrystelling van OpenSSH 8.7, 'n oop implementering van 'n kliënt en bediener om oor die SSH 2.0- en SFTP-protokolle te werk, aangebied.
Belangrikste veranderinge:
- 'n Eksperimentele data-oordragmodus is by scp gevoeg deur die SFTP-protokol in plaas van die tradisionele SCP/RCP-protokol te gebruik. SFTP gebruik meer voorspelbare naamhanteringsmetodes en gebruik nie dopverwerking van globpatrone aan die ander gasheer se kant nie, wat sekuriteitsprobleme skep. Om SFTP in scp te aktiveer, is die "-s" vlag voorgestel, maar in die toekoms word beplan om by verstek na hierdie protokol oor te skakel.
- sftp-bediener implementeer uitbreidings aan die SFTP-protokol om die ~/ en ~user/ paaie uit te brei, wat nodig is vir scp.
- Die scp-nutsding het die gedrag verander wanneer lêers tussen twee afgeleë gashere gekopieer word (byvoorbeeld, "scp host-a:/path host-b:"), wat nou by verstek deur 'n intermediêre plaaslike gasheer gedoen word, soos wanneer die " -3" vlag. Hierdie benadering laat jou toe om te verhoed dat onnodige geloofsbriewe na die eerste gasheer en driedubbele interpretasie van lêername in die dop (aan die bron-, bestemmings- en plaaslike stelselkant) deurgee, en wanneer jy SFTP gebruik, laat dit jou toe om alle verifikasiemetodes te gebruik wanneer jy toegang tot afstand verkry. gashere, en nie net nie-interaktiewe metodes nie. Die "-R" opsie is bygevoeg om die ou gedrag te herstel.
- ForkAfterAuthentication-instelling bygevoeg na ssh wat ooreenstem met die "-f" vlag.
- Bygevoeg StdinNull instelling by ssh, wat ooreenstem met die "-n" vlag.
- 'n SessionType-instelling is by ssh gevoeg, waardeur jy modusse kan stel wat ooreenstem met die "-N" (geen sessie) en "-s" (substelsel) vlae.
- ssh-keygen laat jou toe om 'n sleutelgeldigheidsinterval in sleutellêers te spesifiseer.
- Bygevoeg "-Oprint-pubkey" vlag by ssh-keygen om die volle publieke sleutel te druk as deel van die sshsig handtekening.
- In ssh en sshd is beide kliënt en bediener geskuif om 'n meer beperkende konfigurasielêer-ontleder te gebruik wat dop-agtige reëls gebruik vir die hantering van aanhalings, spasies en ontsnap-karakters. Die nuwe ontleder ignoreer ook nie voorheen gemaak aannames nie, soos die weglating van argumente in opsies (byvoorbeeld, die DenyUsers-aanwysing kan nie meer leeg gelaat word nie), ongeslote aanhalingstekens en die spesifiseer van veelvuldige = karakters.
- Wanneer SSHFP DNS-rekords gebruik word wanneer sleutels geverifieer word, gaan ssh nou alle ooreenstemmende rekords na, nie net dié wat 'n spesifieke tipe digitale handtekening bevat nie.
- In ssh-keygen, wanneer 'n FIDO-sleutel met die -Ochallenge-opsie gegenereer word, word die ingeboude laag nou vir hashing gebruik, eerder as libfido2, wat die gebruik van uitdagingsreekse groter of kleiner as 32 grepe toelaat.
- In sshd, wanneer omgewing="..."-instruksies in authorized_keys-lêers verwerk word, word die eerste passing nou aanvaar en daar is 'n beperking van 1024 omgewingsveranderlikename.
Die OpenSSH-ontwikkelaars het ook gewaarsku oor die ontbinding van algoritmes wat SHA-1-hashes gebruik as gevolg van die verhoogde doeltreffendheid van botsingsaanvalle met 'n gegewe voorvoegsel (die koste om 'n botsing te kies word op ongeveer 50 duisend dollar geskat). In die volgende weergawe beplan ons om by verstek die vermoë om die publieke sleutel digitale handtekeningalgoritme "ssh-rsa" te gebruik, wat in die oorspronklike RFC vir die SSH-protokol genoem is, te gebruik en wyd gebruik word in die praktyk.
Om die gebruik van ssh-rsa op u stelsels te toets, kan u probeer om via ssh te koppel met die “-oHostKeyAlgorithms=-ssh-rsa” opsie. Terselfdertyd beteken die deaktivering van "ssh-rsa" digitale handtekeninge by verstek nie 'n volledige ophou van die gebruik van RSA-sleutels nie, aangesien die SSH-protokol benewens SHA-1 die gebruik van ander hash-berekeningsalgoritmes toelaat. In die besonder, bykomend tot "ssh-rsa", sal dit moontlik bly om die "rsa-sha2-256" (RSA/SHA256) en "rsa-sha2-512" (RSA/SHA512) bundels te gebruik.
Om die oorgang na nuwe algoritmes glad te maak, het OpenSSH voorheen die UpdateHostKeys-instelling by verstek geaktiveer, wat kliënte in staat stel om outomaties na meer betroubare algoritmes oor te skakel. Deur hierdie instelling te gebruik, word 'n spesiale protokoluitbreiding geaktiveer "[e-pos beskerm]", wat die bediener toelaat om, na verifikasie, die kliënt in te lig oor alle beskikbare gasheersleutels. Die kliënt kan hierdie sleutels in sy ~/.ssh/known_hosts-lêer weerspieël, wat toelaat dat die gasheersleutels opgedateer word en dit makliker maak om sleutels op die bediener te verander.
Die gebruik van UpdateHostKeys word beperk deur verskeie waarskuwings wat in die toekoms verwyder kan word: die sleutel moet in die UserKnownHostsFile verwys word en nie in die GlobalKnownHostsFile gebruik word nie; die sleutel moet slegs onder een naam teenwoordig wees; 'n gasheersleutelsertifikaat moet nie gebruik word nie; in bekende_gashere moet maskers volgens gasheernaam nie gebruik word nie; die VerifyHostKeyDNS-instelling moet gedeaktiveer word; Die UserKnownHostsFile-parameter moet aktief wees.
Aanbevole algoritmes vir migrasie sluit in rsa-sha2-256/512 gebaseer op RFC8332 RSA SHA-2 (ondersteun sedert OpenSSH 7.2 en word by verstek gebruik), ssh-ed25519 (ondersteun sedert OpenSSH 6.5) en ecdsa-sha2-nistp256/384 gebaseer op RFC521 ECDSA (ondersteun sedert OpenSSH 5656).
Bron: opennet.ru