Post-Quantum SSH di Ubuntu: Apa yang Berubah?

Perubahan pada post-quantum SSH

Post-quantum SSH sudah diaktifkan secara default untuk sebagian besar pengguna, dan tidak ada konfigurasi manual yang diperlukan. Klien OpenSSH versi terbaru yang terhubung ke server OpenSSH versi terbaru akan memilih key exchange post-quantum hibrida secara default. Dengan demikian, session key tetap tahan terhadap penyerang yang merekam trafik Anda saat ini lalu mendekripsinya beberapa tahun mendatang. Perlindungan ini nyata, tetapi cakupannya lebih terbatas daripada yang disiratkan oleh istilah "quantum-safe SSH".

Ada dua istilah yang perlu dipahami terlebih dahulu. SSH (secure shell) adalah protokol yang digunakan untuk login ke server. Key exchange, yang biasanya ditulis sebagai "kex", adalah langkah pertama dalam setiap koneksi SSH. Kedua sisi menyepakati shared secret, lalu secret tersebut mengenkripsi semua data berikutnya. Bagian yang berubah adalah key exchange. Bagian lainnya tidak berubah.

Jangan percayai halaman ini, jalankan perintahnya

Setiap nama algoritme di bawah ini berasal dari perintah yang dapat Anda jalankan sendiri. Hal itu memang disengaja. Default berubah pada setiap rilis OpenSSH. Karena itu, panduan yang ditulis dua tahun lalu dapat menyebut algoritme yang tidak lagi diprioritaskan oleh mesin Anda, dan panduan tersebut tidak memiliki cara untuk mengetahuinya. Pelajari perintah-perintah ini agar Anda tidak lagi memerlukan artikel tentang topik ini, termasuk artikel ini.

Mulailah dengan melihat kemampuan build yang Anda gunakan.

ssh -V
ssh -Q kex

ssh -V menampilkan baris versi yang diawali dengan OpenSSH_, diikuti suffix paket Ubuntu dan versi OpenSSL. ssh -Q kex menampilkan satu algoritme pertukaran kunci pada setiap baris. Pada build yang mendukung 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 bukan berarti fitur itu ditawarkan

Inilah perbedaan yang sering diabaikan oleh sebagian besar artikel. ssh -Q kex menjawab satu pertanyaan: apa yang dapat dilakukan oleh binary ini. Perintah tersebut tidak menjawab pertanyaan yang penting bagi Anda: apa yang akan ditawarkan oleh koneksi ini. Kedua daftar tersebut berbeda, dan kesenjangan di antara keduanya menjadi sumber masalah serius ketika saran lama diterapkan.

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

ssh -G <host> mencetak 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 mencetak satu baris kexalgorithms dalam urutan preferensi, dan nama pertama pada baris tersebut adalah pilihan pertama sisi itu. Baris itulah 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 algoritma yang dinegosiasikan oleh koneksi Anda

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

Antara client dan server versi terbaru, perintah tersebut menampilkan:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 adalah algoritma hibrida. Algoritma ini menjalankan ML-KEM (mekanisme enkapsulasi kunci berbasis kisi, yang distandardisasi sebagai FIPS 203) dengan set parameter 768, bersama Elliptic Curve Diffie-Hellman X25519, lalu menggabungkan kedua output tersebut ke dalam kunci sesi.

Saat terhubung ke server yang lebih lama, Anda mungkin melihat hasil berikut:

debug1: kex: algorithm: curve25519-sha256

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

Satu aturan negosiasi menjelaskan mengapa satu mesin lama dapat menahan sesi. Client mengirimkan daftarnya berdasarkan urutan preferensi, server mengirimkan daftarnya sendiri, lalu algoritma yang dipilih adalah nama pertama dalam daftar client yang juga terdapat dalam daftar server. Preferensi client yang digunakan, sehingga sisi yang lebih lama menentukan seberapa jauh daftar tersebut dapat digunakan. Memutakhirkan laptop Anda tidak memutakhirkan sesi ke server yang belum mengenal ML-KEM.

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

debug1: kex: host key algorithm: ssh-ed25519

Rilis OpenSSH mana yang menjadikan pertukaran hybrid sebagai default

