ProHoster > Keluaran OpenSSH 8.2 dengan sokongan untuk token pengesahan dua faktor FIDO/U2F

Keluaran OpenSSH 8.2 dengan sokongan untuk token pengesahan dua faktor FIDO/U2F

Selepas empat bulan pembangunan dibentangkan melepaskan OpenSSH 8.2, 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 menggunakan peranti yang menyokong protokol U2F, dibangunkan oleh perikatan itu FIDO. U2F membenarkan penciptaan token perkakasan kos rendah untuk mengesahkan kehadiran fizikal pengguna, berinteraksi dengan mereka melalui USB, Bluetooth atau NFC. Peranti sedemikian dipromosikan sebagai cara pengesahan dua faktor di tapak web, sudah disokong oleh pelayar utama dan dihasilkan oleh pelbagai pengeluar, termasuk Yubico, Feitian, Thetis dan Kensington.

Untuk berinteraksi dengan peranti yang mengesahkan kehadiran pengguna, jenis kunci baharu "ecdsa-sk" dan "ed25519-sk" telah ditambahkan pada OpenSSH, yang menggunakan algoritma tandatangan digital ECDSA dan Ed25519, digabungkan dengan cincang SHA-256. Prosedur untuk berinteraksi dengan token diletakkan di perpustakaan perantaraan, yang dimuatkan dengan cara yang sama seperti perpustakaan untuk sokongan PKCS#11 dan merupakan pembungkus di atas perpustakaan libfido2, yang menyediakan alatan untuk berkomunikasi dengan token melalui USB (protokol FIDO U2F/CTAP 1 dan FIDO 2.0/CTAP 2 disokong). Perpustakaan perantaraan libsk-libfido2 disediakan oleh pembangun OpenSSH termasuk ke dalam libfido2 teras, serta Pemandu HID untuk OpenBSD.

Untuk mengesahkan dan menjana kunci, anda mesti menentukan parameter "SecurityKeyProvider" dalam tetapan atau tetapkan pembolehubah persekitaran SSH_SK_PROVIDER, menunjukkan laluan ke perpustakaan luaran libsk-libfido2.so (eksport SSH_SK_PROVIDER=/path/to/libsk-libfido2. jadi). Ia adalah mungkin untuk membina openssh dengan sokongan terbina dalam untuk perpustakaan lapisan (--dengan-kunci-terbina-keselamatan), dalam kes ini anda perlu menetapkan parameter "SecurityKeyProvider=dalaman".
Seterusnya anda perlu menjalankan "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 sama dengan kunci lain.

Kunci awam (id_ecdsa_sk.pub) hendaklah disalin ke pelayan dalam fail authorized_keys. Di bahagian pelayan, hanya tandatangan digital yang disahkan, dan interaksi dengan token dilakukan pada bahagian klien (anda tidak perlu memasang libsk-libfido2 pada pelayan, tetapi pelayan mesti menyokong jenis kunci "ecdsa-sk") . Kunci persendirian yang dijana (id_ecdsa_sk) pada asasnya ialah pemegang kunci, membentuk kunci sebenar hanya dalam kombinasi dengan urutan rahsia yang disimpan pada bahagian token U2F. Jika kunci id_ecdsa_sk jatuh ke tangan penyerang, untuk lulus pengesahan dia juga perlu mendapatkan akses kepada token perkakasan, tanpa kunci peribadi yang disimpan dalam fail id_ecdsa_sk tidak berguna.

Di samping itu, secara lalai, apabila melakukan sebarang operasi dengan kunci (semasa penjanaan dan semasa pengesahan), pengesahan tempatan kehadiran fizikal pengguna diperlukan, sebagai contoh, adalah dicadangkan untuk menyentuh sensor pada token, yang menjadikannya sukar untuk melakukan serangan jauh pada sistem dengan token yang disambungkan. Sebagai barisan pertahanan lain, kata laluan juga boleh ditentukan semasa fasa permulaan ssh-keygen untuk mengakses fail kunci.

Versi baharu OpenSSH juga mengumumkan penamatan algoritma yang akan datang menggunakan cincang SHA-1 disebabkan oleh kenaikan pangkat 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).

