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, supaya kunci sesi tersebut kebal terhadap penyerang yang merekod trafik anda hari ini dan cuba menyahsulitnya 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 adalah 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. Nilai lalai berubah mengikut setiap keluaran OpenSSH, jadi panduan yang ditulis dua tahun lalu mungkin 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 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 tersebut, 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 sebenarnya akan dicadangkan oleh sambungan ini. Kedua-dua senarai ini berbeza, dan jurang antara keduanya adalah tempat di mana nasihat lama menyebabkan kerosakan sebenar.

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

ssh -G <host> mencetak konfigurasi berkesan klien 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 meninggalkannya daripada 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 mencetak:

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 X25519 elliptic curve Diffie-Hellman, 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 elliptic curve Diffie-Hellman 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 urutan keutamaan, pelayan menghantar senarainya sendiri, dan algoritma yang dipilih ialah nama pertama dalam senarai klien yang juga muncul dalam senarai pelayan. Keutamaan klien 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 mendengar tentang ML-KEM.

Gugurkan grep dan ssh -v 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 huluan 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 separuh 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 konfigurasi dan tanpa sebarang pengumuman kepada pengguna yang menaip ssh.

Keluaran Ubuntu yang menyertakan versi ini

Ubuntu membekukan versi OpenSSH pada setiap 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 menggunakan 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, iaitu 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 lalai mlkem768x25519-sha256 dan memberi amaran tentang sambungan yang bukan pasca-kuantum.

Uji 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 seterusnya bagi klien 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 tahun 2024, tanpa sebarang konfigurasi tambahan.

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 mesin 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 tersebut adalah fakta tentang pelayan yang anda hubungi, bukan tentang klien anda. Penyelesaiannya adalah dengan menaik taraf pelayan. Menetapkan WarnWeakCrypto no akan membuang mesej tersebut dan tidak mengubah apa-apa pada sambungan.

Mengapa hibrid, dan apakah maksud harvest now decrypt later

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 harvest now, decrypt later, atau store now, decrypt later. 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 memacu 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. Jadi 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 nanti.

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 sekali-kali terhadap trafik yang dirakam sekarang.

Kunci log masuk anda juga tidak dilindungi. Kunci dalam ~/.ssh/id_ed25519 adalah jenis tandatangan klasik yang sama, dan penaakulan yang sama terpakai kepadanya. Apa yang melindungi kunci itu 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 untuk ditukar. OpenSSH telah menyatakan bahawa sokongan tandatangan pasca-kuantum akan hadir dalam keluaran akan datang. Sehingga ia dilancarkan, OpenSSH tidak mempunyai jenis kunci hos pasca-kuantum dan tiada jenis kunci pengguna pasca-kuantum, dan ssh-keygen tidak mempunyai apa-apa untuk ditawarkan kepada 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) ialah protokol 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 secara berasingan.

Tindakan pengendali yang wajar sekarang

Pastikan OpenSSH sentiasa terkini, dan berhenti di situ. Itulah keseluruhan strategi bagi 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 naik taraf keselamatan tanpa seliaan 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 konsisten 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 tersisa 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 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. Oleh itu, 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 meluas daripada itu sepatutnya 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 menyebabkan pelayan diceroboh, 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 pengetahuan anda.

FAQ

Adakah sambungan SSH saya sudah menggunakan post-quantum?

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

Versi OpenSSH manakah yang menjadikan pertukaran kunci post-quantum sebagai tetapan 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 versi tersebut sebagai lalai. OpenSSH 10.1, yang dikeluarkan pada 2025-10-06, mula mengeluarkan amaran apabila sesuatu sambungan tidak merundingkan mana-mana daripadanya. Semak tindakan binaan anda sendiri dengan ssh -Q kex dan ssh -G <host>, kerana keluaran Ubuntu anda menentukan versi yang anda miliki.

Adakah saya perlu menjana kunci SSH post-quantum?

Tidak, kerana OpenSSH tidak mempunyai jenis kunci sedemikian. Usaha post-quantum setakat ini meliputi pertukaran kunci, yang tidak memerlukan fail kunci daripada anda dan tidak memerlukan sebarang konfigurasi. Kunci hos dan kunci log masuk masih menggunakan tandatangan klasik seperti Ed25519 dan RSA, dan pihak pembangun telah menyatakan bahawa tandatangan post-quantum akan disertakan dalam keluaran akan datang. Teruskan menggunakan kunci Ed25519 dan lindungi lokasi penyimpanannya.

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

OpenSSH 10.1 dan versi lebih baharu akan memaparkan ** 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 telah menawarkan nama post-quantum tetapi pelayan tidak menerima mana-mana daripadanya. Naik taraf OpenSSH pada pelayan, atau semak sama ada terdapat baris KexAlgorithms yang ditetapkan dalam sshd_config yang mengecualikan nama-nama moden tersebut. Menetapkan WarnWeakCrypto no akan menyembunyikan mesej tersebut dan membiarkan sambungan berada pada tahap keselamatan yang sama seperti sebelumnya.