Na vyf maande se ontwikkeling word die vrystelling van OpenSSH 8.5, 'n oop implementering van 'n kliënt en bediener om oor die SSH 2.0- en SFTP-protokolle te werk, aangebied.
Die OpenSSH-ontwikkelaars het ons herinner aan die komende ontmanteling 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 geraam). In een van die komende vrystellings beplan hulle om by verstek die vermoë om die "ssh-rsa" publieke sleutel digitale handtekeningalgoritme te gebruik, wat in die oorspronklike RFC vir die SSH-protokol genoem word en wydverspreid in die praktyk bly, te deaktiveer.
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 8.5 die UpdateHostKeys-instelling by verstek geaktiveer, wat kliënte toelaat om outomaties oor te skakel na meer betroubare algoritmes. 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).
Ander veranderinge:
- Sekuriteitsveranderinge:
- 'n Kwesbaarheid wat veroorsaak word deur die herbevryding van 'n reeds vrygestelde geheue-area (dubbelvry) is in ssh-agent reggestel. Die probleem is teenwoordig sedert die vrystelling van OpenSSH 8.2 en kan moontlik uitgebuit word as 'n aanvaller toegang het tot die ssh-agent-sok op die plaaslike stelsel. Wat uitbuiting moeiliker maak, is dat slegs root en die oorspronklike gebruiker toegang tot die sok het. Die mees waarskynlike aanvalscenario is dat die agent herlei word na 'n rekening wat deur die aanvaller beheer word, of na 'n gasheer waar die aanvaller worteltoegang het.
- sshd het beskerming bygevoeg teen die oordrag van baie groot parameters met die gebruikernaam na die PAM-substelsel, wat jou toelaat om kwesbaarhede in die PAM (Pluggable Authentication Module) stelselmodules te blokkeer. Byvoorbeeld, die verandering verhoed dat sshd as 'n vektor gebruik word om 'n onlangs ontdekte wortelkwesbaarheid in Solaris (CVE-2020-14871) te ontgin.
- Veranderinge aan versoenbaarheid wat moontlik breek:
- In ssh en sshd is 'n eksperimentele sleuteluitruilmetode herontwerp wat bestand is teen raai op 'n kwantumrekenaar. Kwantumrekenaars is radikaal vinniger om die probleem op te los om 'n natuurlike getal in priemfaktore te ontbind, wat onder moderne asimmetriese enkripsiealgoritmes lê en nie effektief op klassieke verwerkers opgelos kan word nie. Die metode wat gebruik word, is gebaseer op die NTRU Prime algoritme, ontwikkel vir post-kwantum kriptostelsels, en die X25519 elliptiese kurwe sleutel uitruil metode. In plaas van [e-pos beskerm] die metode word nou geïdentifiseer as [e-pos beskerm] (die sntrup4591761-algoritme is vervang deur sntrup761).
- In ssh en sshd is die volgorde waarin ondersteunde digitale handtekeningalgoritmes aangekondig word, verander. ED25519 word nou eerste in plaas van ECDSA aangebied.
- In ssh en sshd word die instelling van TOS/DSCP-kwaliteit van diensparameters vir interaktiewe sessies nou gedoen voordat 'n TCP-verbinding tot stand gebring word.
- Cipher-ondersteuning is gestaak in ssh en sshd [e-pos beskerm], wat identies is aan aes256-cbc en gebruik is voordat RFC-4253 goedgekeur is.
- By verstek is die CheckHostIP-parameter gedeaktiveer, waarvan die voordeel weglaatbaar is, maar die gebruik daarvan bemoeilik sleutelrotasie aansienlik vir gashere agter lasbalanseerders.
- PerSourceMaxStartups- en PerSourceNetBlockSize-instellings is by sshd gevoeg om die intensiteit van die bekendstelling van hanteerders op grond van die kliëntadres te beperk. Hierdie parameters laat jou toe om die limiet op prosesbekendstellings fyner te beheer, in vergelyking met die algemene MaxStartups-instelling.
- 'n Nuwe LogVerbose-instelling is by ssh en sshd gevoeg, wat jou in staat stel om die vlak van ontfoutingsinligting wat in die log gestort word, met die vermoë om volgens sjablone, funksies en lêers te filtreer, kragtig te verhoog.
- In ssh, wanneer 'n nuwe gasheersleutel aanvaar word, word alle gasheername en IP-adresse wat met die sleutel geassosieer word, vertoon.
- ssh laat die UserKnownHostsFile=geen opsie toe om die gebruik van die known_hosts-lêer te deaktiveer wanneer gasheersleutels geïdentifiseer word.
- 'n KnownHostsCommand-instelling is by ssh_config vir ssh gevoeg, wat jou in staat stel om known_hosts-data van die afvoer van die gespesifiseerde opdrag te kry.
- Het 'n PermitRemoteOpen-opsie by ssh_config vir ssh bygevoeg sodat jy die bestemming kan beperk wanneer jy die RemoteForward-opsie met SOCKS gebruik.
- In ssh vir FIDO-sleutels word 'n herhaalde PIN-versoek verskaf in die geval van 'n digitale handtekeningbewerkingsmislukking as gevolg van 'n verkeerde PIN en die gebruiker word nie vir 'n PIN gevra nie (byvoorbeeld wanneer die korrekte biometriese data nie verkry kon word nie en die toestel het teruggeval na handmatige PIN-invoer).
- sshd voeg ondersteuning vir bykomende stelseloproepe by die seccomp-bpf-gebaseerde prosesisolasiemeganisme op Linux.
- Die bydrae/ssh-copy-id-hulpmiddel is opgedateer.
Bron: opennet.ru