Keluaran OpenSSH 8.5

Selepas lima bulan pembangunan, keluaran OpenSSH 8.5, pelaksanaan terbuka klien dan pelayan untuk bekerja melalui protokol SSH 2.0 dan SFTP, dibentangkan.

Pembangun OpenSSH mengingatkan kami tentang penyahtauliahan algoritma yang akan datang menggunakan cincang SHA-1 disebabkan oleh peningkatan kecekapan serangan perlanggaran dengan awalan tertentu (kos memilih perlanggaran dianggarkan kira-kira $50 ribu). Dalam salah satu keluaran yang akan datang, mereka merancang untuk melumpuhkan secara lalai keupayaan untuk menggunakan algoritma tandatangan digital kunci awam "ssh-rsa", yang disebut dalam RFC asal untuk protokol SSH dan kekal meluas dalam amalan.

Untuk menguji penggunaan ssh-rsa pada sistem anda, anda boleh cuba menyambung melalui ssh dengan pilihan β€œ-oHostKeyAlgorithm=-ssh-rsa”. Pada masa yang sama, melumpuhkan tandatangan digital "ssh-rsa" secara lalai tidak bermakna pengabaian sepenuhnya penggunaan kekunci RSA, kerana sebagai tambahan kepada SHA-1, protokol SSH membenarkan penggunaan algoritma pengiraan cincang yang lain. Khususnya, sebagai tambahan kepada "ssh-rsa", ia masih boleh digunakan untuk menggunakan berkas "rsa-sha2-256" (RSA/SHA256) dan "rsa-sha2-512" (RSA/SHA512).

Untuk melancarkan peralihan kepada algoritma baharu, OpenSSH 8.5 mempunyai tetapan UpdateHostKeys didayakan secara lalai, yang membolehkan pelanggan bertukar secara automatik kepada algoritma yang lebih dipercayai. Menggunakan tetapan ini, sambungan protokol khas didayakan "[e-mel dilindungi]", membenarkan pelayan, selepas pengesahan, untuk memaklumkan klien tentang semua kunci hos yang tersedia. Pelanggan boleh mencerminkan kunci ini dalam fail ~/.ssh/known_hosts, yang membolehkan kunci hos dikemas kini dan memudahkan untuk menukar kunci pada pelayan.

Penggunaan UpdateHostKeys dihadkan oleh beberapa kaveat yang mungkin dialih keluar pada masa hadapan: kunci mesti dirujuk dalam UserKnownHostsFile dan tidak digunakan dalam GlobalKnownHostsFile; kunci mesti ada di bawah satu nama sahaja; sijil kunci hos tidak boleh digunakan; dalam known_hosts topeng dengan nama hos tidak boleh digunakan; tetapan VerifyHostKeyDNS mesti dilumpuhkan; Parameter UserKnownHostsFile mesti aktif.

Algoritma yang disyorkan untuk penghijrahan termasuk rsa-sha2-256/512 berdasarkan RFC8332 RSA SHA-2 (disokong sejak OpenSSH 7.2 dan digunakan secara lalai), ssh-ed25519 (disokong sejak OpenSSH 6.5) dan berasaskan ecdsa-sha2-nistp256/384/521 pada RFC5656 ECDSA (disokong sejak OpenSSH 5.7).

