Cara Semak SSH Pasca-Kuantum pada Ubuntu

Apa yang berubah dalam SSH pasca-kuantum

SSH pasca-kuantum sudah diaktifkan untuk kebanyakan pengguna, dan tiada sesiapa perlu mengkonfigurasinya. Klien OpenSSH semasa yang berhubung dengan pelayan OpenSSH semasa akan memilih pertukaran kunci hibrid pasca-kuantum secara lalai. Oleh itu, kunci sesi tersebut mampu menahan serangan daripada pihak yang merekod trafik anda hari ini untuk dinyahsulit pada masa hadapan. Perlindungan ini adalah nyata, namun skopnya lebih terhad daripada apa yang digambarkan oleh frasa "SSH selamat-kuantum".

Dua istilah perlu dijelaskan terlebih dahulu. SSH (secure shell) ialah protokol yang anda gunakan untuk log masuk ke pelayan. Pertukaran kunci, yang biasanya ditulis sebagai "kex", merupakan langkah pertama bagi setiap sambungan SSH: kedua-dua pihak bersetuju mengenai rahsia kongsi, dan rahsia tersebut menyulitkan segala data yang menyusul. Pertukaran kunci inilah bahagian yang berubah. Tiada bahagian lain yang berubah.

Jangan percayai halaman ini, jalankan perintah tersebut

Setiap nama algoritma di bawah diperoleh daripada perintah yang boleh anda jalankan sendiri. Ini dilakukan dengan sengaja. Lalai (default) berubah mengikut setiap keluaran OpenSSH, jadi panduan yang ditulis dua tahun lalu menamakan algoritma yang tidak lagi diutamakan oleh mesin anda, dan ia tidak mempunyai cara untuk memberitahu anda. Pelajari perintah-perintah ini dan anda tidak lagi memerlukan artikel mengenainya, termasuk artikel ini.

Mulakan dengan apa yang diketahui oleh binaan (build) anda.

ssh -V
ssh -Q kex

ssh -V mencetak baris versi yang bermula dengan OpenSSH_, diikuti oleh akhiran pakej Ubuntu dan versi OpenSSL. ssh -Q kex mencetak satu algoritma pertukaran kunci bagi setiap baris. Pada binaan dengan sokongan pasca-kuantum, anda akan menemui nama seperti mlkem768x25519-sha256 dan sntrup761x25519-sha512@openssh.com dalam senarai itu, bersebelahan dengan nama klasik seperti curve25519-sha256.

Apa yang disokong oleh binaan anda bukanlah apa yang ditawarkannya

Ini adalah perbezaan yang sering diabaikan oleh kebanyakan hantaran. ssh -Q kex menjawab satu soalan: apakah yang boleh dilakukan oleh binari ini. Ia tidak menjawab soalan yang anda pentingkan: apakah yang akan dicadangkan oleh sambungan ini sebenarnya. Kedua-dua senarai ini adalah berbeza, dan jurang antara keduanya adalah tempat di mana nasihat lama mendatangkan kerosakan sebenar.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> mencetak konfigurasi berkesan pelanggan untuk hos tersebut, selepas ~/.ssh/config dan /etc/ssh/ssh_config digunakan. sshd -T melakukan perkara yang sama untuk pelayan. Setiap satunya mencetak satu baris kexalgorithms mengikut susunan keutamaan, dan nama pertama padanya ialah pilihan utama pihak tersebut. Baris itulah yang dihantar melalui rangkaian.

Jurang ini bukan sekadar teori. OpenSSH 8.5, yang dikeluarkan pada 2021-03-03, menambah sntrup761x25519-sha512@openssh.com dan sengaja tidak memasukkannya ke dalam senarai lalai. Pada keluaran tersebut ssh -Q kex menunjukkan algoritma itu dan ssh -G tidak, yang bermaksud binari tersebut boleh melakukan pertukaran kunci pasca-kuantum tetapi tiada sambungan yang memintanya.

Baca algoritma yang dirundingkan oleh sambungan anda

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Antara klien semasa dan pelayan semasa, ia memaparkan:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 ialah hibrid. Ia menjalankan ML-KEM (mekanisme enkapsulasi kunci modul-kekisi, diseragamkan sebagai FIPS 203) pada set parameter 768, bersama-sama dengan Diffie-Hellman lengkung eliptik X25519, dan mencampurkan kedua-dua output ke dalam kunci sesi.

Terhadap pelayan yang lebih lama, anda mungkin melihat ini sebaliknya:

