Celah OpenSSH di Alpine Linux: Password yang Cukup Panjang Bisa Membuka Akun Tanpa Password

Pada 5 November 2026, tim Alpine Linux dan proyek OpenSSH merilis perbaikan untuk celah bypass autentikasi password pada sshd di Alpine. Di server yang terdampak, penyerang bisa masuk ke akun yang sama sekali tidak punya password, misalnya user yang biasanya login dengan SSH key, cukup dengan mengirim password yang panjangnya lebih dari 256 byte. Peneliti yang melaporkannya, Özgün Kültekin dari Wakefield, menjulukinya sshole, dan celah ini dilaporkan dengan nomor CVE-2026-123158. Perbaikannya ada di OpenSSH 10.6p2 dan di paket openssh terbaru untuk semua rilis Alpine dari 3.16 sampai 3.24. Pada laporan awal belum ada serangan yang terkonfirmasi, tetapi caranya sangat mudah dan sudah dipublikasikan, jadi pemindaian massal tinggal menunggu waktu.

Bagaimana Password Panjang Bisa Lolos

Bug ini muncul di antara dua komponen yang masing-masing sebenarnya bekerja dengan wajar. Secara default Alpine menyertakan sshd tanpa PAM, sehingga sshd memeriksa password sendiri: password yang diketik diproses dengan fungsi crypt() dari library C memakai salt dari /etc/shadow, lalu hasilnya dibandingkan dengan hash yang tersimpan.

Akun yang memang tidak boleh login dengan password diberi tanda bintang di kolom password /etc/shadow, bukan hash. Di Alpine, ini berlaku untuk root di base image sejak 3.16, untuk user yang hanya login memakai key, dan untuk sebagian akun dari directory service. Supaya waktu respons tidak membocorkan akun mana yang ada, sshd tidak langsung berhenti untuk akun seperti ini. sshd meminjam salt asli dari akun lain dan tetap menjalankan crypt(), sebuah perilaku yang berasal dari perubahan pada 2016.

Library C di Alpine adalah musl, dan musl menolak meng-hash input yang lebih panjang dari 256 byte. Saat itu terjadi, crypt() milik musl mengembalikan tanda bintang sebagai tanda error. sshd lalu membandingkan tanda bintang itu dengan tanda bintang yang tersimpan untuk akun tanpa password, keduanya sama, dan login diterima. Tidak ada kriptografi yang lemah atau kerusakan memori di sini, hanya satu karakter yang punya dua arti berbeda. Damien Miller, developer OpenSSH, menyatakan bahwa proyek OpenSSH menganggap akar masalahnya ada di luar OpenSSH. Perbaikan di sshd menolak nilai tersimpan yang terlalu pendek untuk menjadi hash yang valid, sehingga hasil error tidak bisa lagi dianggap cocok.

Apakah Server Anda Terdampak

Sebuah sistem baru bisa dieksploitasi jika semua kondisi berikut terpenuhi. Banyak mesin Alpine memenuhi semuanya dengan pengaturan bawaan.

• Menjalankan sshd dari paket openssh-server yang dibangun tanpa PAM, atau dari openssh-server-pam dengan UsePAM bernilai no.
• PasswordAuthentication aktif, yang memang merupakan pengaturan bawaan.
• Ada setidaknya satu akun bertanda bintang di kolom password yang bisa login lewat SSH. Root sudah bertanda bintang sejak Alpine 3.16, tetapi pengaturan bawaan PermitRootLogin prohibit-password memblokir login password untuk root. Target yang lebih realistis adalah user yang hanya memakai key, user dari directory service, dan user alpine di image cloud tiny-cloud.
• Ada setidaknya satu akun lokal lain yang punya hash password sungguhan, diawali $5$ atau $6$, yang salt-nya dipinjam oleh sshd.

Kasus tiny-cloud adalah yang paling serius. Image cloud Alpine yang dibangun dengan tiny-cloud dari versi 3.18.11 sampai 3.24.3 menyertakan user alpine dengan password bertanda bintang dan doas tanpa password. Begitu ada satu akun di mesin itu yang diberi password sungguhan, penyerang bisa login sebagai alpine lalu menjadi root dengan satu perintah tambahan.

Sistem yang tidak terdampak: container Alpine yang tidak menjalankan sshd, yang mencakup sebagian besar image seperti node:alpine atau nginx:alpine; sistem dengan PasswordAuthentication bernilai no; build PAM dengan UsePAM yes; akun yang dikunci dengan tanda seru, bukan tanda bintang; serta distro berbasis glibc seperti Ubuntu, Debian, dan Red Hat Enterprise Linux. Maintainer Alpine juga menyatakan Dropbear tidak terdampak. Sistem lain berbasis musl yang menjalankan OpenSSH tanpa PAM, misalnya sebagian build Buildroot atau Yocto untuk perangkat embedded, punya kelemahan yang sama dan perlu perbaikan dari OpenSSH 10.6p2.

Cara Mengecek dengan Beberapa Perintah

Jalankan perintah berikut sebagai root di setiap mesin Alpine yang menjalankan sshd. Semuanya hanya membaca kondisi saat ini dan tidak mengubah apa pun.

