SSH Pascakuantum di Ubuntu: Apa yang Berubah?

Perubahan pada SSH pascakuantum

SSH pascakuantum sudah diaktifkan secara default untuk sebagian besar pengguna, dan tidak ada konfigurasi yang perlu dilakukan. Klien OpenSSH versi terbaru yang terhubung ke server OpenSSH versi terbaru akan memilih pertukaran kunci pascakuantum hibrida secara default. Dengan demikian, kunci sesi tetap tahan terhadap penyerang yang merekam trafik Anda hari ini lalu mendekripsinya bertahun-tahun kemudian. Perlindungan ini nyata, tetapi cakupannya lebih sempit daripada yang disiratkan oleh istilah "SSH aman terhadap komputasi kuantum".

Ada dua istilah yang perlu dipahami terlebih dahulu. SSH (secure shell) adalah protokol yang digunakan untuk login ke server. Pertukaran kunci, yang biasanya ditulis sebagai "kex", merupakan langkah pertama dalam setiap koneksi SSH. Kedua endpoint menyepakati sebuah rahasia bersama, lalu rahasia tersebut mengenkripsi semua data berikutnya. Bagian yang berubah adalah pertukaran kunci. Tidak ada bagian lain yang berubah.

Jangan percayai halaman ini, jalankan perintahnya

Setiap nama algoritma di bawah ini berasal dari perintah yang dapat Anda jalankan sendiri. Hal itu memang disengaja. Nilai default berubah pada setiap rilis OpenSSH, sehingga panduan yang ditulis dua tahun lalu dapat menyebut algoritma yang tidak lagi diprioritaskan oleh komputer Anda, dan panduan tersebut tidak memiliki cara untuk mengetahuinya. Pelajari perintah-perintah ini agar Anda tidak lagi bergantung pada artikel tentang hal ini, termasuk artikel ini.

Mulailah dengan memeriksa kemampuan yang dikenali oleh build Anda.

ssh -V
ssh -Q kex

ssh -V mencetak baris versi yang diawali dengan OpenSSH_, lalu suffix paket Ubuntu dan versi OpenSSL. ssh -Q kex mencetak satu algoritma pertukaran kunci pada setiap baris. Pada build dengan dukungan pascakuantum, Anda akan menemukan nama seperti mlkem768x25519-sha256 dan sntrup761x25519-sha512@openssh.com dalam daftar tersebut, berdampingan dengan nama klasik seperti curve25519-sha256.

Dukungan build Anda berbeda dari algoritme yang ditawarkannya

Inilah perbedaan yang sering dilewatkan oleh sebagian besar tulisan. ssh -Q kex menjawab satu pertanyaan: apa yang dapat dilakukan oleh binary ini. Perintah tersebut tidak menjawab pertanyaan yang penting bagi Anda: apa yang sebenarnya akan ditawarkan oleh koneksi ini. Kedua daftar tersebut berbeda, dan kesenjangan di antaranya dapat menimbulkan dampak nyata jika mengikuti panduan lama.

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

ssh -G <host> menampilkan konfigurasi efektif klien untuk host tersebut setelah ~/.ssh/config dan /etc/ssh/ssh_config diterapkan. sshd -T melakukan hal yang sama untuk server. Masing-masing menampilkan satu baris kexalgorithms dalam urutan preferensi, dan nama pertama pada baris tersebut adalah pilihan pertama sisi itu. Baris inilah yang dikirim melalui jaringan.

Kesenjangan ini bukan sekadar teori. OpenSSH 8.5, yang dirilis pada 2021-03-03, menambahkan sntrup761x25519-sha512@openssh.com dan sengaja tidak memasukkannya ke dalam daftar default. Pada rilis tersebut, ssh -Q kex menampilkan algoritme itu, sedangkan ssh -G tidak, yang berarti binary tersebut dapat melakukan pertukaran kunci pascakuantum, tetapi tidak ada koneksi yang pernah memintanya.

Baca algoritme yang dinegosiasikan oleh koneksi Anda

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

Antara klien dan server versi terbaru, perintah tersebut menampilkan:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 adalah algoritme hibrida. Algoritme ini menjalankan ML-KEM (mekanisme enkapsulasi kunci berbasis kisi, distandardisasi sebagai FIPS 203) pada set parameter 768, bersama Diffie-Hellman kurva eliptik X25519, lalu mencampurkan kedua output tersebut ke dalam kunci sesi.