debug1: kex: algorithm: curve25519-sha256

Nama itu tidak mempunyai bahagian pasca-kuantum. curve25519-sha256 ialah Diffie-Hellman lengkung eliptik sahaja, dan komputer kuantum yang besar boleh memecahkannya. Itulah sebab utama mengapa tetapan lalai telah berubah.

Satu peraturan rundingan menjelaskan mengapa satu mesin lama menahan sesi daripada dinaik taraf. Klien menghantar senarainya mengikut susunan keutamaan, pelayan menghantar senarainya sendiri, dan algoritma yang dipilih ialah nama pertama dalam senarai klien yang juga muncul dalam senarai pelayan. Keutamaan klien yang menang, jadi pihak yang lebih lama antara kedua-duanya menentukan sejauh mana anda boleh mencapai senarai tersebut. Menaik taraf komputer riba anda tidak menaik taraf sesi kepada pelayan yang tidak pernah mengenali ML-KEM.

ssh -v berbaloi untuk diketahui lebih daripada sekadar baris ini, kerana output yang sama adalah tempat anda menjejaki kegagalan Permission denied (publickey) apabila log masuk ditolak secara terus.

Gugurkan grep dan ssh -v akan menunjukkan baki rundingan tersebut, termasuk baris yang akan dibincangkan dalam bahagian seterusnya:

debug1: kex: host key algorithm: ssh-ed25519

Keluaran OpenSSH yang menjadikan pertukaran hibrid sebagai lalai

Nota keluaran hulu (upstream) memberikan urutan yang jelas. Tarikh lebih penting daripada nombor versi, kerana ia menunjukkan berapa lama perkara ini telah berjalan secara senyap.

• 8.5, dikeluarkan pada 2021-03-03, menambah sntrup761x25519-sha512@openssh.com dan membiarkannya dinyahdayakan secara lalai.
• 9.0, dikeluarkan pada 2022-04-08, mengaktifkannya. Nota tersebut menyatakan OpenSSH akan "menggunakan kaedah pertukaran kunci hibrid Streamlined NTRU Prime + x25519 secara lalai". Ini adalah keluaran di mana pertukaran kunci pasca-kuantum menjadi kebiasaan.
• 9.9, dikeluarkan pada 2024-09-19, menambah mlkem768x25519-sha256 sebagai pilihan kedua. Keluaran yang sama memberikan kaedah lama itu nama berdaftar IANA, sntrup761x25519-sha512, jadi binaan yang lebih baharu menyenaraikannya di bawah kedua-dua ejaan.
• 10.0, dikeluarkan pada 2025-04-09, menjadikan mlkem768x25519-sha256 sebagai lalai untuk persetujuan kunci.
• 10.1, dikeluarkan pada 2025-10-06, menambah amaran klien apabila sambungan merundingkan pertukaran kunci tanpa bahagian pasca-kuantum. Ia dikawal oleh pilihan WarnWeakCrypto dalam ssh_config dan diaktifkan secara lalai.

April 2022 adalah tarikh yang perlu diingati. Mana-mana pasangan mesin yang menjalankan OpenSSH 9.0 atau lebih baharu telah melakukan pertukaran kunci pasca-kuantum sejak tarikh tersebut, tanpa sebarang konfigurasi dan tanpa sebarang pemberitahuan kepada pengguna yang menaip ssh.

Keluaran Ubuntu yang menyertakan versi ini

Ubuntu menetapkan versi OpenSSH pada masa keluaran, kemudian melakukan backport terhadap tampalan keselamatan tanpa menukar nombor versi. Oleh itu, keluaran Ubuntu yang anda jalankan menentukan algoritma lalai anda. Periksa mesin di hadapan anda dengan ssh -V dan bukannya mempercayai senarai. Setakat Ogos 2026, arkib mengandungi versi berikut:

• 22.04 LTS menyertakan 1:8.9p1, yang mendahului lalai 9.0, jadi pemasangan standard merundingkan curve25519-sha256.
• 24.04 LTS menyertakan 1:9.6p1, yang berada selepas 9.0 dan sebelum 9.9, jadi lalainya ialah sntrup761x25519-sha512@openssh.com dan ia tidak mempunyai ML-KEM.
• 25.10 menyertakan 1:10.0p1, yang mempunyai lalai mlkem768x25519-sha256.
• 26.04 LTS menyertakan 1:10.2p1, yang menggunakan mlkem768x25519-sha256 sebagai lalai dan memberi amaran tentang sambungan yang bukan pasca-kuantum.

