Keandalan Teknis & Keamanan

Celah Keamanan OpenSSH di Alpine Linux: Cek Server

Celah keamanan OpenSSH di Alpine Linux (5 November 2026) membuka login SSH tanpa password. Cek apakah server Anda terdampak dan cara menutupnya.

Celah Keamanan OpenSSH di Alpine Linux: Cek Server
Daftar isi
  1. Apa yang terjadi pada celah keamanan OpenSSH ini?
  2. Server seperti apa yang terdampak?
  3. Server yang tidak terdampak
  4. Cara cek dan menutup celah keamanan OpenSSH (untuk tim IT/vendor Anda)
  5. Pelajaran jangka panjang untuk pemilik bisnis
  6. Pertanyaan yang sering diajukan
  7. Referensi
  8. Lanjutkan membaca

Celah keamanan OpenSSH yang diumumkan pada 5 November 2026 membuat sebagian server Alpine Linux bisa dimasuki tanpa mengetahui password. OpenSSH adalah program yang dipakai tim IT untuk masuk ke server dari jarak jauh. Bila server Anda memakai Alpine, minta tim IT memperbarui paket openssh lalu menyalakan ulang layanannya.

Kabar baiknya, tidak semua server terdampak. Celah ini hanya terbuka pada kombinasi setelan tertentu. Alpine Linux sendiri adalah sistem operasi server yang ringan dan banyak dipakai di VPS, image cloud, dan container.

Di bawah ini ada penjelasan singkat, cara mengenali server yang berisiko, dan langkah perbaikan yang bisa Anda teruskan ke tim IT atau vendor.

Apa yang terjadi pada celah keamanan OpenSSH ini?

Singkatnya, server bisa menerima password yang sangat panjang sebagai password yang benar. Padahal akun yang dituju sebenarnya tidak punya password sama sekali.

Menurut catatan rilis resmi OpenSSH, versi 10.6p2 dirilis pada 5 November 2026. Isinya disebut "critical security workaround", yaitu perbaikan keamanan kritis. Perbaikan itu ditujukan untuk sistem Linux yang memakai musl dan mematikan PAM. Musl adalah pustaka dasar, semacam kumpulan fungsi bawaan, yang dipakai Alpine. PAM adalah modul yang biasanya mengatur proses login.

Pengumuman resmi Alpine (5 November 2026) menjelaskan akar masalahnya. Bila password yang dikirim lebih dari 256 byte (kira-kira 256 huruf), fungsi pengecek password di musl mengembalikan tanda bintang (*) sebagai tanda gagal. Masalahnya, tanda bintang yang sama juga tersimpan pada akun yang memang tidak diberi password. Sistem lalu menganggap keduanya cocok, dan login diterima.

Alpine menulis, "An attacker who can reach your SSH port can log in without knowing any password." Artinya, siapa pun yang bisa menjangkau pintu SSH server Anda bisa masuk tanpa tahu password. Caranya cukup dengan password acak sepanjang 257 sampai 1.024 byte. Menurut Alpine, cara itu berhasil setiap kali dalam satu koneksi, tanpa perlu mencoba ulang.

Celah ini tercatat dengan kode CVE-2026-123158. CVE adalah nomor katalog internasional untuk celah keamanan. Catatan CVE yang terbit 5 November 2026 memberi skor 8,1 dari 10, kategori High (tinggi). Lembaga keamanan siber Amerika Serikat, CISA, mencatat bahwa contoh serangan atau proof of concept (PoC) sudah tersedia untuk umum. Sampai artikel ini ditulis pada 7 November 2026, belum ada sumber resmi yang menyebut celah ini sudah dipakai dalam serangan nyata.

Server seperti apa yang terdampak?

Server Anda berisiko bila keempat kondisi berikut terpenuhi sekaligus. Satu saja tidak terpenuhi, celah ini tidak bisa dipakai.

  • Server memakai Alpine Linux dengan paket SSH bawaan (openssh-server, yang dibuat tanpa PAM), atau paket openssh-server-pam dengan setelan UsePAM no.
  • Login dengan password masih diizinkan (PasswordAuthentication yes). Setelan ini memang bawaan OpenSSH bila tidak pernah diubah.
  • Ada akun yang kolom password-nya berisi tanda bintang (*), artinya akun itu tidak diberi password. Contohnya akun yang hanya dipakai dengan kunci SSH, akun root di image dasar Alpine, dan user alpine di image cloud resmi.
  • Ada minimal satu akun lain yang punya password sungguhan. Password ini tersimpan dalam bentuk hash, yaitu password yang sudah diacak, dengan awalan $5$ atau $6$.

