OpenSSH 10.3 dan SplitSSHell: Pembaruan Keamanan yang Wajib Diterapkan

OpenSSH 10.3 dirilis pada 2 April 2026 dengan sejumlah perbaikan keamanan, salah satunya untuk celah yang dijuluki SplitSSHell (CVE-2026-35414). Celah ini membuat sertifikat SSH dengan principal berisi koma dibaca sebagai beberapa principal sekaligus, sehingga akses bisa melebar sampai root pada konfigurasi tertentu. Per 29 Oktober 2026 belum ada laporan eksploitasi di alam liar.

Ringkasan OpenSSH 10.3 dan SplitSSHell

• CVE: CVE-2026-35414, dijuluki SplitSSHell oleh perusahaan keamanan data Cyera.
• Produk terdampak: OpenSSH sebelum versi 10.3. SecurityWeek menyebut bug ini sudah ada selama sekitar 15 tahun.
• Jenis kerentanan: salah penanganan opsi principals pada authorized_keys ketika principal sertifikat memuat koma.
• Skor CVSS: 8.1 (High, CVSS 3.1) menurut NVD, angka yang juga dipakai advisori Cyber Security Agency of Singapore. Penerbit CVE (MITRE) memberi skor jauh lebih rendah, 4.2 (Medium), karena menilai syaratnya sulit dipenuhi.
• Status eksploitasi: tidak tercantum di katalog CISA KEV per 29 Oktober 2026, dan penilaian SSVC dari CISA pada catatan NVD (April 2026) mencatat belum ada eksploitasi. Cyera hanya mendemonstrasikannya di server uji.
• Perbaikan: OpenSSH 10.3 atau yang lebih baru. Per 29 Oktober 2026 rilis terbaru adalah OpenSSH 10.6 (6 Oktober 2026).

Jika istilah di atas masih baru, baca dulu penjelasan Apa Itu CVE dan cara membaca skor CVSS.

Apa yang terjadi: komentar kecil yang berdampak besar

Pada rilis 10.3, tim OpenSSH mencatat bahwa algoritma pencocokan pada opsi principals="" di berkas authorized_keys bisa menghasilkan kecocokan yang salah jika principal sertifikat mengandung koma. Menurut SecurityWeek, akar masalahnya adalah kesalahan penggunaan ulang kode: koma di dalam sebuah principal diperlakukan sebagai pemisah daftar. Principal seperti "deploy,root" pun dapat dibaca sebagai dua nilai, dan salah satunya bisa cocok dengan akun yang jauh lebih berhak.

Syaratnya cukup spesifik. Penyerang harus memegang sertifikat valid yang diterbitkan oleh CA yang dipercaya server dan memuat koma pada principal-nya, sementara opsi principals="" di authorized_keys mencantumkan lebih dari satu principal. Catatan rilis menambahkan bahwa CA pada umumnya membatasi ketat nama principal yang diterbitkannya. Catatan rilis OpenSSH menegaskan bahwa masalah ini hanya berlaku untuk kunci CA pengguna yang dipasang langsung di authorized_keys, bukan untuk TrustedUserCAKeys maupun AuthorizedPrincipalsFile. Tanpa infrastruktur sertifikat SSH, Anda tidak terdampak oleh celah ini.

Siapa yang terdampak dan mengapa penting

Banyak VPS dan server Linux memakai autentikasi kunci biasa, bukan sertifikat, dan konfigurasi seperti itu tidak tersentuh SplitSSHell. Yang perlu waspada adalah organisasi yang membangun alur akses berbasis CA SSH, misalnya perusahaan dengan banyak server yang menerbitkan sertifikat berumur pendek untuk tim DevOps, atau penyedia layanan yang memberi akses terbatas kepada vendor.

Bahaya terbesarnya ada pada deteksi. Menurut SecurityWeek, serangan seperti ini tidak menimbulkan kegagalan autentikasi di log, karena yang terekam adalah login sah dengan sertifikat valid. Karena itu deteksi berbasis log tidak bisa diandalkan. Pembaruan dan audit konfigurasi menjadi jalan yang paling pasti. Ini juga contoh bagaimana prinsip least privilege harus berlaku sampai ke kebijakan penerbitan sertifikat.

Perbaikan lain di OpenSSH 10.3

Rilis ini bukan hanya soal satu CVE. Menurut pengumuman resmi di milis openssh-unix-dev, berikut perbaikan keamanan lain yang dicantumkan:

• Validasi nama pengguna dari baris perintah di ssh yang sebelumnya terlambat, sehingga nama buatan penyerang berpotensi lolos ke ekspansi shell pada konfigurasi tertentu, misalnya token %u di blok Match exec.
• scp dalam mode legacy (-O) tidak menghapus bit setuid/setgid saat dijalankan sebagai root tanpa opsi -p.
• Daftar PubkeyAcceptedAlgorithms dan HostbasedAcceptedAlgorithms tidak diterapkan penuh pada kunci ECDSA.
• Konfirmasi ControlMaster ask/autoask tidak diperiksa pada sesi mode proxy (ssh -O proxy).