Catatan rilis upstream menunjukkan urutan yang jelas. Tanggalnya lebih penting daripada nomor versinya karena menunjukkan sudah berapa lama fitur ini berjalan tanpa disadari.

• 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 rilis menyatakan bahwa OpenSSH akan "menggunakan metode pertukaran kunci hybrid Streamlined NTRU Prime + x25519 secara 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 penamaan.
• 10.0, dirilis pada 2025-04-09, menjadikan mlkem768x25519-sha256 sebagai default untuk negosiasi kunci.
• 10.1, dirilis pada 2025-10-06, menambahkan peringatan pada client ketika koneksi menegosiasikan pertukaran kunci yang tidak memiliki komponen pascakuantum. Fitur ini dikendalikan oleh opsi WarnWeakCrypto dalam 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 dan tanpa pemberitahuan kepada orang yang mengetik ssh.

Versi Ubuntu yang menyertakannya

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

• Ubuntu 22.04 LTS menyertakan 1:8.9p1, yang lebih lama daripada default 9.0, sehingga instalasi standar menegosiasikan curve25519-sha256.
• Ubuntu 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.
• Ubuntu 25.10 menyertakan 1:10.0p1, yang default-nya adalah mlkem768x25519-sha256.
• Ubuntu 26.04 LTS menyertakan 1:10.2p1, yang default-nya adalah mlkem768x25519-sha256 dan memperingatkan koneksi yang tidak 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 ssh -v. Pertukaran kunci pada sesi tersebut bersifat post-quantum, meskipun server dibuat pada 2024, tanpa konfigurasi tambahan dari siapa pun.

Kasus 22.04 berjalan sebaliknya. Kasus ini 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 menampilkannya:

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

Peringatan tersebut adalah fakta tentang server yang Anda akses, bukan tentang klien Anda. Solusinya adalah memperbarui 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 tidak dapat membacanya hari ini. Mereka menyimpannya sampai tersedia komputer kuantum yang cukup besar untuk memecahkan X25519, lalu membacanya. Ini disebut harvest now, decrypt later atau store now, decrypt later. Saat ini, penyerang tidak memerlukan metode yang canggih. Mereka hanya memerlukan ruang disk dan kesabaran.

Masalah ini berlaku pada enkripsi, tetapi tidak pada tanda tangan, dan asimetri tersebut menentukan hal-hal lainnya. Ciphertext yang direkam tetap bernilai selama data di dalamnya masih sensitif. Tanda tangan hanya perlu tidak dapat dipalsukan saat diperiksa. Memecahkan algoritme tanda tangan pada 2035 memungkinkan seseorang menyamar sebagai server pada 2035. Hal itu tidak memungkinkan mereka kembali memalsukan login dari 2026. Karena itu, pertukaran kunci harus diperbaiki terlebih dahulu, sedangkan sisi tanda tangan dapat ditunda.

Hybrid berarti kedua algoritme dijalankan dan kedua hasilnya digunakan untuk menghasilkan kunci sesi. Untuk memulihkan rahasia di balik mlkem768x25519-sha256, penyerang harus memecahkan ML-KEM 768 dan X25519. Pemilihan pasangan ini disengaja: ML-KEM jauh lebih baru daripada X25519 dan memiliki waktu yang jauh lebih singkat untuk diuji oleh para kriptanalisis. 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 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. Tanda tangan tersebut tidak dapat digunakan untuk menyerang trafik yang direkam sekarang.

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

Anda tidak perlu melakukan apa pun terkait kedua hal tersebut karena belum ada pilihan penggantinya. OpenSSH menyatakan bahwa dukungan tanda tangan pascakuantum akan tersedia dalam rilis mendatang. Sebelum fitur tersebut dirilis, OpenSSH tidak memiliki jenis kunci host pascakuantum maupun jenis kunci pengguna pascakuantum, dan ssh-keygen juga tidak menyediakan pilihan tersebut. Panduan yang menyuruh Anda membuatnya sedang menjelaskan perangkat lunak yang belum ada.

TLS pada server yang sama merupakan pertanyaan terpisah dengan jawaban yang berbeda. TLS (transport layer security) adalah protokol yang digunakan web server Anda pada port 443. TLS menggunakan basis kode dan jadwal pengembangan yang berbeda. Memutakhirkan OpenSSH tidak mengubah apa pun pada TLS. Jika Anda menjalankan sertifikat yang ditandatangani sendiri untuk layanan privat pada VPS yang sama, tanda tangan dan pertukaran kuncinya ditentukan oleh OpenSSL dan web server Anda. Karena itu, bahas stack tersebut secara terpisah.

