Pada 5 November 2026, tim OpenSSH merilis versi 10.6p2 secara mendadak. Alasannya bukan pembaruan fitur, melainkan celah keamanan yang dijuluki sshole. Di kondisi tertentu, penyerang bisa masuk ke server Linux tanpa mengetahui password sama sekali. Paling rentan adalah server berbasis Alpine Linux, distro ringan yang populer sebagai basis image Docker, container aplikasi, dan perangkat jaringan.

Bagi pengelola TI di instansi pemerintah, desa, sekolah, maupun UMKM, kasus ini penting. Bukan karena serangannya rumit, tetapi karena salah satu syaratnya justru praktik yang sering dianggap aman: login hanya dengan SSH key, tanpa password.

Apa yang sebenarnya terjadi

Menurut laporan The Hacker News dan pengumuman keamanan Alpine, penyerang dapat login ke akun yang tidak memiliki password pada server Alpine yang menjalankan paket standar openssh-server. Contohnya akun yang dibuat khusus untuk akses SSH key saja. Penyerang hanya perlu tiga hal: akses jaringan ke server, nama akun, dan password sepanjang 257 hingga 1.024 byte.

Kedengarannya aneh: kok password panjang malah bisa lolos? Akarnya ada pada kombinasi OpenSSH dengan musl, pustaka C yang dipakai Alpine, sementara sebagian besar distro lain memakai glibc. Paket openssh-server Alpine juga dibangun tanpa PAM.

Tanpa PAM, sshd memeriksa password sendiri. Password yang dicoba di-hash dengan fungsi crypt(), lalu dibandingkan dengan isi kolom password di berkas shadow. Akun tanpa password hanya berisi tanda bintang, terlalu pendek untuk menampung salt, sehingga sshd meminjam salt milik akun lain yang punya hash asli. Untuk hash bertipe $5$ dan $6$, crypt() di musl menolak password lebih dari 256 byte dan mengembalikan tanda bintang sebagai penanda gagal. Karena kolom akun tadi juga berisi tanda bintang, hasilnya dianggap cocok dan login diterima.

Siapa yang benar-benar terdampak

Alpine merinci empat kondisi yang harus terpenuhi sekaligus. Server baru berisiko bila:

• Menjalankan paket openssh-server (dibangun tanpa PAM), atau openssh-server-pam dengan UsePAM no;
• PasswordAuthentication bernilai yes, dan ini nilai bawaan OpenSSH;
• Ada akun dengan kolom password berisi *, artinya tidak punya password;
• Ada minimal satu akun lain di mesin yang hash password-nya diawali $5$ atau $6$.

Satu akun berpassword sudah cukup untuk membuka semua akun tanpa password di server itu. Menurut pengumuman Alpine, serangan berhasil pada setiap percobaan dengan satu koneksi saja. Akun tanpa password di Alpine antara lain pengguna yang dibuat dengan adduser tanpa password, pengguna dari layanan direktori lewat musl-nscd, dan root yang sejak sekitar Alpine 3.16 dikirim sebagai root:* di image dasar.

Root masih terlindungi setelan bawaan PermitRootLogin prohibit-password, tetapi perlindungan itu runtuh bila akun rentan bisa naik ke root lewat doas. Image cloud tiny-cloud versi 3.18.11 sampai 3.24.3 memberi user alpine akses doas tanpa password. Image tersebut aman saat boot pertama, tetapi terbuka begitu ada satu hash $6$ di mesin, misalnya setelah admin memasang password konsol.

Sistem Debian/Ubuntu, Windows, dan distro berbasis glibc tidak terkena karena pemeriksaan password lewat PAM. Yang perlu diperiksa adalah sistem berbasis musl: Alpine, OpenWrt, Buildroot, dan Yocto. Khusus OpenWrt, SSH bawaannya memakai Dropbear yang tidak terdampak; celah ini baru relevan bila admin memasang OpenSSH Server di atasnya.

Cara menambal server Alpine

OpenSSH menyebut perbaikannya sebagai workaround: sshd kini menolak kecocokan bila kolom password tersimpan kurang dari empat karakter. Alpine sudah menerbitkan paket yang dipatch untuk semua rilis hingga 3.16. Perbaikan cukup dua langkah, tetapi keduanya wajib:

1. Perbarui paket: apk upgrade -U -a
2. Restart layanan, karena upgrade paket tidak otomatis me-restart sshd yang sedang berjalan: rc-service sshd restart

Jika belum bisa menambal segera, matikan login password. Buat berkas drop-in di direktori sshd_config.d (dibaca sejak Alpine 3.19) berisi PasswordAuthentication no. Ubah juga setiap baris PasswordAuthentication di berkas konfigurasi utama sshd dari yes menjadi no, termasuk yang berada di dalam blok Match. Damien Miller dari proyek OpenSSH menyarankan langkah tegas: matikan login password atau nonaktifkan SSH pada sistem tersebut segera. Setelah itu verifikasi dengan sshd -T | grep -i passwordauthentication; hasilnya harus passwordauthentication no.

Cek apakah server Anda sudah disusupi

Belum ada laporan serangan yang memakai celah ini. Pemeriksaan tetap layak dilakukan, terutama pada server yang sejak lama memakai login key-only:

• Cari baris Accepted password for di log pesan sistem untuk akun yang seharusnya tidak punya password, misalnya alpine, root, atau user khusus key.
• Audit penggunaan doas, akun yang baru dibuat, serta perubahan pada daftar kunci SSH dan berkas konfigurasi.
• Sebagai pencegahan, kunci akun tanpa password dengan menambahkan tanda seru di kolom password. Akun bertanda seru tidak terkena celah ini.

Yang perlu dilakukan pengelola TI hari ini

Prioritas pertama adalah inventaris: cari container atau server yang berbasis Alpine. Image alpine di Docker, container aplikasi internal, sampai router OpenWrt yang dipasangi OpenSSH semuanya masuk daftar periksa. Perbarui image dasar, jalankan ulang container, lalu pastikan login password benar-benar dimatikan dan akses admin memakai SSH key. Untuk server Debian/Ubuntu yang secara teknis tidak terdampak pun, mematikan login password tetap praktik yang layak dipertahankan, sebab percobaan brute force password SSH adalah salah satu lalu lintas paling ramai di log server publik.

Yang membuat celah ini menarik sekaligus mengganggu adalah sifatnya. Bukan bug pada kode autentikasi OpenSSH yang rumit, melainkan interaksi antar-komponen yang selama bertahun-tahun dianggap wajar: pustaka C, cara menangani kegagalan hash, dan peminjaman salt untuk mencegah kebocoran nama pengguna. Ini pengingat bahwa login khusus SSH key tanpa pengamanan tambahan bukan berarti bebas risiko.

Sumber: The Hacker News: OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux; Alpine Linux Security Advisory, 5 November 2026; Ars Technica; laporan teknis sshhole.com oleh Özgün Kültekin.