Dalam OpenSSH 8.2, keupayaan untuk menyambung menggunakan "ssh-rsa" masih tersedia, 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 penggunaan SHA-1 dalam sijil dikaitkan dengan risiko tambahan, kerana penyerang mempunyai masa tanpa had untuk mencari perlanggaran bagi sijil sedia ada, manakala masa serangan pada kunci hos dihadkan oleh tamat masa sambungan (LoginGraceTime ).

Menjalankan ssh-keygen kini lalai kepada algoritma rsa-sha2-512, yang disokong sejak OpenSSH 7.2, yang mungkin mencipta isu keserasian apabila cuba memproses sijil yang ditandatangani dalam OpenSSH 8.2 pada sistem yang menjalankan keluaran OpenSSH yang lebih lama (untuk menyelesaikan masalah apabila Apabila Apabila menjana tandatangan, anda boleh menentukan secara eksplisit "ssh-keygen -t ssh-rsa" atau menggunakan algoritma ecdsa-sha2-nistp256/384/521, disokong sejak OpenSSH 5.7).

Perubahan lain:

  • Arahan Sertakan telah ditambahkan pada sshd_config, yang membolehkan anda memasukkan kandungan fail lain pada 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 mengesahkan akses kepada token secara fizikal apabila menjana kunci;
  • Arahan PubkeyAuthOptions telah ditambahkan pada sshd_config, yang menggabungkan pelbagai pilihan yang berkaitan dengan pengesahan kunci awam. Pada masa ini, hanya bendera "tidak perlu disentuh" ​​disokong untuk melangkau semakan kehadiran fizikal untuk pengesahan token. Dengan analogi, pilihan "tidak perlu disentuh" ​​telah ditambahkan pada fail authorized_keys;
  • Menambahkan pilihan "-O write-attestation=/path" pada ssh-keygen untuk membenarkan sijil pengesahan FIDO tambahan ditulis semasa menjana kunci. OpenSSH belum lagi menggunakan sijil ini, tetapi ia boleh digunakan kemudian untuk mengesahkan bahawa kunci diletakkan di kedai perkakasan yang dipercayai;
  • Dalam tetapan ssh dan sshd, kini boleh menetapkan mod keutamaan trafik melalui arahan IPQoS LE DSCP (Kelakuan Per-Hop Usaha Rendah);
  • Dalam ssh, apabila menetapkan nilai "AddKeysToAgent=yes", jika kunci tidak mengandungi medan ulasan, ia akan ditambahkan pada ssh-agent yang menunjukkan laluan ke kunci sebagai ulasan. DALAM
    ssh-keygen dan ssh-agent juga kini menggunakan label PKCS#11 dan nama subjek X.509 dan bukannya laluan perpustakaan sebagai ulasan dalam kunci;

  • Menambahkan keupayaan untuk mengeksport PEM untuk kunci DSA dan ECDSA ke ssh-keygen;
  • Menambahkan boleh laku baharu, ssh-sk-helper, digunakan untuk mengasingkan perpustakaan akses token FIDO/U2F;
  • Menambahkan pilihan binaan "--dengan-zlib" pada ssh dan sshd untuk penyusunan dengan sokongan perpustakaan zlib;
  • Selaras dengan keperluan RFC4253, amaran tentang penyekatan akses kerana melebihi had MaxStartups disediakan dalam sepanduk yang dipaparkan semasa sambungan. Untuk memudahkan diagnostik, pengepala proses sshd, kelihatan apabila 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 dihantar tambahan: β€œconfirm” - dialog pengesahan (ya/tidak), β€œnone ” - mesej maklumat, β€œkosong” β€” permintaan kata laluan;
  • Menambahkan operasi tandatangan digital baharu "cari-pengetua" ke ssh-keygen untuk mencari fail penandatangan yang dibenarkan untuk pengguna yang dikaitkan dengan tandatangan digital tertentu;
  • Sokongan yang lebih baik untuk pengasingan proses sshd pada Linux menggunakan mekanisme seccomp: melumpuhkan panggilan sistem IPC, membenarkan clock_gettime64(), clock_nanosleep_time64 dan clock_nanosleep().

Sumber: opennet.ru

Tambah komen