După patru luni de dezvoltare, a fost prezentată lansarea OpenSSH 8.7, o implementare deschisă a unui client și server pentru lucrul peste protocoalele SSH 2.0 și SFTP.
Principalele modificări:
- Un mod experimental de transfer de date a fost adăugat la scp folosind protocolul SFTP în loc de protocolul tradițional SCP/RCP. SFTP folosește metode mai previzibile de gestionare a numelor și nu utilizează procesarea shell a modelelor glob de partea celeilalte gazde, ceea ce creează probleme de securitate. Pentru a activa SFTP în scp, a fost propus indicatorul „-s”, dar în viitor se plănuiește trecerea implicită la acest protocol.
- sftp-server implementează extensii la protocolul SFTP pentru a extinde căile ~/ și ~user/, care sunt necesare pentru scp.
- Utilitarul scp a schimbat comportamentul la copierea fișierelor între două gazde la distanță (de exemplu, „scp host-a:/path host-b:”), ceea ce se face acum implicit printr-o gazdă locală intermediară, ca atunci când se specifică „ -3” steag. Această abordare vă permite să evitați transmiterea acreditărilor inutile către prima gazdă și interpretarea triplă a numelor de fișiere din shell (pe partea sursă, destinație și sistemul local), iar atunci când utilizați SFTP, vă permite să utilizați toate metodele de autentificare atunci când accesați la distanță. gazde, și nu doar metode non-interactive. Opțiunea „-R” a fost adăugată pentru a restabili vechiul comportament.
- S-a adăugat setarea ForkAfterAuthentication la ssh corespunzătoare steagului „-f”.
- S-a adăugat setarea StdinNull la ssh, corespunzătoare steagului „-n”.
- La ssh a fost adăugată o setare SessionType, prin care puteți seta modurile corespunzătoare steagurilor „-N” (fără sesiune) și „-s” (subsistem).
- ssh-keygen vă permite să specificați un interval de valabilitate a cheii în fișierele cheie.
- S-a adăugat flag „-Oprint-pubkey” la ssh-keygen pentru a tipări cheia publică completă ca parte a semnăturii sshsig.
- În ssh și sshd, atât clientul, cât și serverul au fost mutați pentru a utiliza un parser de fișiere de configurare mai restrictiv care utilizează reguli de tip shell pentru gestionarea ghilimelelor, spațiilor și caracterelor de escape. De asemenea, noul analizator nu ignoră ipotezele făcute anterior, cum ar fi omiterea argumentelor în opțiuni (de exemplu, directiva DenyUsers nu mai poate fi lăsată goală), ghilimele neînchise și specificarea mai multor = caractere.
- Când utilizați înregistrările DNS SSHFP la verificarea cheilor, ssh verifică acum toate înregistrările care se potrivesc, nu doar cele care conțin un anumit tip de semnătură digitală.
- În ssh-keygen, atunci când se generează o cheie FIDO cu opțiunea -Ochallenge, stratul încorporat este acum utilizat pentru hashing, mai degrabă decât libfido2, care permite utilizarea secvențelor de provocare mai mari sau mai mici de 32 de octeți.
- În sshd, când se procesează directivele environment="..." în fișierele authorized_keys, prima potrivire este acum acceptată și există o limită de 1024 de nume de variabile de mediu.
Dezvoltatorii OpenSSH au avertizat și despre descompunerea algoritmilor folosind hash-uri SHA-1 din cauza eficienței crescute a atacurilor de coliziune cu un prefix dat (costul de selectare a unei coliziuni este estimat la aproximativ 50 de mii de dolari). În următoarea ediție, intenționăm să dezactivăm implicit capacitatea de a utiliza algoritmul de semnătură digitală cu cheie publică „ssh-rsa”, care a fost menționat în RFC original pentru protocolul SSH și rămâne utilizat pe scară largă în practică.
Pentru a testa utilizarea ssh-rsa pe sistemele dvs., puteți încerca să vă conectați prin ssh cu opțiunea „-oHostKeyAlgorithms=-ssh-rsa”. În același timp, dezactivarea implicită a semnăturilor digitale „ssh-rsa” nu înseamnă o abandonare completă a utilizării cheilor RSA, deoarece pe lângă SHA-1, protocolul SSH permite utilizarea altor algoritmi de calcul hash. În special, pe lângă „ssh-rsa”, va rămâne posibilă utilizarea pachetelor „rsa-sha2-256” (RSA/SHA256) și „rsa-sha2-512” (RSA/SHA512).
Pentru a ușura tranziția la noi algoritmi, OpenSSH avea anterior setarea UpdateHostKeys activată în mod implicit, ceea ce permite clienților să treacă automat la algoritmi mai fiabili. Folosind această setare, este activată o extensie specială de protocol „[e-mail protejat]", permițând serverului, după autentificare, să informeze clientul despre toate cheile de gazdă disponibile. Clientul poate reflecta aceste chei în fișierul său ~/.ssh/known_hosts, care permite ca cheile gazdei să fie actualizate și ușurează schimbarea cheilor pe server.
Utilizarea UpdateHostKeys este limitată de câteva avertismente care pot fi eliminate în viitor: cheia trebuie să fie referită în UserKnownHostsFile și nu utilizată în GlobalKnownHostsFile; cheia trebuie să fie prezentă sub un singur nume; nu trebuie utilizat un certificat de cheie de gazdă; în cunoscute_gazde nu trebuie folosite măști după numele gazdei; setarea VerifyHostKeyDNS trebuie dezactivată; Parametrul UserKnownHostsFile trebuie să fie activ.
Algoritmii recomandați pentru migrare includ rsa-sha2-256/512 bazat pe RFC8332 RSA SHA-2 (acceptat începând cu OpenSSH 7.2 și utilizat implicit), ssh-ed25519 (acceptat începând cu OpenSSH 6.5) și ecdsa-sha2-nistp256/384 based pe RFC521 ECDSA (acceptat începând cu OpenSSH 5656).
Sursa: opennet.ru