Lakukan ujian menggunakan pasangan mesin sebenar. Komputer riba 26.04 bersambung ke pelayan 24.04. Pilihan pertama klien, mlkem768x25519-sha256, tiada dalam senarai pelayan 9.6. Pilihan pasca-kuantum klien seterusnya yang dimiliki oleh pelayan ialah sntrup761x25519-sha512@openssh.com, dan itulah nama yang dilaporkan oleh ssh -v. Sesi tersebut adalah pasca-kuantum pada pertukaran kunci, terhadap pelayan yang dibina pada 2024, tanpa sebarang konfigurasi tambahan oleh sesiapa pun.

Kes 22.04 berlaku sebaliknya, dan ia menunjukkan dengan tepat mengapa ssh -Q kex secara sendirian boleh mengelirukan. OpenSSH 8.9 mengenali nama sntrup761x25519-sha512@openssh.com, jadi ssh -Q kex pada kotak tersebut menyenaraikannya, tetapi cadangan lalai tidak menyertakannya, jadi rundingan berakhir pada curve25519-sha256. Daripada klien OpenSSH 10.1 atau lebih baharu, sambungan tersebut menyatakan perkara berikut:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Amaran itu adalah fakta tentang pelayan yang anda hubungi, bukan tentang klien anda. Penyelesaiannya adalah dengan menaik taraf pelayan tersebut. Menetapkan WarnWeakCrypto no akan membuang mesej tersebut dan tidak mengubah apa-apa tentang sambungan itu.

Mengapa hibrid, dan apakah maksud tuai sekarang nyahsulit kemudian

Ancaman ini mempunyai bentuk yang jelas. Penyerang yang boleh melihat trafik anda akan merekodkan bait yang disulitkan hari ini dan menyimpannya. Mereka tidak boleh membacanya hari ini. Mereka menyimpannya sehingga komputer kuantum yang cukup besar untuk memecahkan X25519 wujud, dan kemudian mereka membacanya. Ini dipanggil tuai sekarang, nyahsulit kemudian, atau simpan sekarang, nyahsulit kemudian. Ia tidak memerlukan kepintaran daripada penyerang pada masa sekarang. Ia hanya memerlukan ruang cakera dan kesabaran.

Penyulitan mempunyai masalah ini manakala tandatangan tidak, dan asimetri tersebut mendorong segala-galanya. Ciphertext yang direkodkan mengekalkan nilainya selagi data di dalamnya kekal sensitif. Tandatangan hanya perlu menjadi tidak boleh dipalsukan pada saat ia diperiksa. Memecahkan algoritma tandatangan pada tahun 2035 membolehkan seseorang menyamar sebagai pelayan pada tahun 2035. Ia tidak membolehkan mereka kembali ke masa lalu dan memalsukan log masuk dari tahun 2026. Oleh itu, pertukaran kunci perlu dibaiki terlebih dahulu, dan bahagian tandatangan boleh menunggu.

Hibrid bermaksud kedua-dua algoritma dijalankan dan kedua-dua hasil menyumbang kepada kunci sesi. Untuk mendapatkan semula rahsia di sebalik mlkem768x25519-sha256, penyerang mesti memecahkan ML-KEM 768 dan X25519. Gandingan ini dilakukan dengan sengaja: ML-KEM jauh lebih baharu daripada X25519 dan mempunyai masa yang jauh lebih singkat di bawah serangan daripada penganalisis kripto, jadi kelemahan yang ditemui dalam algoritma baharu tidak menjejaskan perlindungan yang telah anda miliki.

Apa yang dilindungi dan apa yang tidak

Pertukaran kunci adalah dilindungi. Rahsia kongsi yang menyulitkan sesi anda terhasil daripada pertukaran hibrid, jadi rakaman sesi yang dibuat hari ini tidak akan menjadi boleh dibaca apabila komputer kuantum tiba kelak.

Kunci hos tidak dilindungi. Baris debug1: kex: host key algorithm: ssh-ed25519 menamakan tandatangan klasik, begitu juga dengan rsa-sha2-512 dan jenis ECDSA (elliptic curve digital signature algorithm). Penyerang yang memiliki komputer kuantum yang berfungsi boleh memalsukan tandatangan tersebut dan menyamar sebagai pelayan anda, tetapi hanya semasa sambungan langsung pada masa hadapan itu, dan tidak akan berkesan terhadap trafik yang dirakam sekarang.