• Versi Alpine dan paket yang terpasang: cat /etc/alpine-release dan apk list -I "openssh*". Bandingkan versi openssh dengan tabel di bagian berikutnya.
• Pengaturan sshd yang berlaku: sshd -T | grep -Ei "^(usepam|passwordauthentication|permitrootlogin) ". Perintah ini menampilkan nilai yang benar-benar dipakai sshd setelah semua file konfigurasi digabung, sehingga lebih bisa diandalkan daripada membaca sshd_config secara manual.
• Akun tanpa password: awk -F: '$2=="*" {print $1}' /etc/shadow menampilkan akun yang bisa dibuka lewat celah ini.
• Akun dengan hash sungguhan: grep -cE ':\$[56]\$' /etc/shadow menghitung jumlahnya. Jika hasilnya nol, tidak ada salt yang bisa dipinjam sehingga celah ini tidak bisa dipicu. Namun perlindungan ini rapuh, karena langsung hilang begitu ada yang mengatur password.

Versi yang Sudah Diperbaiki

Alpine juga membuat perbaikan untuk rilis yang sudah tidak didukung, mundur sampai 3.16, sesuatu yang jarang dilakukan. Anggap itu tanda seberapa serius celah ini, bukan alasan untuk bertahan di rilis lama. Rilis point terbaru, yaitu 3.21.10, 3.22.8, 3.23.8, dan 3.24.4, sudah berisi paket yang diperbaiki, sehingga image dan instalasi yang dibangun dari rilis tersebut aman.

Cara Update

1. 1Perbarui paket dengan apk upgrade -U -a, lalu pastikan versi openssh dengan apk list -I "openssh*".
2. 2Restart sshd dengan rc-service sshd restart. Langkah ini wajib: daemon yang sedang berjalan tetap memakai kode lama sampai di-restart, jadi upgrade saja membuat server tetap bisa dieksploitasi. Sesi SSH yang sedang terbuka tidak terputus saat restart.
3. 3Untuk container yang menjalankan sshd, misalnya container SFTP atau jump host, build ulang image dari base yang sudah diperbarui, pastikan proses build memasang paket openssh yang sudah diperbaiki, lalu buat ulang container-nya. Patch yang dilakukan di dalam container yang sedang berjalan akan hilang saat container dibuat ulang.
4. 4Untuk instance cloud yang dibuat dari image tiny-cloud lama, update dengan cara yang sama, dan perbarui juga image atau template buatan sendiri supaya instance baru tidak lahir dengan paket lama.
5. 5Cek ulang setiap mesin dengan sshd -T dan apk list -I, jangan berasumsi update sudah sampai ke semuanya.

Jika Belum Bisa Update Hari Ini

Mematikan autentikasi password menghilangkan masalah ini sepenuhnya, dan untuk server yang bisa diakses dari internet, pengaturan ini memang seharusnya dipakai. Pastikan dulu Anda bisa login dengan SSH key, dan biarkan satu sesi tetap terbuka selama melakukan perubahan supaya kesalahan konfigurasi tidak membuat Anda terkunci di luar.

1. 1Di Alpine 3.19 ke atas, buat file di /etc/ssh/sshd_config.d/ dengan nama yang urutannya paling awal, misalnya 00-no-password.conf, berisi baris PasswordAuthentication no. sshd memakai nilai pertama yang dibacanya, jadi nama file yang diawali angka kecil memastikan pengaturan ini yang berlaku. Di 3.16 sampai 3.18, ubah langsung baris tersebut di /etc/ssh/sshd_config.
2. 2Validasi konfigurasi dengan sshd -t. Jika tidak ada output, sintaksnya sudah benar.
3. 3Restart dengan rc-service sshd restart, lalu pastikan dengan sshd -T | grep -i passwordauthentication bahwa hasilnya no.
4. 4Dari terminal baru, login dengan key untuk memastikan akses masih berjalan sebelum menutup sesi lama.

Jika ada user yang benar-benar masih butuh login dengan password, batasi siapa saja yang bisa menjangkau port 22, misalnya lewat firewall yang hanya mengizinkan alamat IP kantor atau VPN, sampai update selesai dilakukan.

Mengecek Apakah Sudah Ada yang Masuk

Eksploitasi celah ini tidak meninggalkan jejak log yang khas. Login lewat bug ini terlihat seperti login password biasa yang berhasil. Karena itu, yang perlu dicek adalah apakah ada login password yang berhasil untuk akun yang sebenarnya tidak punya password. Cari Accepted password for di /var/log/messages, lalu bandingkan nama user-nya dengan daftar akun bertanda bintang dari pengecekan di atas. Periksa juga penggunaan doas, user yang baru dibuat, perubahan pada file authorized_keys, dan file di direktori sistem yang baru saja berubah. Container sering tidak menyimpan log setelah dibuat ulang, sehingga pengecekannya lebih sulit. Jika Anda tidak bisa memastikan bahwa belum ada yang masuk, anggap mesin tersebut sudah disusupi dan bangun ulang, jangan mencoba membersihkannya.

Pelajaran dari Bug Ini

Sebagian besar mesin Alpine yang bisa dieksploitasi punya dua kesamaan: autentikasi password dibiarkan sesuai bawaan, dan port SSH terbuka ke seluruh internet. Cukup salah satunya diatur berbeda, mesin itu akan aman. Untuk server yang menghadap internet, gunakan hanya key atau SSH certificate untuk login, taruh SSH di belakang VPN atau bastion host jika memungkinkan, dan simpan daftar mesin mana saja yang menjalankan sshd, termasuk VM Alpine kecil dan container yang mudah terlupakan. Jadikan juga restart service sebagai bagian dari setiap update keamanan, karena di Alpine tidak ada yang mengingatkan bahwa sebuah daemon masih menjalankan kode lama. Jika Anda butuh bantuan memeriksa atau memperkuat keamanan server, tim managed service kami siap membantu.