Risiko terbesar ada pada image cloud resmi Alpine (tiny-cloud) versi 3.18.11 sampai 3.24.3. Image ini membawa user alpine tanpa password yang boleh memakai doas tanpa password. Doas adalah perintah untuk menjalankan sesuatu sebagai admin. Penyerang yang masuk sebagai alpine bisa langsung naik menjadi root, akun dengan kuasa penuh atas server.

Menurut Alpine, image tersebut aman saat pertama dinyalakan. Celahnya terbuka begitu ada satu akun dengan password sungguhan. Bayangkan sebuah toko online yang menjalankan aplikasi kasir di VPS Alpine. Developer pernah memasang password untuk login lewat konsol darurat. Perubahan kecil seperti itu sudah cukup untuk membuka pintu.

Server yang tidak terdampak

Sebagian besar server bisnis kemungkinan tidak terdampak, selama bukan Alpine dengan login password aktif. Berikut kondisi yang menurut Alpine dan catatan CVE berada di luar jangkauan celah ini.

  • Server Ubuntu, Debian, atau RHEL pada umumnya. Deskripsi resmi CVE hanya menyebut sistem Linux yang memakai musl tanpa PAM. Ketiga sistem itu biasanya memakai pustaka lain (glibc) dan PAM, jadi tidak masuk kategori tersebut.
  • Server Alpine yang memakai openssh-server-pam dengan setelan UsePAM yes.
  • Server yang sudah mematikan login password (PasswordAuthentication no).
  • Akun yang dikunci, yaitu yang kolom password-nya berisi tanda seru (!). Akun seperti ini tidak bisa login dengan password maupun kunci.
  • Container Docker yang tidak menjalankan sshd. Sshd adalah program server SSH yang menunggu koneksi masuk, dan kebanyakan container aplikasi tidak menjalankannya.
  • Image cloud yang diatur lewat cloud-init, karena cloud-init otomatis menulis setelan PasswordAuthentication no.

Jadi, pertanyaan pertama untuk tim IT cukup satu: apakah kita punya server Alpine yang membuka SSH dan masih mengizinkan login password?

Cara cek dan menutup celah keamanan OpenSSH (untuk tim IT/vendor Anda)

Bagian ini bisa Anda teruskan langsung ke tim IT atau vendor. Langkahnya diambil dari pengumuman resmi Alpine tanggal 5 November 2026.

  1. Pastikan sistem operasinya dengan cat /etc/os-release. Bila hasilnya bukan Alpine, celah ini tidak berlaku untuk server tersebut.
  2. Cek apakah sshd berjalan dengan rc-service sshd status. Untuk container, cek apakah sshd ikut dijalankan di dalamnya.
  3. Perbarui paket, lalu nyalakan ulang sshd. Alpine menegaskan bahwa update paket saja tidak mengganti sshd yang sedang berjalan.
apk upgrade -U -a
rc-service sshd restart

Setelah itu, cocokkan versi paket openssh dengan versi aman menurut pelacak keamanan Alpine:

  • Alpine 3.24: 10.3_p1-r2 atau lebih baru.
  • Alpine 3.23: 10.2_p1-r1 atau lebih baru.
  • Alpine 3.22: 10.0_p1-r11 atau lebih baru.
  • Alpine 3.21: 9.9_p2-r1 atau lebih baru.
  • Alpine 3.20: 9.7_p1-r6 atau lebih baru.
  • Alpine 3.19: 9.6_p1-r3 atau lebih baru.
  • Alpine edge: 10.6_p2-r0 atau lebih baru.

Rilis Alpine 3.21.10, 3.22.8, 3.23.8, dan 3.24.4 sudah membawa paket yang diperbaiki. Alpine juga mencatat bahwa dukungan 3.21 berakhir pada 1 November 2026, meski paket perbaikannya tetap diterbitkan. Server yang masih di versi lama sebaiknya dijadwalkan naik versi.

Bila belum bisa update, matikan login password dulu. Pastikan login dengan kunci SSH sudah berjalan, dan jangan tutup sesi yang aktif sebelum login baru berhasil dites.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Perintah terakhir seharusnya menampilkan passwordauthentication no. Folder sshd_config.d baru dibaca mulai Alpine 3.19. Untuk versi yang lebih lama, ikuti perintah lengkap di pengumuman Alpine.

Terakhir, cek tanda pembobolan. Cari baris Accepted password for di /var/log/messages untuk akun yang tidak punya password, misalnya alpine, root, atau akun khusus kunci SSH. Periksa juga pemakaian doas, user baru, dan kunci SSH yang baru ditambahkan. Pesan Alpine jelas: bila login asing tidak bisa dipastikan tidak terjadi, anggap server sudah dibobol.