Kunci log masuk anda juga tidak dilindungi. Kunci dalam ~/.ssh/id_ed25519 adalah jenis tandatangan klasik yang sama, dan alasan yang sama terpakai untuknya. Apa yang melindungi kunci tersebut pada tahun ini ialah tempat ia disimpan dan siapa yang boleh membacanya, jadi pengurusan kunci SSH yang wajar mengalihkan risiko sebenar anda jauh lebih berkesan daripada sebarang nama algoritma di halaman ini.

Tiada apa yang perlu anda lakukan mengenai kedua-duanya, kerana tiada pilihan lain untuk ditukar. OpenSSH telah menyatakan sokongan tandatangan pasca-kuantum akan hadir dalam keluaran akan datang. Sehingga ia dilancarkan, OpenSSH tidak mempunyai jenis kunci hos pasca-kuantum mahupun jenis kunci pengguna pasca-kuantum, dan ssh-keygen tidak menawarkan apa-apa untuk anda. Panduan yang menyuruh anda menjana kunci tersebut sebenarnya menerangkan perisian yang belum wujud lagi.

TLS pada pelayan yang sama adalah persoalan berasingan dengan jawapan yang berasingan. TLS (transport layer security) adalah apa yang digunakan oleh pelayan web anda pada port 443, dan ia merupakan kod asas yang berbeza dengan jadual yang berbeza. Menaik taraf OpenSSH tidak mengubah apa-apa di situ. Jika anda menjalankan sijil yang ditandatangani sendiri untuk servis peribadi pada VPS yang sama, tandatangan dan pertukaran kuncinya ditentukan oleh OpenSSL dan pelayan web anda, jadi rujuklah timbunan perisian tersebut mengikut ketentuannya sendiri.

Tindakan pengendali yang wajar sekarang

Pastikan OpenSSH sentiasa terkini, dan cukup setakat itu sahaja. Itulah keseluruhan strategi untuk masalah ini. sudo apt update && sudo apt upgrade mengekalkan anda pada versi yang dibekalkan oleh keluaran Ubuntu anda, dan beralih kepada keluaran Ubuntu yang lebih baharu adalah cara untuk mendapatkan OpenSSH yang lebih baharu. Mengaktifkan kemas kini keselamatan automatik memastikan tampalan tersebut digunakan tanpa perlu anda mengingatinya. Membina OpenSSH daripada sumber semata-mata untuk mengejar nama algoritma adalah tindakan yang kurang bijak, kerana anda akan kehilangan kemas kini keselamatan daripada pengedar untuk servis yang paling terdedah pada pelayan tersebut. Jika anda tetap memuat turun sumber, semak muat turun tersebut dengan checksum yang diterbitkan sebelum anda membinanya.

Jangan tulis sendiri baris KexAlgorithms. Ini adalah satu tindakan yang secara pasti memburukkan keadaan. Panduan pengukuhan (hardening) dari tahun 2018 memberikan anda senarai yang tepat pada tahun 2018, dan menampalnya ke dalam sshd_config akan menggantikan senarai lalai dan bukannya menambah kepadanya. Setiap algoritma yang dicipta sejak itu kini dikecualikan, jadi pelayan yang sepatutnya merundingkan mlkem768x25519-sha256 secara automatik akan jatuh kepada apa sahaja yang masih ada dalam senarai yang ditetapkan itu. Jalankan sudo sshd -T | grep -i '^kexalgorithms' pada mana-mana pelayan yang anda warisi. Jika baris tersebut lebih pendek daripada yang terdapat pada pemasangan baharu bagi keluaran yang sama, seseorang telah menetapkannya secara manual.

Jika anda mempunyai alasan yang kukuh untuk menukar senarai tersebut, tambahkan kepadanya dan bukannya menggantikannya. OpenSSH membaca + di hadapan sebagai tambah, - di hadapan sebagai buang, dan ^ di hadapan sebagai pindah ke hadapan.

KexAlgorithms ^mlkem768x25519-sha256