Perubahan lain:

  • Perubahan keselamatan:
    • Kerentanan yang disebabkan oleh membebaskan semula kawasan memori yang telah dibebaskan (bebas berganda) telah diperbaiki dalam ssh-agent. Isu ini telah wujud sejak keluaran OpenSSH 8.2 dan berpotensi dieksploitasi jika penyerang mempunyai akses kepada soket ejen ssh pada sistem setempat. Apa yang menjadikan eksploitasi lebih sukar ialah hanya root dan pengguna asal mempunyai akses kepada soket. Senario serangan yang paling berkemungkinan ialah ejen dihalakan semula ke akaun yang dikawal oleh penyerang, atau ke hos di mana penyerang mempunyai akses root.
    • sshd telah menambah perlindungan daripada menghantar parameter yang sangat besar dengan nama pengguna ke subsistem PAM, yang membolehkan anda menyekat kelemahan dalam modul sistem PAM (Modul Pengesahan Boleh Pasang). Sebagai contoh, perubahan itu menghalang sshd daripada digunakan sebagai vektor untuk mengeksploitasi kerentanan akar yang ditemui baru-baru ini dalam Solaris (CVE-2020-14871).
  • Perubahan keserasian yang berpotensi memecahkan:
    • Π’ ssh ΠΈ sshd ΠΏΠ΅Ρ€Π΅Ρ€Π°Π±ΠΎΡ‚Π°Π½ ΡΠΊΡΠΏΠ΅Ρ€ΠΈΠΌΠ΅Π½Ρ‚Π°Π»ΡŒΠ½Ρ‹ΠΉ ΠΌΠ΅Ρ‚ΠΎΠ΄ ΠΎΠ±ΠΌΠ΅Π½Π° ΠΊΠ»ΡŽΡ‡Π°ΠΌΠΈ, стойкий ΠΊ ΠΏΠΎΠ΄Π±ΠΎΡ€Ρƒ Π½Π° ΠΊΠ²Π°Π½Ρ‚ΠΎΠ²ΠΎΠΌ ΠΊΠΎΠΌΠΏΡŒΡŽΡ‚Π΅Ρ€Π΅. ΠšΠ²Π°Π½Ρ‚ΠΎΠ²Ρ‹Π΅ ΠΊΠΎΠΌΠΏΡŒΡŽΡ‚Π΅Ρ€Ρ‹ ΠΊΠ°Ρ€Π΄ΠΈΠ½Π°Π»ΡŒΠ½ΠΎ быстрСС Ρ€Π΅ΡˆΠ°ΡŽΡ‚ Π·Π°Π΄Π°Ρ‡Ρƒ разлоТСния Π½Π°Ρ‚ΡƒΡ€Π°Π»ΡŒΠ½ΠΎΠ³ΠΎ числа Π½Π° простыС ΠΌΠ½ΠΎΠΆΠΈΡ‚Π΅Π»ΠΈ, которая Π»Π΅ΠΆΠΈΡ‚ Π² основС соврСмСнных асиммСтричных Π°Π»Π³ΠΎΡ€ΠΈΡ‚ΠΌΠΎΠ² ΡˆΠΈΡ„Ρ€ΠΎΠ²Π°Π½ΠΈΡ ΠΈ эффСктивно Π½Π΅ Ρ€Π΅ΡˆΠ°Π΅ΠΌΠ° Π½Π° классичСских процСссорах. Π˜ΡΠΏΠΎΠ»ΡŒΠ·ΡƒΠ΅ΠΌΡ‹ΠΉ ΠΌΠ΅Ρ‚ΠΎΠ΄ основан Π½Π° Π°Π»Π³ΠΎΡ€ΠΈΡ‚ΠΌΠ΅ NTRU Prime, Ρ€Π°Π·Ρ€Π°Π±ΠΎΡ‚Π°Π½Π½ΠΎΠΌ для постквантумных криптосистСм, ΠΈ ΠΌΠ΅Ρ‚ΠΎΠ΄Π΅ ΠΎΠ±ΠΌΠ΅Π½Π° ΠΊΠ»ΡŽΡ‡Π°ΠΌΠΈ Π½Π° Π±Π°Π·Π΅ эллиптичСских ΠΊΡ€ΠΈΠ²Ρ‹Ρ… X25519. ВмСсто [e-mel dilindungi] ΠΌΠ΅Ρ‚ΠΎΠ΄ Ρ‚Π΅ΠΏΠ΅Ρ€ΡŒ идСнтифицируСтся ΠΊΠ°ΠΊ [e-mel dilindungi] (algoritma sntrup4591761 telah digantikan oleh sntrup761).
    • Dalam ssh dan sshd, susunan algoritma tandatangan digital yang disokong diumumkan telah diubah. ED25519 kini ditawarkan dahulu berbanding ECDSA.
    • Dalam ssh dan sshd, menetapkan kualiti TOS/DSCP parameter perkhidmatan untuk sesi interaktif kini dilakukan sebelum mewujudkan sambungan TCP.
    • Sokongan sifir telah dihentikan dalam ssh dan sshd [e-mel dilindungi], yang sama dengan aes256-cbc dan telah digunakan sebelum RFC-4253 diluluskan.
    • Secara lalai, parameter CheckHostIP dinyahdayakan, faedahnya boleh diabaikan, tetapi penggunaannya merumitkan putaran kunci dengan ketara untuk hos di belakang pengimbang beban.
  • Tetapan PerSourceMaxStartups dan PerSourceNetBlockSize telah ditambahkan pada sshd untuk mengehadkan keamatan pengendali pelancaran berdasarkan alamat klien. Parameter ini membolehkan anda mengawal had pelancaran proses dengan lebih halus, berbanding tetapan MaxStartups umum.
  • Tetapan LogVerbose baharu telah ditambahkan pada ssh dan sshd, yang membolehkan anda menaikkan secara paksa tahap maklumat penyahpepijatan yang dibuang ke dalam log, dengan keupayaan untuk menapis mengikut templat, fungsi dan fail.
  • Dalam ssh, apabila menerima kunci hos baharu, semua nama hos dan alamat IP yang dikaitkan dengan kunci ditunjukkan.
  • ssh membenarkan pilihan UserKnownHostsFile=none untuk melumpuhkan penggunaan fail known_hosts apabila mengenal pasti kunci hos.
  • Tetapan KnownHostsCommand telah ditambahkan pada ssh_config untuk ssh, membolehkan anda mendapatkan data known_hosts daripada output arahan yang ditentukan.
  • Menambah pilihan PermitRemoteOpen ke ssh_config untuk ssh untuk membolehkan anda menyekat destinasi apabila menggunakan pilihan RemoteForward dengan SOCKS.
  • Dalam ssh untuk kunci FIDO, permintaan PIN berulang diberikan sekiranya berlaku kegagalan operasi tandatangan digital disebabkan oleh PIN yang salah dan pengguna tidak digesa untuk PIN (contohnya, apabila data biometrik yang betul tidak dapat diperoleh dan peranti jatuh kembali ke kemasukan PIN manual).
  • sshd menambah sokongan untuk panggilan sistem tambahan kepada mekanisme pengasingan proses berasaskan seccomp-bpf pada Linux.
  • Utiliti contrib/ssh-copy-id telah dikemas kini.

Sumber: opennet.ru

Tambah komen