Az OpenSSH 8.0 kiadása

Öt hónapos fejlesztés után bemutatott kiadás OpenSSH 8.0, egy nyílt kliens és kiszolgáló megvalósítás az SSH 2.0 és SFTP protokollokon keresztül történő munkához.

Nagy változások:

  • Kísérleti támogatást nyújtottak az ssh-hoz és az sshd-hez egy olyan kulcscsere-módszerhez, amely ellenáll a kvantumszámítógépek elleni brute-force támadásoknak. A kvantumszámítógépek radikálisan gyorsabban oldják meg a természetes számok prímtényezőkre bontásának problémáját, amely a modern aszimmetrikus titkosítási algoritmusok hátterében áll, és nem oldható meg hatékonyan a klasszikus processzorokon. A javasolt módszer az algoritmuson alapul NTRU Prime (függvény ntrup4591761), posztkvantum kriptorendszerekhez kifejlesztett és az X25519 elliptikus görbe kulcscsere módszere;
  • Az sshd-ben a ListenAddress és a PermitOpen direktívák már nem támogatják a régi "host/port" szintaxist, amelyet 2001-ben vezettek be a "host:port" alternatívájaként az IPv6-tal való munka egyszerűsítése érdekében. A modern körülmények között a „[::6]:1” szintaxist az IPv22-hoz hozták létre, és a „gazda/port” kifejezést gyakran összekeverik az alhálózat (CIDR) jelzésével;
  • Az ssh, az ssh-agent és az ssh-add már támogatja a kulcsokat ECDSA PKCS#11 tokenekben;
  • Az ssh-keygenben az alapértelmezett RSA kulcs mérete 3072 bitre nőtt, az új NIST ajánlásoknak megfelelően;
  • Az ssh lehetővé teszi a "PKCS11Provider=none" beállítás használatát az ssh_config paraméterben megadott PKCS11Provider direktíva felülbírálására;
  • Az sshd naplózást biztosít azokról a helyzetekről, amikor a kapcsolat megszakad, amikor olyan parancsokat próbálnak végrehajtani, amelyeket az sshd_config „ForceCommand=internal-sftp” korlátozása blokkol;
  • Az ssh-ban az új gazdakulcs elfogadásának megerősítésére vonatkozó kérés megjelenítésekor az „igen” válasz helyett a kulcs helyes ujjlenyomata kerül elfogadásra (a kapcsolat megerősítésére vonatkozó felhívásra válaszul a felhasználó másolhatja a külön kapott referenciakivonat a vágólapon keresztül, hogy ne kézzel hasonlítsa össze);
  • Az ssh-keygen biztosítja a tanúsítvány sorszámának automatikus növelését, amikor több tanúsítványhoz digitális aláírást hoz létre a parancssorban;
  • Az scp és az sftp új "-J" opcióval egyenértékű a ProxyJump beállítással;
  • Az ssh-agent, az ssh-pkcs11-helper és az ssh-add esetén a „-v” parancssori opció feldolgozása hozzáadásra került a kimenet információtartalmának növelése érdekében (ha meg van adva, ez az opció továbbadódik a gyermekfolyamatoknak, pl. például, amikor az ssh-pkcs11-helpert az ssh-agent hívja meg );
  • A „-T” opció hozzáadásra került az ssh-add-hoz, hogy tesztelje az ssh-agent kulcsainak alkalmasságát a digitális aláírás létrehozására és ellenőrzésére;
  • Az sftp-server támogatja az „lsetstat at openssh.com” protokollbővítményt, amely támogatja az SSH2_FXP_SETSTAT műveletet az SFTP-hez, de szimbolikus hivatkozások követése nélkül;
  • "-h" opció hozzáadva az sftp-hez a chown/chgrp/chmod parancsok futtatásához olyan kérésekkel, amelyek nem használnak szimbolikus hivatkozásokat;
  • Az sshd biztosítja a $SSH_CONNECTION környezeti változó beállítását a PAM számára;
  • Az sshd esetében egy „Match final” illesztési mód került hozzáadásra az ssh_config paraméterhez, amely hasonló a „Match canonical”-hoz, de nem szükséges engedélyezni a gazdagépnév normalizálását;
  • Az sftp „@” előtagjának támogatása a kötegelt módban végrehajtott parancsok kimenetének fordításának letiltásához;
  • Amikor a paranccsal megjeleníti egy tanúsítvány tartalmát
    Az "ssh-keygen -Lf /útvonal/tanúsítvány" most megjeleníti a CA által a tanúsítvány érvényesítésére használt algoritmust;

  • Továbbfejlesztett támogatás a Cygwin környezethez, például lehetővé teszi a csoport- és felhasználónevek kis- és nagybetűk megkülönböztetését. Az sshd folyamat a Cygwin portban cygsshd-re módosult, hogy elkerüljük a Microsoft által biztosított OpenSSH porttal való interferenciát;
  • Hozzáadtuk a kísérleti OpenSSL 3.x ággal való építkezés lehetőségét;
  • Eltüntetett sebezhetőség (CVE-2019-6111) az scp segédprogram megvalósításában, amely lehetővé teszi a célkönyvtárban lévő tetszőleges fájlok ügyféloldali felülírását, amikor egy támadó által vezérelt kiszolgálóhoz érik el. A probléma az, hogy scp használatakor a szerver dönti el, hogy mely fájlokat és könyvtárakat küldje el a kliensnek, a kliens pedig csak a visszaadott objektumnevek helyességét ellenőrzi. Az ügyféloldali ellenőrzés csak az aktuális könyvtáron túli utazás blokkolására korlátozódik (../), de nem veszi figyelembe az eredetileg kérttől eltérő nevű fájlok átvitelét. Rekurzív másolás (-r) esetén a fájlnevek mellett az alkönyvtárak neveit is hasonló módon manipulálhatjuk. Például, ha a felhasználó fájlokat másol a kezdőkönyvtárba, a támadó által vezérelt szerver a kért fájlok helyett .bash_aliases vagy .ssh/authorized_keys nevű fájlokat állíthat elő, és ezeket az scp segédprogram elmenti a felhasználó könyvtárába. kezdőkönyvtár.

    Az új kiadásban az scp segédprogram frissítésre került, hogy ellenőrizze a kért és a szerver által küldött fájlnevek közötti megfelelést, ami a kliens oldalon történik. Ez problémákat okozhat a maszkfeldolgozás során, mivel a maszkbővítési karakterek feldolgozása eltérő lehet a szerver és a kliens oldalon. Abban az esetben, ha az ilyen eltérések miatt a kliens leállítja az scp fájlok elfogadását, a „-T” opció hozzáadásra került az ügyféloldali ellenőrzés letiltásához. A probléma teljes kijavításához az scp protokoll koncepcionális átdolgozása szükséges, amely maga már elavult, ezért javasolt helyette korszerűbb protokollokat használni, mint például az sftp és az rsync.

Forrás: opennet.ru

Hozzászólás