Hal yang dilakukan operator yang bijak sekarang

Selalu perbarui OpenSSH, lalu berhenti sampai di situ. Itulah seluruh strategi untuk masalah ini. sudo apt update && sudo apt upgrade mempertahankan Anda pada versi yang disediakan oleh rilis Ubuntu Anda, sedangkan beralih ke rilis Ubuntu yang lebih baru akan memindahkan Anda ke OpenSSH yang lebih baru. Mengaktifkan pemutakhiran keamanan otomatis akan menerapkan patch tersebut tanpa mengharuskan Anda mengingatnya. Membangun OpenSSH dari source untuk mengejar nama algoritme merupakan pertukaran yang buruk, karena Anda kehilangan pemutakhiran keamanan dari distribusi untuk service yang paling terekspos pada server. Jika Anda tetap mengunduh source, periksa unduhan terhadap checksum yang dipublikasikan sebelum membangunnya.

Jangan menulis baris KexAlgorithms secara manual. Tindakan inilah yang hampir selalu memperburuk keadaan. Panduan hardening dari 2018 memberikan daftar yang benar pada 2018, tetapi menempelkannya ke sshd_config akan menggantikan daftar default, bukan menambahkannya. Semua algoritme yang dibuat setelah itu kini dikecualikan, sehingga server yang seharusnya menegosiasikan mlkem768x25519-sha256 secara otomatis justru diam-diam turun ke algoritme yang masih ada dalam daftar yang dikunci. Jalankan sudo sshd -T | grep -i '^kexalgorithms' pada setiap server yang Anda warisi. Jika baris tersebut lebih pendek daripada baris pada instalasi baru dari rilis yang sama, seseorang telah menguncinya.

Jika Anda memiliki alasan yang jelas untuk mengubah daftar tersebut, tambahkan algoritme alih-alih menggantinya. OpenSSH membaca + di awal sebagai operasi penambahan, - di awal sebagai operasi penghapusan, dan ^ di awal sebagai pemindahan ke bagian depan.

KexAlgorithms ^mlkem768x25519-sha256

Uji file tersebut sebelum mengandalkannya. sudo sshd -t mengurai konfigurasi dan tidak menampilkan apa pun jika konfigurasi valid. Baris KexAlgorithms yang mencantumkan algoritme yang tidak tersedia dalam build akan mencegah sshd berjalan. Pada server jarak jauh, ini berarti Anda tidak dapat masuk kembali, jadi pertahankan sesi kedua tetap terbuka selama bekerja. Jika daftar pada kedua sisi tidak lagi memiliki algoritme 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 suatu produk quantum-safe sedang menjelaskan lapisan yang mereka sebutkan, dan lapisan itu biasanya merupakan key exchange di suatu bagian sistem. Mintalah nama algoritme dan protokol yang menerapkannya. Untuk OpenSSH pada August 2026, versi klaim yang jujur adalah bahwa key exchange bersifat hybrid post-quantum, sedangkan signature masih bersifat klasik. Klaim yang lebih luas dari itu harus disertai nama yang dapat Anda temukan dalam output ssh -Q kex.

Tetap lakukan langkah-langkah dasar yang sering diabaikan. Key exchange post-quantum tidak mengatasi password yang mudah ditebak atau private key yang disalin ke laptop yang kemudian dicuri. Hal-hal itulah yang sebenarnya menyebabkan server dibobol, 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-kuantum?

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-kuantum. curve25519-sha256, ecdh-sha2-nistp256, dan nama diffie-hellman-group apa pun adalah pertukaran klasik. Kedua sisi memerlukan versi yang menawarkan nama post-kuantum, karena negosiasi memilih pilihan pertama dari klien yang juga didukung server. Jadi, mesin yang lebih lama menentukan batasnya.

Rilis OpenSSH mana yang menjadikan pertukaran kunci post-kuantum 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 ketika 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-kuantum?

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

Mengapa ssh memperingatkan bahwa koneksi saya tidak post-kuantum?

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