Uji fail tersebut sebelum anda bergantung kepadanya. sudo sshd -t menghuraikan konfigurasi dan tidak mencetak apa-apa apabila ia sah. Baris KexAlgorithms yang menamakan algoritma yang tidak dimiliki oleh binaan tersebut akan menghalang sshd daripada bermula, dan pada pelayan jauh, ini bermakna anda tidak boleh masuk semula, jadi pastikan sesi kedua sentiasa terbuka semasa anda bekerja. Apabila senarai kedua-dua pihak tidak lagi bertindih, klien akan menyatakan perkara itu dengan jelas:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Anggap pemasaran "quantum-safe" sebagai tuntutan mengenai satu lapisan sahaja. Vendor yang memanggil produk sebagai quantum-safe sedang menerangkan lapisan yang mereka namakan, dan lapisan itu biasanya merupakan pertukaran kunci di suatu tempat. Minta nama algoritma dan protokol yang digunakannya. Bagi OpenSSH pada Ogos 2026, versi jujur bagi tuntutan tersebut ialah pertukaran kunci adalah hibrid pasca-kuantum manakala tandatangannya adalah klasik. Apa-apa yang lebih luas daripada itu harus disertakan dengan nama yang boleh anda temui dalam output ssh -Q kex.

Teruskan melakukan bahagian yang membosankan. Pertukaran kunci pasca-kuantum tidak membantu terhadap kata laluan yang mudah diteka, atau kunci peribadi yang disalin ke komputer riba yang kemudiannya dicuri. Perkara itulah yang sebenarnya menjejaskan pelayan, dan pengukuhan SSH standard pada VPS masih membawa hampir keseluruhan beban keselamatan. Jika langkah rundingan di sini tidak biasa bagi anda, apa yang dilakukan oleh SSH apabila anda menyambung merangkumi peringkat yang diandaikan oleh halaman ini sebagai perkara yang anda sudah ketahui.

FAQ

Adakah sambungan SSH saya sudah menggunakan post-quantum?

Jalankan ssh -v yourserver 2>&1 | grep 'kex: algorithm' dan baca nama yang dipaparkan. mlkem768x25519-sha256 dan sntrup761x25519-sha512@openssh.com ialah pertukaran hibrid post-quantum. curve25519-sha256, ecdh-sha2-nistp256 dan sebarang nama diffie-hellman-group adalah klasik. Kedua-dua hujung memerlukan versi yang menawarkan nama post-quantum, kerana rundingan akan memilih pilihan pertama klien yang turut disokong oleh pelayan, jadi mesin yang lebih lama menetapkan had maksimum.

Keluaran OpenSSH manakah yang menjadikan pertukaran kunci post-quantum sebagai lalai?

OpenSSH 9.0, yang dikeluarkan pada 2022-04-08, menjadikan sntrup761x25519-sha512@openssh.com sebagai pertukaran kunci lalai. OpenSSH 9.9, yang dikeluarkan pada 2024-09-19, menambah mlkem768x25519-sha256, dan OpenSSH 10.0, yang dikeluarkan pada 2025-04-09, menjadikan yang tersebut sebagai lalai. OpenSSH 10.1, yang dikeluarkan pada 2025-10-06, mula mengeluarkan amaran apabila sambungan tidak merundingkan mana-mana daripadanya. Semak perkara yang dilakukan oleh binaan anda sendiri dengan ssh -Q kex dan ssh -G <host>, kerana keluaran Ubuntu anda menentukan versi yang anda miliki.

Patutkah saya menjana kunci SSH post-quantum?

Tidak, kerana OpenSSH tidak mempunyai jenis kunci sedemikian. Kerja post-quantum setakat ini meliputi pertukaran kunci, yang tidak memerlukan fail kunci daripada anda dan tiada konfigurasi langsung. Kunci hos dan kunci log masuk masih merupakan tandatangan klasik seperti Ed25519 dan RSA, dan pihak pembangun telah menyatakan bahawa tandatangan post-quantum akan hadir dalam keluaran akan datang. Teruskan menggunakan kunci Ed25519 dan lindungi tempat ia disimpan.

Mengapakah ssh memberi amaran bahawa sambungan saya bukan post-quantum?

OpenSSH 10.1 dan lebih baharu mencetak ** WARNING: connection is not using a post-quantum key exchange algorithm. apabila pertukaran yang dirundingkan tidak mempunyai bahagian post-quantum. Amaran tersebut adalah mengenai pelayan, bukan klien anda, kerana klien anda menawarkan nama post-quantum tetapi pelayan tidak menerima satu pun daripadanya. Naik taraf OpenSSH pelayan tersebut, atau semak sama ada sesiapa telah menetapkan baris KexAlgorithms dalam sshd_config yang mengecualikan nama moden. Menetapkan WarnWeakCrypto no akan menyembunyikan mesej tersebut dan membiarkan sambungan itu kekal lemah seperti sebelumnya.