Pada server versi lama, Anda mungkin melihat:

debug1: kex: algorithm: curve25519-sha256

Nama tersebut tidak memiliki komponen pascakuantum. curve25519-sha256 hanya menggunakan Diffie-Hellman kurva eliptik, dan komputer kuantum berskala besar dapat memecahkannya. Itulah alasan utama default tersebut diubah.

Satu aturan negosiasi menjelaskan mengapa satu mesin lama dapat membatasi sesi. Klien mengirimkan daftarnya berdasarkan urutan preferensi, server mengirimkan daftarnya sendiri, lalu algoritme yang dipilih adalah nama pertama dalam daftar klien yang juga terdapat dalam daftar server. Preferensi klien yang digunakan, sehingga sisi yang lebih lama menentukan seberapa jauh daftar tersebut dapat digunakan. Meng-upgrade laptop Anda tidak akan meng-upgrade sesi ke server yang belum mengenal ML-KEM.

ssh -v penting diketahui bukan hanya untuk baris ini, karena output yang sama juga digunakan untuk menelusuri kegagalan Permission denied (publickey) saat login ditolak sepenuhnya.

Hapus grep, lalu ssh -v menampilkan sisa negosiasi, termasuk baris yang menjadi topik bagian berikutnya:

debug1: kex: host key algorithm: ssh-ed25519

Rilis OpenSSH mana yang menjadikan pertukaran hibrida sebagai default

Catatan rilis upstream menunjukkan urutannya dengan jelas. Tanggal lebih penting daripada nomor versi karena menunjukkan sudah berapa lama fitur ini berjalan tanpa banyak diketahui.

• 8.5, dirilis pada 2021-03-03, menambahkan sntrup761x25519-sha512@openssh.com dan menonaktifkannya secara default.
• 9.0, dirilis pada 2022-04-08, mengaktifkannya. Catatan tersebut menyatakan bahwa OpenSSH akan "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default". Inilah rilis ketika pertukaran kunci pascakuantum menjadi kondisi normal.
• 9.9, dirilis pada 2024-09-19, menambahkan mlkem768x25519-sha256 sebagai opsi kedua. Rilis yang sama memberikan nama yang terdaftar di IANA untuk metode lama tersebut, yaitu sntrup761x25519-sha512, sehingga build yang lebih baru mencantumkannya dengan kedua ejaan.
• 10.0, dirilis pada 2025-04-09, menjadikan mlkem768x25519-sha256 sebagai default untuk perjanjian kunci.
• 10.1, dirilis pada 2025-10-06, menambahkan peringatan pada client ketika koneksi menegosiasikan pertukaran kunci tanpa komponen pascakuantum. Fitur ini dikendalikan oleh opsi WarnWeakCrypto di ssh_config dan aktif secara default.

April 2022 adalah tanggal yang perlu diingat. Setiap pasangan mesin yang menjalankan OpenSSH 9.0 atau yang lebih baru telah menggunakan pertukaran kunci pascakuantum sejak saat itu, tanpa konfigurasi apa pun dan tanpa pemberitahuan kepada orang yang mengetik ssh.

Versi Ubuntu yang menyertakannya

Ubuntu membekukan versi OpenSSH saat sebuah rilis diterbitkan, lalu mem-backport perbaikan keamanan ke dalamnya tanpa mengubah nomor versinya. Jadi, rilis Ubuntu yang Anda jalankan menentukan algoritme default. Periksa mesin yang sedang Anda gunakan dengan ssh -V, bukan dengan mengandalkan daftar. Per Agustus 2026, arsip memuat versi berikut:

• 22.04 LTS menyertakan 1:8.9p1, yang lebih lama daripada default 9.0, sehingga instalasi standar menegosiasikan curve25519-sha256.
• 24.04 LTS menyertakan 1:9.6p1, yang lebih baru daripada 9.0 dan lebih lama daripada 9.9, sehingga default-nya adalah sntrup761x25519-sha512@openssh.com dan tidak memiliki ML-KEM.
• 25.10 menyertakan 1:10.0p1, yang default-nya adalah mlkem768x25519-sha256.
• 26.04 LTS menyertakan 1:10.2p1, yang menggunakan mlkem768x25519-sha256 sebagai default dan memberikan peringatan tentang koneksi yang bukan post-quantum.