Sejak itu OpenSSH merilis 10.4 (6 Juli 2026), 10.5 (11 Agustus 2026), dan 10.6 (6 Oktober 2026), masing-masing dengan perbaikan keamanan tambahan. Contohnya celah pada unduhan sftp dan salinan scp yang bisa menulis ke lokasi tak terduga, denial of service GSSAPI sebelum autentikasi, operasi ssh-agent yang semestinya lokal tetapi bisa dijalankan dari jarak jauh, serta kata kunci restrict yang tidak sepenuhnya berlaku untuk tunnel forwarding. Karena itu, bila Anda memperbarui sekarang, sasarannya adalah versi terbaru atau paket distro yang sudah memuat perbaikan tersebut, bukan berhenti di 10.3.

Ada pula perubahan perilaku di 10.3 yang perlu diuji sebelum rollout: sertifikat dengan daftar principal kosong kini tidak pernah cocok (dulu bisa cocok dengan apa saja), opsi -J dan ProxyJump dari baris perintah kini memvalidasi nama pengguna dan host, serta kompatibilitas dengan implementasi yang tidak mendukung rekeying dihapus.

Cara memeriksa paparan dan menerapkan OpenSSH 10.3

1. Cek versi. Jalankan ssh -V pada klien dan server. Distribusi Linux sering membackport perbaikan tanpa menaikkan nomor versi, jadi periksa juga changelog paket atau advisori distro Anda.
2. Tentukan apakah Anda memakai sertifikat SSH. Cari konfigurasi TrustedUserCAKeys dan baris cert-authority di authorized_keys. Kalau tidak ada, risiko SplitSSHell praktis nol, tetapi tetap perbarui.
3. Audit opsi principals. Tinjau setiap baris cert-authority yang memakai principals=. Pastikan CA Anda tidak pernah menerbitkan principal yang memuat koma, dan tolak itu di sisi penerbitan.
4. Pertimbangkan alternatif. Menurut catatan rilis, TrustedUserCAKeys dengan AuthorizedPrincipalsFile tidak terdampak oleh bug ini.
5. Perbarui dan uji. Terapkan versi terbaru (minimal 10.3) atau paket distro yang sudah diperbaiki di lingkungan uji, lalu produksi. Simpan satu sesi SSH yang masih terbuka saat restart sshd agar Anda tidak terkunci di luar.

Hardening SSH untuk VPS Anda sekarang

Pembaruan hanya satu lapis. Beberapa langkah dasar yang tetap relevan: nonaktifkan login kata sandi dan pakai kunci, batasi pengguna yang boleh masuk dengan AllowUsers, larang login root langsung, batasi akses port 22 lewat firewall hanya dari alamat yang Anda kenal atau lewat VPN, dan aktifkan autentikasi dua faktor untuk akun administrator. Kirim log SSH ke tempat terpusat agar perubahan mencurigakan tetap terlihat walau server disusupi. Untuk pemeriksaan konfigurasi oleh pihak ketiga, layanan asesmen Linuxhackingid dapat membantu meninjau pengaturan SSH dan akses server Anda.

Linimasa singkat

• 2 April 2026: OpenSSH 10.3 diumumkan dengan perbaikan keamanan, dan CVE-2026-35414 dipublikasikan di NVD.
• 27 April 2026: SecurityWeek memberitakan celah ini, lalu pada 30 April memperbarui artikelnya dengan nama SplitSSHell. Pada 30 April pula CSA Singapura menerbitkan advisorinya.
• 6 Juli, 11 Agustus, dan 6 Oktober 2026: OpenSSH 10.4, 10.5, dan 10.6 dirilis dengan perbaikan keamanan lanjutan.
• 29 Oktober 2026: CVE-2026-35414 tidak tercantum di katalog CISA KEV.

Baca juga: FortiBleed dan Bypass SSO FortiCloud: Langkah Wajib bagi Pengguna Fortinet.

Pertanyaan yang Sering Diajukan

Apakah semua server SSH saya rentan terhadap SplitSSHell?

Tidak. Celah ini hanya relevan jika Anda memakai kunci CA pengguna dengan opsi principals di authorized_keys dan CA Anda menerbitkan principal yang memuat koma. Pengguna kunci SSH biasa tidak terdampak.

Mengapa log tidak menunjukkan serangannya?

Karena yang terjadi adalah login dengan sertifikat valid yang kemudian dicocokkan ke akun yang tidak seharusnya. Log mencatat autentikasi yang berhasil, bukan kegagalan, sehingga tidak ada sinyal anomali yang jelas.

Apakah cukup memperbarui saja?

Perbarui ke versi terbaru, lalu audit juga kebijakan penerbitan sertifikat Anda. Perbaikan di sisi server tidak menggantikan disiplin di sisi CA.

Kesimpulan

OpenSSH 10.3 menutup SplitSSHell dan beberapa celah lain yang tampak kecil tetapi menyentuh jalur akses paling sensitif di server Anda, dan rilis sesudahnya menambah perbaikan lagi. Periksa versi, audit penggunaan sertifikat SSH, dan terapkan pembaruan terbaru. Jika Anda ingin memperdalam keamanan server Linux secara praktis, lihat kursus Linuxhackingid yang membahas hardening dan administrasi sistem.