Selepas empat bulan pembangunan melepaskan , pelaksanaan klien dan pelayan terbuka untuk bekerja melalui protokol SSH 2.0 dan SFTP.
Peningkatan utama dalam keluaran OpenSSH 8.2 ialah keupayaan untuk menggunakan pengesahan dua faktor dengan peranti yang menyokong protokol. , dibangunkan oleh perikatan itu U2F membolehkan penciptaan token perkakasan kos rendah untuk mengesahkan kehadiran fizikal pengguna, berinteraksi dengan mereka melalui USB, Bluetooth atau NFC. Peranti ini dipromosikan sebagai cara pengesahan dua faktor di tapak web, sudah disokong oleh penyemak imbas utama, dan dihasilkan oleh pelbagai pengeluar, termasuk Yubico, Feitian, Thetis dan Kensington.
Untuk berinteraksi dengan peranti yang mengesahkan kehadiran pengguna, OpenSSH telah menambah jenis kunci baharu, "ecdsa-sk" dan "ed25519-sk," yang menggunakan algoritma tandatangan digital ECDSA dan Ed25519 dalam kombinasi dengan cincang SHA-256. Prosedur untuk berinteraksi dengan token telah dialihkan ke perpustakaan perantaraan, yang dimuatkan sama dengan perpustakaan sokongan PKCS#11 dan bertindak sebagai pembalut di sekeliling perpustakaan. , yang menyediakan cara untuk berkomunikasi dengan token melalui USB (protokol FIDO U2F/CTAP 1 dan FIDO 2.0/CTAP 2 disokong). Pustaka perantaraan libsk-libfido2, disediakan oleh pembangun OpenSSH, ke dalam komposisi teras libfido2, serta untuk OpenBSD.
Untuk mengesahkan dan menjana kunci, anda mesti menentukan parameter "SecurityKeyProvider" dalam tetapan atau tetapkan pembolehubah persekitaran SSH_SK_PROVIDER, menentukan laluan ke perpustakaan luaran libsk-libfido2.so (eksport SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). OpenSSH boleh dibina dengan sokongan terbina dalam untuk perpustakaan perantara (--with-security-key-builtin); dalam kes ini, anda mesti menetapkan parameter "SecurityKeyProvider=internal".
Seterusnya, jalankan "ssh-keygen -t ecdsa-sk" atau, jika kekunci telah dibuat dan dikonfigurasikan, sambung ke pelayan menggunakan "ssh." Apabila anda menjalankan ssh-keygen, pasangan kunci yang dijana akan disimpan dalam "~/.ssh/id_ecdsa_sk" dan boleh digunakan seperti kekunci lain.
Kunci awam (id_ecdsa_sk.pub) hendaklah disalin ke fail authorized_keys pada pelayan. Pelayan hanya mengesahkan tandatangan digital, manakala interaksi token berlaku pada klien (libsk-libfido2 tidak perlu dipasang pada pelayan, tetapi pelayan mesti menyokong jenis kunci "ecdsa-sk"). Kunci persendirian yang dijana (id_ecdsa_sk) pada asasnya ialah deskriptor kunci yang membentuk kunci sebenar hanya apabila digabungkan dengan urutan rahsia yang disimpan pada token U2F. Jika penyerang memperoleh kunci id_ecdsa_sk, mereka juga memerlukan akses kepada token perkakasan untuk mengesahkan, tanpa kunci peribadi yang disimpan dalam fail id_ecdsa_sk tidak berguna.
Tambahan pula, secara lalai, semua operasi utama (kedua-dua penjanaan dan pengesahan) memerlukan pengesahan setempat tentang kehadiran fizikal pengguna, seperti menyentuh penderia pada token, menjadikannya sukar untuk melakukan serangan jauh pada sistem dengan token yang disambungkan. Sebagai lapisan keselamatan tambahan, kata laluan untuk mengakses fail kunci juga boleh ditetapkan semasa permulaan ssh-keygen.
Versi baharu OpenSSH juga mengumumkan penamatan algoritma yang akan datang menggunakan cincang SHA-1 disebabkan oleh keberkesanan serangan perlanggaran dengan awalan yang diberikan (kos memilih perlanggaran dianggarkan kira-kira 45 ribu dolar). 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 daripada ssh-rsa dalam sistem anda, anda boleh cuba menyambung melalui ssh dengan pilihan "-oHostKeyAlgorithm=-ssh-rsa").
Untuk melancarkan peralihan kepada algoritma baharu dalam OpenSSH, pada keluaran akan datang tetapan UpdateHostKeys akan didayakan secara lalai, yang secara automatik akan memindahkan pelanggan kepada algoritma yang lebih dipercayai. 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).
OpenSSH 8.2 masih menyokong penyambungan menggunakan "ssh-rsa", tetapi algoritma ini telah dialih keluar daripada senarai CASignatureAlgorithms, yang mentakrifkan algoritma yang dibenarkan untuk menandatangani sijil baharu secara digital. Begitu juga, algoritma diffie-hellman-group14-sha1 telah dialih keluar daripada algoritma pertukaran kunci lalai yang disokong. Adalah diperhatikan bahawa menggunakan SHA-1 dalam sijil membawa risiko tambahan, kerana penyerang mempunyai masa tanpa had untuk mencari perlanggaran bagi sijil sedia ada, manakala serangan pada kunci hos dihadkan oleh tamat masa sambungan (LoginGraceTime).
Apabila menjalankan ssh-keygen, algoritma rsa-sha2-512, yang disokong sejak OpenSSH 7.2, kini digunakan secara lalai, yang mungkin mewujudkan isu keserasian apabila cuba memproses sijil yang ditandatangani OpenSSH 8.2 pada sistem yang menjalankan keluaran OpenSSH yang lebih lama (untuk menyelesaikan isu ini, anda boleh menentukan secara eksplisit "ssh-keygen -t" apabila menghasilkan "ssh-keygen" -t algoritma ecdsa-sha2-nistp256/384/521 disokong sejak OpenSSH 5.7).
Perubahan lain:
- Arahan Sertakan telah ditambahkan pada sshd_config, membenarkan kandungan fail lain dimasukkan ke dalam kedudukan semasa fail konfigurasi (topeng glob boleh digunakan apabila menentukan nama fail);
- Pilihan "tidak perlu disentuh" telah ditambahkan pada ssh-keygen, yang melumpuhkan keperluan untuk pengesahan fizikal akses kepada token apabila menjana kunci;
- Arahan PubkeyAuthOptions telah ditambahkan pada sshd_config, menyatukan pelbagai pilihan yang berkaitan dengan pengesahan kunci awam. Pada masa ini, hanya bendera "tidak perlu disentuh" disokong, membenarkan untuk melangkau semakan kehadiran fizikal semasa pengesahan token. Begitu juga, pilihan "no-touch-required" telah ditambahkan pada fail authorized_keys.
- Pilihan "-O write-attestation=/path" telah ditambahkan pada ssh-keygen, membolehkan sijil pengesahan FIDO tambahan ditulis semasa menjana kunci. OpenSSH tidak menggunakan sijil ini pada masa ini, tetapi ia boleh digunakan pada masa hadapan untuk mengesahkan bahawa kunci disimpan dalam storan perkakasan yang dipercayai.
- Dalam tetapan ssh dan sshd, kini boleh menetapkan mod keutamaan trafik melalui arahan IPQoS. (Gelagat Per-Hop Usaha Rendah);
- Dalam ssh, apabila menetapkan nilai "AddKeysToAgent=yes", jika kunci tidak mengandungi medan ulasan, ia akan ditambahkan pada ssh-agent dengan laluan ke kunci yang ditentukan sebagai ulasan.
ssh-keygen dan ssh-agent kini turut menggunakan label PKCS#11 dan nama subjek X.509 sebagai ulasan dalam kunci dan bukannya laluan perpustakaan; - Menambahkan keupayaan untuk mengeksport PEM untuk kunci DSA dan ECDSA ke ssh-keygen;
- Menambahkan fail boleh laku baharu ssh-sk-helper, digunakan untuk mengasingkan akses perpustakaan kepada token FIDO/U2F;
- Menambahkan pilihan binaan "--with-zlib" pada ssh dan sshd untuk menyusun dengan sokongan perpustakaan zlib;
- Selaras dengan RFC 4253, amaran tentang akses disekat kerana melebihi had MaxStartups kini dipaparkan dalam sepanduk sambungan. Untuk memudahkan diagnostik, pengepala proses sshd, boleh dilihat menggunakan utiliti ps, kini memaparkan bilangan sambungan yang sedang disahkan dan status had MaxStartups.
- Dalam ssh dan ssh-agent, apabila memanggil program untuk memaparkan jemputan pada skrin, ditentukan melalui $SSH_ASKPASS, bendera dengan jenis jemputan kini juga diluluskan: “confirm” — dialog pengesahan (ya/tidak), “none” — mesej maklumat, “kosong” — permintaan kata laluan;
- Operasi tandatangan digital baharu "cari-pengetua" telah ditambahkan pada ssh-keygen untuk mencari fail penandatangan yang dibenarkan untuk pengguna yang dikaitkan dengan tandatangan digital yang ditentukan;
- Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Sumber: opennet.ru