Gunakan pasangan mesin nyata sebagai contoh. Laptop 26.04 terhubung ke server 24.04. Pilihan pertama klien, mlkem768x25519-sha256, tidak terdapat dalam daftar server 9.6. Pilihan post-quantum berikutnya dari klien yang tersedia pada server adalah sntrup761x25519-sha512@openssh.com, dan itulah nama yang dilaporkan oleh ssh -v. Sesi tersebut menggunakan pertukaran kunci post-quantum, meskipun server dibuat pada 2024 dan tidak ada pihak yang mengonfigurasi apa pun.

Kasus 22.04 berjalan sebaliknya dan menunjukkan alasan ssh -Q kex saja dapat menyesatkan. OpenSSH 8.9 mengenali nama sntrup761x25519-sha512@openssh.com, sehingga ssh -Q kex pada mesin tersebut menampilkannya. Namun, proposal default tidak menyertakannya, sehingga negosiasi menggunakan curve25519-sha256. Dari klien OpenSSH 10.1 atau yang lebih baru, koneksi menampilkan hal tersebut:

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

Peringatan tersebut merupakan fakta tentang server yang Anda akses, bukan tentang klien Anda. Solusinya adalah memutakhirkan server. Menetapkan WarnWeakCrypto no menghapus pesan tersebut dan tidak mengubah koneksi.

Mengapa hybrid, dan apa arti harvest now, decrypt later

Ancaman ini bentuknya sederhana. Penyerang yang dapat melihat trafik Anda merekam byte terenkripsi hari ini dan menyimpannya. Mereka belum dapat membacanya hari ini. Mereka menyimpannya sampai tersedia quantum computer yang cukup besar untuk membobol X25519, lalu membacanya. Ini disebut harvest now, decrypt later, atau store now, decrypt later. Penyerang tidak perlu melakukan sesuatu yang canggih saat ini. Mereka hanya membutuhkan ruang disk dan kesabaran.

Enkripsi memiliki masalah ini, sedangkan tanda tangan digital tidak. Perbedaan ini menentukan hal-hal lainnya. Ciphertext yang direkam tetap bernilai selama data di dalamnya masih sensitif. Tanda tangan digital hanya perlu tidak dapat dipalsukan saat diverifikasi. Membobol algoritme tanda tangan pada 2035 memungkinkan seseorang menyamar sebagai server pada 2035. Hal itu tidak memungkinkan mereka kembali ke masa lalu dan memalsukan login dari 2026. Karena itu, pertukaran kunci harus diperbaiki terlebih dahulu, sedangkan sisi tanda tangan dapat menunggu.

Hybrid berarti kedua algoritme dijalankan dan kedua hasilnya digunakan untuk menghasilkan session key. Untuk mendapatkan kembali secret di balik mlkem768x25519-sha256, penyerang harus membobol ML-KEM 768 dan X25519. Pasangan ini dipilih secara sengaja: ML-KEM jauh lebih baru daripada X25519 dan memiliki waktu yang jauh lebih singkat untuk diuji oleh cryptanalyst. Dengan demikian, kerentanan yang ditemukan pada algoritme baru tidak menghilangkan perlindungan yang sudah Anda miliki.

Apa yang dilindungi dan apa yang tidak

Pertukaran kunci dilindungi. Rahasia bersama yang mengenkripsi sesi Anda dihasilkan melalui pertukaran hibrida. Karena itu, rekaman sesi yang dibuat hari ini tidak akan menjadi dapat dibaca ketika komputer kuantum tersedia.

Kunci host tidak dilindungi. Baris debug1: kex: host key algorithm: ssh-ed25519 menyebutkan tanda tangan klasik. Hal yang sama berlaku untuk rsa-sha2-512 dan jenis ECDSA (elliptic curve digital signature algorithm). Penyerang yang memiliki komputer kuantum yang berfungsi dapat memalsukan tanda tangan tersebut dan menyamar sebagai server Anda, tetapi hanya selama koneksi aktif pada masa mendatang. Cara ini tidak dapat digunakan terhadap trafik yang direkam sekarang.

