Kabar buruk bagi pengelola server: celah autentikasi di OpenSSH yang dijuluki SSHole sudah dieksploitasi kurang dari sembilan jam setelah nomor CVE-nya terbit. Firma intelijen ancaman Previdian mencatat percobaan pertama pada 6 November 2026 dan mengonfirmasi akses root di honeypot Alpine Linux. Ini bukan lagi ancaman teoretis: pemindai otomatis biasanya menyalip jadwal patch kita.

Yang membuat celah ini istimewa, penyerang tidak perlu mencuri password, tidak perlu kunci SSH, dan tidak perlu akun. Cukup satu koneksi dengan password yang sangat panjang, dan pada konfigurasi tertentu ia langsung masuk ke akun yang seharusnya tidak bisa dipakai login sama sekali.

Apa itu SSHole dan mengapa bisa terjadi

Celah ini tercatat sebagai CVE-2026-123158 dengan skor CVSS 8.1. Ditemukan peneliti keamanan Özgün Kültekin dari Wakefield, dan sudah diperbaiki di OpenSSH 10.6p2 yang dirilis 5 November 2026. Akar masalahnya bukan di sshd, melainkan di interaksi sshd dengan pustaka C musl yang dipakai Alpine Linux dan sejumlah distro ringan lain.

Ketika OpenSSH dibangun tanpa PAM, sshd memeriksa password sendiri: password yang dicoba di-hash, lalu hasilnya dibandingkan dengan isi kolom password pada file shadow sistem. Pada musl, fungsi hashing mengembalikan tanda bintang (*) sebagai penanda error bila password yang diberikan melebihi 256 byte. Masalahnya, * juga persis nilai yang tersimpan untuk akun yang sengaja dikunci tanpa password, misalnya root di image Alpine sejak versi 3.16 atau akun khusus kunci SSH.

Jadi ketika penyerang mengirim password sepanjang 257 sampai 1.024 byte, proses hashing gagal, musl mengembalikan *, dan sshd menganggapnya cocok dengan akun tanpa password. Login pun berhasil. Syarat tambahannya: di mesin itu harus ada minimal satu akun lain dengan hash password SHA-256 atau SHA-512 (ditandai awalan $5$ atau $6$), karena sshd meminjam salt dari akun tersebut. Satu akun berpassword saja sudah cukup untuk membuka semua akun tanpa password di mesin itu.

Siapa yang benar-benar terdampak

Kabar baiknya, cakupannya cukup spesifik. Sebuah sistem rentan hanya jika semua kondisi berikut terpenuhi:

• Menjalankan OpenSSH di atas musl libc, umumnya Alpine Linux, juga sebagian build OpenWrt, Buildroot, dan Yocto.
• OpenSSH dibangun tanpa PAM, atau memakai UsePAM no.
• PasswordAuthentication masih yes (nilai bawaan OpenSSH).
• Ada akun dengan kolom password berisi *, dan minimal satu akun lain dengan hash $5$ atau $6$.

Sebaliknya, distribusi berbasis glibc seperti Ubuntu, Debian, RHEL, AlmaLinux, dan Rocky Linux tidak terdampak selama autentikasi password ditangani PAM. Dropbear juga tidak terpengaruh. Namun jangan buru-buru lega: container Docker berbasis Alpine yang menjalankan sshd, image cloud tiny-cloud, serta perangkat IoT dan server kecil dengan OpenSSH tanpa PAM tetap masuk daftar periksa.

Cek cepat: apakah server Anda kena

Di mesin Alpine, jalankan sebagai root:

1. Cek versi dan status autentikasi password: ssh -V lalu sshd -T | grep -i passwordauthentication.
2. Lihat paket terpasang: apk list -I openssh. Versi di bawah perbaikan berarti belum aman.
3. Periksa daftar akun tanpa password dengan awk pada file shadow: awk -F: '$2=="*" {print $1}' /etc/shadow.
4. Pastikan ada akun dengan hash $5$ atau $6$: awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow. Jika hasilnya kosong, celah ini tidak bisa dieksploitasi di mesin tersebut, tetapi pembaruan tetap dianjurkan.

Cara memperbaiki

Jalur utama adalah memperbarui paket, bukan sekadar menunggu. Alpine telah menerbitkan paket perbaikan pada rilis 3.21.10, 3.22.8, 3.23.8, dan 3.24.4.

1. Perbarui sistem dengan apk upgrade -U -a.
2. Restart sshd, langkah yang paling sering terlupa: rc-service sshd restart. Memperbarui paket tidak otomatis mengganti daemon yang sedang berjalan, sehingga server tetap rentan sampai sshd dijalankan ulang.
3. Verifikasi ulang dengan sshd -T | grep -i passwordauthentication.

Bila pembaruan belum bisa dilakukan, misalnya karena jadwal pemeliharaan aplikasi, matikan autentikasi password sebagai mitigasi. Caranya, tambahkan satu berkas drop-in berisi PasswordAuthentication no di folder konfigurasi sshd, uji dengan sshd -t, lalu restart layanan.

Sebelum mematikan login password, pastikan seluruh tim sudah memakai kunci SSH agar tidak ada yang terkunci di luar server. Untuk server Ubuntu dan Debian yang memakai PAM, prioritasnya lebih rendah, tetapi pembaruan OpenSSH tetap layak dijadwalkan.

Jika sudah terlanjur dieksploitasi

Indikasinya bisa dilihat di log. Pada Alpine, periksa /var/log/messages dan cari baris Accepted password for pada akun yang seharusnya tidak menerima login password, seperti root, alpine, atau akun khusus kunci. Previdian mencatat delapan percobaan dari satu IP di Jepang, dan percobaan semacam ini biasanya diikuti upaya lain.

Bila ada keraguan, anggap mesin sudah disusupi: ganti seluruh kunci SSH dan kredensial, periksa pengguna baru, file authorized_keys yang tidak dikenal, aktivitas doas maupun sudo, serta proses dan koneksi keluar yang mencurigakan. Pada lingkungan instansi, langkah ini sebaiknya disertai pencatatan insiden dan pemberitahuan ke pengelola aplikasi di atasnya.

Pelajaran untuk pengelola TI

Kasus SSHole menunjukkan dua hal. Pertama, aset yang sering diabaikan justru container dan image dasar: server utama mungkin Ubuntu yang aman, tetapi container Alpine di dalamnya menjalankan sshd tanpa PAM. Kedua, kecepatan eksploitasi kini dihitung dalam jam, bukan hari. Tim OpenSSH sendiri menyatakan akan lebih sering merilis perbaikan karena banyak temuan bug kini datang lewat bantuan model AI dan bisa ditemukan ulang pihak lain dalam hitungan jam.

Langkah paling murah tetap sama: inventarisasi semua host yang membuka port SSH, gunakan hanya kunci untuk login, batasi akses port 22 lewat firewall, dan jadwalkan pembaruan rutin. Untuk klien EASYSTEM, pengecekan konfigurasi sshd dan pembaruan paket sudah menjadi bagian dari pemeliharaan berkala.

Sumber: The Hacker News; Alpine Linux Security Advisory; OpenSSH 10.6p2 Release Notes; Ars Technica.