Pelajaran jangka panjang untuk pemilik bisnis

Pelajaran utamanya, setelan bawaan yang terlihat aman bisa berubah jadi pintu masuk karena satu perubahan kecil. Empat kebiasaan berikut membuat celah serupa jauh lebih sulit dimanfaatkan.

  • Login ke server hanya dengan kunci SSH. Kunci SSH adalah file kunci digital di laptop admin, mirip kunci fisik, sehingga tidak bisa ditebak seperti password.
  • Batasi siapa yang bisa menjangkau port SSH, misalnya lewat firewall atau VPN kantor. Celah ini hanya bisa dipakai oleh orang yang bisa mencapai port tersebut.
  • Buat daftar server dan image container. Cukup spreadsheet berisi nama server, sistem operasi dan versinya, pengelolanya, dan tanggal update terakhir.
  • Bila memakai vendor, tulis di kontrak siapa yang memantau pengumuman keamanan dan berapa cepat update dipasang.

Pola yang sama juga terlihat pada celah keamanan kernel Linux yang memengaruhi banyak server dan celah pada sistem update APT di Ubuntu dan Debian. Server yang tercatat rapi dan punya penanggung jawab jelas selalu lebih cepat ditambal. Untuk aplikasi Anda sendiri, audit trail yang mencatat siapa mengubah data membantu melacak akses yang mencurigakan.

Pertanyaan yang sering diajukan

Apakah server Ubuntu saya ikut terkena celah keamanan OpenSSH ini?

Deskripsi resmi CVE-2026-123158 hanya menyebut sistem Linux yang memakai musl tanpa PAM, dengan Alpine sebagai contoh. Ubuntu umumnya memakai glibc dan PAM, jadi tidak masuk kategori itu. Tetap pasang update OpenSSH secara rutin.

Saya memakai Docker dengan image Alpine. Perlu khawatir?

Menurut Alpine, container yang tidak menjalankan sshd tidak terdampak. Kebanyakan container aplikasi web memang tidak menjalankan sshd. Minta tim IT memastikan tidak ada container yang membuka SSH dengan login password.

Paket sudah diperbarui. Apakah server langsung aman?

Belum, sampai sshd dinyalakan ulang dengan rc-service sshd restart. Update paket tidak mengganti sshd yang sedang berjalan. Setelah restart, cocokkan versi openssh dengan daftar versi aman dari Alpine.

Bagaimana tahu server pernah dibobol lewat celah ini?

Cari baris "Accepted password for" di /var/log/messages untuk akun yang tidak punya password, seperti alpine atau root. Periksa juga user baru dan kunci SSH yang baru ditambahkan. Bila ragu, Alpine menyarankan menganggap server sudah dibobol.

Bila Anda tidak yakin server mana yang memakai Alpine, atau belum ada orang yang rutin memantau pengumuman keamanan, Anaverse, software house dan IT consultant di Pekanbaru, Riau, bisa membantu memeriksa dan merapikan pengelolaan server lewat layanan konsultan IT dan pengelolaan sistem. Ceritakan kondisi server Anda lewat halaman kontak.

Referensi

Lanjutkan membaca

Baca selanjutnya

Celah Keamanan SonicWall Lewati MFA: Cek Firewall Anda
Keandalan Teknis & Keamanan

Celah Keamanan SonicWall Lewati MFA: Cek Firewall Anda

Celah keamanan SonicWall CVE-2026-19868 bisa melewati MFA di VPN kantor bila login memakai SAML. Cek versi SonicOS, langkah update, dan audit login VPN.

Celah Keamanan APT Ubuntu dan Debian: Cek Server Anda
Keandalan Teknis & Keamanan

Celah Keamanan APT Ubuntu dan Debian: Cek Server Anda

Celah keamanan APT Ubuntu dan Debian (4 November 2026) bisa membuat server memasang paket palsu sebagai root. Cek versi aman dan langkah perbaikannya.

Celah Keamanan WordPress: Amankan Update ke 7.1.4
Keandalan Teknis & Keamanan

Celah Keamanan WordPress: Amankan Update ke 7.1.4

Celah keamanan WordPress CVE-2026-119977 sudah dieksploitasi lewat proses update. Cek versi, blokir folder upgrade, lalu update ke 7.1.4 dengan aman.

Butuh partner digital?

Mari wujudkan ide Anda.

Konsultasikan kebutuhan website, sistem, atau aplikasi Anda bersama tim kami.