Kunci login Anda juga tidak dilindungi. Kunci dalam ~/.ssh/id_ed25519 merupakan jenis tanda tangan klasik yang sama. Penalaran yang sama berlaku untuk kunci tersebut. Perlindungan kunci itu tahun ini bergantung pada tempat kunci tersebut disimpan dan siapa yang dapat membacanya. Karena itu, manajemen kunci SSH yang tepat jauh lebih berpengaruh terhadap risiko nyata Anda daripada nama algoritma apa pun di halaman ini.

Anda tidak perlu melakukan apa pun terkait kedua hal tersebut karena belum ada opsi penggantinya. OpenSSH menyatakan bahwa dukungan tanda tangan pascakuantum akan hadir dalam rilis mendatang. Sebelum dukungan tersebut dirilis, OpenSSH tidak memiliki jenis kunci host pascakuantum maupun jenis kunci pengguna pascakuantum, dan ssh-keygen tidak menyediakan keduanya. Panduan yang meminta Anda membuat salah satunya sedang menjelaskan software yang belum ada.

TLS pada server yang sama merupakan hal terpisah dengan jawaban yang berbeda. TLS (transport layer security) adalah protokol yang digunakan web server Anda pada port 443. TLS juga menggunakan codebase berbeda dan memiliki jadwal pengembangan berbeda. Meng-upgrade OpenSSH tidak mengubah apa pun pada TLS. Jika Anda menjalankan sertifikat yang ditandatangani sendiri untuk service privat pada VPS yang sama, tanda tangan dan pertukaran kuncinya ditentukan oleh OpenSSL dan web server Anda. Karena itu, evaluasi stack tersebut secara terpisah.

Hal yang dilakukan operator yang bijak sekarang

Pertahankan OpenSSH tetap mutakhir, lalu berhenti di situ. Itulah keseluruhan strategi untuk masalah ini. sudo apt update && sudo apt upgrade mempertahankan Anda pada versi yang dirilis bersama rilis Ubuntu yang digunakan, sedangkan beralih ke rilis Ubuntu yang lebih baru akan memindahkan Anda ke OpenSSH yang lebih baru. Mengaktifkan pemutakhiran keamanan tanpa pengawasan membuat patch tersebut diterapkan tanpa perlu mengingatnya. Membangun OpenSSH dari source demi mengejar nama algoritma merupakan pertukaran yang buruk karena Anda kehilangan pemutakhiran keamanan dari distribusi untuk service yang paling terekspos pada server. Jika tetap mengambil source, periksa unduhan terhadap checksum yang dipublikasikan sebelum membangunnya.

Jangan menulis baris KexAlgorithms secara manual. Inilah satu tindakan yang hampir selalu memperburuk keadaan. Panduan hardening dari 2018 memberi Anda daftar yang benar pada 2018, lalu menempelkannya ke sshd_config akan mengganti daftar default, bukan menambahkannya. Semua algoritma yang dibuat sejak saat itu kini dikecualikan. Akibatnya, server yang sebenarnya akan menegosiasikan mlkem768x25519-sha256 dengan sendirinya secara diam-diam turun ke algoritma apa pun yang masih ada dalam daftar yang dikunci. Jalankan sudo sshd -T | grep -i '^kexalgorithms' pada server yang Anda warisi. Jika baris tersebut lebih pendek daripada baris pada instalasi baru dari rilis yang sama, berarti seseorang menguncinya.

Jika Anda memiliki alasan yang benar-benar diperlukan untuk mengubah daftar tersebut, tambahkan item ke daftar, bukan menggantinya. OpenSSH membaca + di awal sebagai perintah untuk menambahkan, - di awal sebagai perintah untuk menghapus, dan ^ di awal sebagai perintah untuk memindahkan item ke bagian depan.

KexAlgorithms ^mlkem768x25519-sha256

Uji file tersebut sebelum mengandalkannya. sudo sshd -t mengurai konfigurasi dan tidak mencetak apa pun jika konfigurasi valid. Baris KexAlgorithms yang mencantumkan algoritma yang tidak tersedia dalam build akan membuat sshd gagal start. Pada server remote, itu berarti Anda tidak dapat masuk kembali. Karena itu, pertahankan sesi kedua tetap terbuka selama bekerja. Jika daftar dari kedua sisi tidak lagi memiliki algoritma yang sama, client akan menyatakannya 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

