Ing. Calogero Bono
Pada 5 November 2026 dirilis OpenSSH 10.6p2, yang memperbaiki bug berjuluk «*sshole». Bug ini menyangkut server SSH di Linux yang memakai pustaka musl, seperti Alpine Linux, dengan PAM dinonaktifkan. Siapa pun yang bisa mencapai port SSH dapat masuk ke akun tanpa password hanya dengan mengirim password yang sangat panjang. Ini penting karena cukup satu koneksi saja, dan gambar cloud resmi Alpine bisa memberi akses sebagai root.
Beberapa istilah sebelum masuk ke faktanya. musl adalah pustaka C alternatif untuk glibc, yang dipakai oleh Alpine, OpenWrt, Buildroot, dan Yocto. crypt() adalah fungsi yang mengubah password menjadi hash-nya. PAM adalah sistem autentikasi modular di Linux. /etc/shadow adalah berkas yang menyimpan hash password. doas adalah alat, mirip sudo, untuk mendapatkan hak akses root.
Bagaimana cara kerja bug *sshole?
Akun Linux tanpa password memiliki tanda bintang di tempat hash di /etc/shadow. Tidak ada password yang seharusnya bisa membukanya. Menurut BleepingComputer, perubahan pada OpenSSH tahun 2016, yang dibuat untuk memperbaiki CVE-2016-6210 tentang enumerasi pengguna, membuat hash tetap dihitung untuk akun-akun ini.
Di sinilah musl berperan. Seperti dijelaskan pengumuman Alpine, crypt() di musl mengembalikan * sebagai sinyal error jika kunci melebihi 256 byte. Tanda bintang itu sama dengan yang tersimpan di akun, sehingga perbandingannya berhasil. Peneliti Özgün Kültekin menyatakan bahwa celah ini sudah ada sejak 2016.
Siapa yang benar-benar berisiko?
Beberapa kondisi harus terpenuhi bersamaan. Menurut Alpine, paket openssh-server dikompilasi tanpa PAM, atau memakai openssh-server-pam dengan UsePAM no. PasswordAuthentication harus aktif, sesuai pengaturan default. Diperlukan akun dengan * dan setidaknya satu akun lain dengan hash $5$ atau $6$. Cukup satu pengguna yang memiliki password agar semua akun lain bisa dijangkau.
Alpine telah memverifikasi versi 3.21 hingga 3.24 dan edge, serta versi lama 3.16 hingga 3.20. Container tanpa sshd, sistem dengan PasswordAuthentication no, dan sistem dengan PAM aktif tidak terdampak. Debian, Ubuntu, dan Fedora, yang memakai glibc, tidak rentan, tulis BleepingComputer.
Mengapa gambar cloud Alpine menjadi perhatian?
Gambar resmi tiny-cloud, dari 3.18.11 hingga 3.24.3, memiliki pengguna alpine dengan password * dan doas tanpa password. Alpine menegaskan bahwa gambar tersebut aman saat pertama kali dijalankan. Gambar menjadi bisa dieksploitasi ketika muncul hash $6$, misalnya jika administrator mengatur password konsol atau jika user-data menambahkan pengguna dengan hashed_passwd.
Dalam kondisi itu penyerang mendapatkan shell sebagai alpine dan dengan doas menjadi root. Gambar yang dikonfigurasi dengan cloud-init, yang menulis PasswordAuthentication no, tidak terdampak. Untuk root, nilai default PermitRootLogin prohibit-password hanya melindunginya secara langsung.
Bagaimana memperbaikinya dan memeriksa serangan?
Perbaikannya ada di OpenSSH 10.6p2. Di Alpine, jalankan apk upgrade -U -a, lalu restart sshd, karena pembaruan tidak menggantikan daemon yang sedang berjalan. Alpine telah merilis paket yang sudah diperbaiki hingga 3.16, termasuk untuk rilis yang tidak lagi didukung.
Jika kamu belum bisa memperbarui, atur PasswordAuthentication no dan restart sshd, setelah memastikan login dengan kunci berfungsi. Untuk mencari jejak, periksa di /var/log/messages baris «Accepted password» untuk akun tanpa password. Alpine menambahkan bahwa jika akses tidak bisa dikesampingkan, mesin harus dianggap sudah disusupi. Untuk izin akun, panduan tentang izin file Linux juga relevan.
Batasan yang perlu kamu tahu
Alpine menyebutkan bahwa saat artikel ini ditulis belum ada CVE yang ditetapkan. OpenSSH menulis bahwa penyebabnya berada di luar sshd, tetapi bisa dieksploitasi melalui sshd dan di sana hal itu bisa dihindari. Belum ada data tentang serangan nyata yang sedang berlangsung. Klaim tentang 17.600 uji coba dengan agen AI berasal dari peneliti yang dikutip BleepingComputer, dan belum diverifikasi secara independen.
Apa dampaknya bagi yang bekerja di dunia digital
Jika kamu mengelola server Alpine, router OpenWrt, atau sistem embedded dengan Yocto dan Buildroot, periksa apakah sshd mengizinkan password dan apakah ada akun dengan *. Banyak yang memakai Alpine di container tanpa sshd dan tidak terdampak. Jika kamu menjalankan mesin cloud dengan gambar tiny-cloud, periksa setiap instans yang sudah berjalan. Server terkelola dengan pembaruan rutin mengurangi risiko semacam ini, kami membahasnya di halaman tentang hosting dan server terkelola. Ada baiknya juga mengikuti kasus terkait eksploit yang dihasilkan AI, yang pernah kami tulis di artikel ini.
Pendapat kami
Kasus ini menunjukkan betapa rapuhnya batas antara komponen yang saling mempercayai. OpenSSH menambahkan pertahanan yang sah pada 2016, musl memilih nilai error yang umum, dan keduanya bersama-sama membuka celah selama sepuluh tahun. Yang juga mengkhawatirkan adalah bug ini ditemukan dengan agen AI. OpenSSH sendiri memperingatkan bahwa bug yang ditemukan dengan AI sering ditemukan ulang oleh pihak lain, sehingga menunggu adalah risiko. Solusi paling kokoh tetap sama seperti dulu, yaitu kunci sebagai pengganti password.
Pertanyaan yang sering diajukan
Apakah Debian dan Ubuntu rentan terhadap *sshole?
Tidak. Keduanya memakai glibc, bukan pustaka musl. BleepingComputer memastikan sistem dengan autentikasi PAM tidak rentan, sedangkan Alpine menjelaskan bahwa openssh-server-pam dengan UsePAM no tidak rentan, tetapi dengan UsePAM yes tidak.
Apakah cukup memperbarui paket openssh?
Tidak, sshd juga harus di-restart. Alpine menjelaskan bahwa pembaruan tidak menggantikan daemon yang sudah berjalan, sehingga versi yang rentan tetap aktif.
Bisakah saya melindungi diri tanpa memperbarui?
Bisa, sebagai solusi sementara. Atur PasswordAuthentication no di konfigurasi sshd lalu restart layanannya. Pastikan dulu login dengan kunci berfungsi.
Apakah root juga terbuka?
Hanya dalam kondisi tertentu. Dengan PermitRootLogin prohibit-password, yang merupakan nilai default, root tidak bisa dijangkau langsung. Root menjadi terbuka jika PermitRootLogin yes aktif atau jika pengguna lain bisa menjadi root, misalnya lewat doas.
Apakah ada CVE untuk bug ini?
Belum, menurut Alpine. Pengumumannya menyebutkan bahwa saat ditulis belum ada pengenal yang ditetapkan. Rujukannya adalah catatan rilis OpenSSH 10.6p2.
Yang perlu dipantau setelah OpenSSH 10.6p2
OpenSSH mengumumkan rilis yang lebih sering agar perbaikan sampai ke pengguna lebih cepat. Bug ini masih menyisakan beberapa hal yang perlu diikuti.
- Pantau apakah CVE akan ditetapkan dan apakah alat pemindai kamu akan mengenalinya.
- Periksa kapan produsen firmware berbasis OpenWrt, Buildroot, dan Yocto akan merilis pembaruan.
- Siapkan rutinitas untuk memasang rilis kecil OpenSSH tanpa menunggu versi yang dijadwalkan.
