--- title: "regreSSHion CVE-2024-6387, Cek dan Tambal OpenSSH" description: "Cara mengecek apakah OpenSSH di servermu rentan regreSSHion (CVE-2024-6387), versi paket tambalan per distro, dan mitigasi sementaranya." url: "https://nivelva.com/insight/regresshion-cve-2024-6387-cek-tambal-openssh" category: "Keamanan/Cyber Security" tags: ["regresshion","openssh","cve-2024-6387","ssh","linux"] author: "Theresia Candiawan" published: "2026-11-07T08:35:00+07:00" updated: "2026-11-07T08:35:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # regreSSHion CVE-2024-6387, Cek dan Tambal OpenSSH > **Jawaban singkat:** regreSSHion (CVE-2024-6387) adalah celah race condition di sshd OpenSSH 8.5p1 sampai sebelum 9.8p1 pada Linux berbasis glibc yang bisa berujung eksekusi kode sebagai root. Perbarui paket openssh-server dari distro, restart sshd, dan pakai LoginGraceTime 0 hanya sebagai mitigasi darurat. Apakah OpenSSH di servermu sudah aman dari regreSSHion? Kalau servermu rutin diperbarui sejak Juli 2024, jawabannya hampir pasti ya. Tapi untuk VPS yang jarang disentuh, image lama, atau server yang paket-paketnya "dikunci", ada baiknya dicek sekarang, karena celah ini menyasar layanan yang hampir selalu terbuka ke internet: SSH. regreSSHion adalah nama yang diberikan Qualys untuk CVE-2024-6387, diumumkan 1 Juli 2024. Celahnya berupa race condition pada penanganan sinyal di `sshd` yang, pada Linux berbasis glibc, bisa dimanfaatkan untuk menjalankan kode sebagai root tanpa login. Skor CVSS-nya 8.1. Disebut "regresi" karena ini sebenarnya celah lama (CVE-2006-5051) yang muncul kembali akibat perubahan kode di OpenSSH 8.5p1. ## Versi mana yang rentan? Menurut advisori Qualys: - OpenSSH **sebelum 4.4p1** rentan, kecuali sudah ditambal untuk CVE-2006-5051 dan CVE-2008-4109. - OpenSSH **4.4p1 sampai sebelum 8.5p1** tidak rentan. - OpenSSH **8.5p1 sampai sebelum 9.8p1** rentan lagi. Celah dieksploitasi pada sistem Linux dengan glibc. OpenBSD tidak rentan. Qualys mendemonstrasikan eksploitasi pada sistem 32-bit di laboratorium, dengan rata-rata waktu beberapa jam sampai berhari-hari karena harus memenangkan race condition berulang kali. Pada 64-bit, eksploitasi belum didemonstrasikan saat advisori terbit, tetapi Qualys menilai kemungkinannya ada. Jadi jangan anggap server 64-bit otomatis aman. Satu hal penting: distro besar menambal versinya sendiri tanpa mengganti nomor versi upstream. OpenSSH 8.9p1 di Ubuntu 22.04 bisa saja sudah aman, asal revisi paketnya sudah yang terbaru. Karena itu yang dicek adalah **versi paket distro**, bukan hanya angka OpenSSH. ## Langkah mengecek dan menambal ### Langkah 1: Lihat versi OpenSSH dan paketnya ``` ssh -V ``` Lalu cek paket distro: ``` # Ubuntu dan Debian dpkg -l openssh-server | tail -1 # AlmaLinux, Rocky, RHEL rpm -q openssh-server ``` ### Langkah 2: Bandingkan dengan versi tambalan Berdasarkan halaman keamanan resmi masing-masing distro: - **Ubuntu 24.04:** `1:9.6p1-3ubuntu13.3` atau lebih baru. - **Ubuntu 22.04:** `1:8.9p1-3ubuntu0.10` atau lebih baru. - **Ubuntu 20.04:** tidak terdampak (OpenSSH-nya lebih lama dari 8.5p1). - **Debian 12 (bookworm):** `1:9.2p1-2+deb12u3` atau lebih baru. Debian 11 tidak terdampak. - **RHEL 9 dan turunannya (AlmaLinux 9, Rocky 9):** terdampak, pasang pembaruan openssh dari repositori resmi. Menurut Red Hat, RHEL 6, 7, dan 8 tidak terdampak. Bila versimu lebih rendah dari daftar di atas, lanjut ke langkah 3. ### Langkah 3: Perbarui paket ``` # Ubuntu dan Debian sudo apt update && sudo apt install --only-upgrade openssh-server # AlmaLinux, Rocky, RHEL sudo dnf update openssh openssh-server openssh-clients ``` ### Langkah 4: Restart sshd tanpa mengunci diri sendiri Sebelum restart, buka **sesi SSH kedua** dan biarkan tetap tersambung. Kalau ada yang salah, sesi itu jadi jalan keluarmu. ``` sudo sshd -t sudo systemctl restart ssh # Ubuntu dan Debian sudo systemctl restart sshd # keluarga RHEL ``` Perintah `sshd -t` memeriksa konfigurasi lebih dulu. Kalau tidak ada keluaran, konfigurasi valid. Setelah restart, coba login dari sesi baru sebelum menutup sesi lama. ### Langkah 5: Pastikan proses lama sudah berganti ``` sudo systemctl status ssh ``` Perhatikan waktu mulai (Active since) yang baru. Di Ubuntu 24.04, SSH bisa memakai socket activation (`ssh.socket`), jadi koneksi berikutnya otomatis memakai biner baru. Untuk memastikan, jalankan `sudo needrestart` (Debian dan Ubuntu) atau `sudo needs-restarting -s` (keluarga RHEL). ### Langkah 6: Mitigasi sementara bila belum bisa update Kalau paket belum bisa diperbarui (misalnya server lama tanpa akses repositori), Qualys menyebut setelan berikut di `/etc/ssh/sshd_config` menutup jalur eksekusi kode: ``` LoginGraceTime 0 ``` Efek sampingnya, penyerang bisa menghabiskan slot koneksi (MaxStartups) sehingga SSH sulit diakses, alias risiko denial of service. Jadi ini hanya penyelamat sementara. Lapisan tambahan yang sangat membantu: batasi IP yang boleh mengakses port 22 di firewall, atau akses SSH hanya lewat VPN. ### Langkah 7: Kurangi permukaan serangan SSH ke depan Tambalan menutup celah ini, tapi kebiasaan baik mengurangi dampak celah berikutnya: - Login dengan SSH key dan matikan password (`PasswordAuthentication no`). Alasannya ada di [SSH key vs password](https://nivelva.com/insight/ssh-key-vs-password). - Pasang [Fail2ban](https://nivelva.com/insight/fail2ban-blokir-brute-force) untuk memblokir IP yang terus mencoba login. - Aktifkan [update keamanan otomatis di Ubuntu](https://nivelva.com/insight/cara-mengaktifkan-update-keamanan-otomatis-ubuntu) agar tambalan seperti ini terpasang sendiri. Perlu dicatat, SSH key dan Fail2ban tidak mencegah regreSSHion karena celahnya ada sebelum proses autentikasi selesai. Yang benar-benar menutupnya hanyalah paket yang sudah ditambal. ## Ringkasan versi tambalan | Distro | Status | Versi paket aman | |:--|:--|:--| | Ubuntu 24.04 LTS | Terdampak, sudah ditambal | 1:9.6p1-3ubuntu13.3 ke atas | | Ubuntu 22.04 LTS | Terdampak, sudah ditambal | 1:8.9p1-3ubuntu0.10 ke atas | | Ubuntu 20.04 LTS | Tidak terdampak | - | | Debian 12 | Terdampak, sudah ditambal | 1:9.2p1-2+deb12u3 ke atas | | Debian 11 | Tidak terdampak | - | | RHEL 9, AlmaLinux 9, Rocky 9 | Terdampak, sudah ditambal | Paket openssh terbaru dari repo resmi | | RHEL 8 dan sebelumnya | Tidak terdampak | - | | OpenSSH upstream | Diperbaiki di 9.8p1 | 9.8p1 ke atas | ## Pertanyaan yang sering diajukan ### Server saya memakai OpenSSH 8.9p1, apakah pasti rentan? Belum tentu. Nomor upstream 8.9p1 ada di rentang rentan, tetapi Ubuntu 22.04 menambalnya di paket 1:8.9p1-3ubuntu0.10. Cek revisi paket distro, bukan hanya angka versi. ### Apakah mengganti port SSH dari 22 mencegah serangan ini? Tidak mencegah, hanya mengurangi pemindaian otomatis yang malas. Penyerang yang serius tetap bisa menemukan port SSH. Tambalan tetap wajib. ### Apakah update openssh-server memutus sesi SSH yang sedang aktif? Biasanya tidak. Sesi yang sudah berjalan memakai proses lama dan tetap tersambung. Koneksi baru akan memakai sshd yang sudah diperbarui setelah restart. ### Bagaimana kalau saya memakai image VPS atau template lama? Image lama membawa paket lama. Setelah membuat VPS dari image apa pun, langsung jalankan pembaruan sistem sebelum memasang aplikasi. Checklist singkat: - `dpkg -l` atau `rpm -q` menunjukkan versi paket di atas versi tambalan. - `sshd -t` bersih dan sshd sudah di-restart. - `needrestart` atau `needs-restarting` tidak lagi menyebut sshd. - `LoginGraceTime 0` dikembalikan ke nilai normal setelah paket diperbarui. - Port SSH dibatasi IP atau VPN bila memungkinkan. ## Sumber - - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/regresshion-cve-2024-6387-cek-tambal-openssh Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com