Pahami pemasaran "quantum-safe" sebagai klaim tentang satu lapisan. Vendor yang menyebut produknya quantum-safe sedang menjelaskan lapisan tertentu yang mereka sebutkan, dan lapisan itu biasanya merupakan key exchange di suatu tempat dalam protokol. Minta nama algoritma dan protokol yang menerapkannya. Untuk OpenSSH pada August 2026, versi klaim yang jujur adalah bahwa key exchange bersifat hybrid post-quantum, sedangkan tanda tangannya bersifat klasik. Klaim yang lebih luas dari itu harus disertai nama yang dapat Anda temukan dalam output ssh -Q kex.

Tetap lakukan bagian-bagian yang membosankan. Post-quantum key exchange tidak dapat mengatasi password yang mudah ditebak atau private key yang disalin ke laptop lalu laptop tersebut dicuri. Hal-hal itulah yang benar-benar menyebabkan server diambil alih, dan hardening SSH standar pada VPS masih memberikan perlindungan terbesar. Jika tahapan negosiasi di sini belum Anda kenal, apa yang dilakukan SSH saat Anda terhubung menjelaskan tahapan yang diasumsikan sudah Anda pahami di halaman ini.

FAQ

Apakah koneksi SSH saya sudah post-quantum?

Jalankan ssh -v yourserver 2>&1 | grep 'kex: algorithm' dan baca nama yang ditampilkan. mlkem768x25519-sha256 dan sntrup761x25519-sha512@openssh.com adalah pertukaran hybrid post-quantum. curve25519-sha256, ecdh-sha2-nistp256, dan nama apa pun yang diawali diffie-hellman-group adalah pertukaran klasik. Kedua sisi memerlukan versi yang menawarkan nama post-quantum, karena negosiasi memilih pilihan pertama dari klien yang juga didukung server. Dengan demikian, mesin yang lebih lama menentukan batas kemampuan.

Rilis OpenSSH mana yang menjadikan pertukaran kunci post-quantum sebagai default?

OpenSSH 9.0, yang dirilis pada 2022-04-08, menjadikan sntrup761x25519-sha512@openssh.com sebagai pertukaran kunci default. OpenSSH 9.9, yang dirilis pada 2024-09-19, menambahkan mlkem768x25519-sha256, dan OpenSSH 10.0, yang dirilis pada 2025-04-09, menjadikan nama tersebut sebagai default. OpenSSH 10.1, yang dirilis pada 2025-10-06, mulai menampilkan peringatan jika koneksi tidak menegosiasikan salah satunya. Periksa perilaku build Anda dengan ssh -Q kex dan ssh -G <host>, karena rilis Ubuntu Anda menentukan fitur yang tersedia.

Haruskah saya membuat kunci SSH post-quantum?

Tidak, karena OpenSSH tidak memiliki jenis kunci tersebut. Implementasi post-quantum sejauh ini mencakup pertukaran kunci, yang tidak memerlukan file kunci dari Anda maupun konfigurasi apa pun. Kunci host dan kunci login masih menggunakan tanda tangan klasik seperti Ed25519 dan RSA, dan upstream menyatakan bahwa tanda tangan post-quantum akan tersedia pada rilis mendatang. Tetap gunakan kunci Ed25519 dan lindungi lokasi penyimpanannya.

Mengapa ssh memperingatkan bahwa koneksi saya bukan post-quantum?

OpenSSH 10.1 dan versi yang lebih baru menampilkan ** WARNING: connection is not using a post-quantum key exchange algorithm. jika pertukaran yang dinegosiasikan tidak memiliki komponen post-quantum. Peringatan tersebut berkaitan dengan server, bukan klien Anda, karena klien Anda menawarkan nama post-quantum tetapi server tidak menerima satu pun di antaranya. Upgrade OpenSSH pada server, atau periksa apakah ada pihak yang menetapkan baris KexAlgorithms dalam sshd_config milik server sehingga nama-nama modern tidak dapat digunakan. Menetapkan WarnWeakCrypto no hanya menyembunyikan pesan tersebut dan membuat koneksi tetap memiliki tingkat kelemahan yang sama.