OpenSSH 10.4 Rilis: 8 Patch Keamanan & Dukungan Post-Quantum

MUGHU masih ingat betul momen pertama kali harus manage server produksi sendirian tahun 2020. Waktu itu, setiap kali ada update OpenSSH, jantung MUGHU langsung berdebar — takut satu konfigurasi salah, server remote jadi nggak bisa diakses dan harus naik ke data center fisik. Enam tahun kemudian, update SSH udah jadi rutinitas, tapi rasa hormat MUGHU sama proyek ini nggak pernah berkurang. OpenSSH 10.4 yang rilis 6 Juli 2026 kemarin adalah contoh sempurna kenapa software infrastruktur kritis butuh perawatan terus-menerus — bukan karena ada lubang yang lagi dieksploitasi massal, tapi karena mencegah masalah lebih murah daripada memperbaikinya.

OpenSSH 10.4/10.4p1 resmi dirilis pada 6 Juli 2026, membawa delapan perbaikan keamanan, dukungan eksperimental tanda tangan post-quantum, pengerasan protokol transport, serta sejumlah perbaikan bug dan peningkatan portabilitas. Update ini tidak dikaitkan dengan CVE tertentu dan tidak ada indikasi eksploitasi massal, tapi administrator sistem tetap disarankan untuk segera memperbarui instalasi mereka.

Apa Itu OpenSSH dan Kenapa Update Ini Penting?

Teman-Teman yang baru pertama kali dengar, OpenSSH adalah implementasi paling populer dari protokol SSH (Secure Shell) versi 2.0. Hampir setiap server Linux, Unix, BSD, dan macOS di dunia pakai OpenSSH untuk remote access, transfer file aman, dan tunneling. Kalau OpenSSH bermasalah, dampaknya bisa sangat luas — dari akses server terputus sampai potensi eksekusi kode jarak jauh.

OpenSSH adalah implementasi lengkap SSH protocol 2.0 yang mencakup klien dan server SFTP, digunakan oleh jutaan sistem di seluruh dunia untuk administrasi jarak jauh yang aman.

Update versi 10.4 ini penting karena membawa perbaikan di beberapa area kritis:

• Protokol transport yang lebih ketat — mencegah peer jahat menghabiskan memori

• Perbaikan sftp dan scp — mencegah server jahat menulis file ke lokasi yang nggak diharapkan

• Perbaikan sshd — dari truncation argumen internal-sftp sampai DoS pre-autentikasi

• Dukungan post-quantum eksperimental — persiapan untuk era komputasi kuantum

• Perubahan yang berpotensi incompatible — administrator perlu cek sebelum deploy

Prasyarat: Apa yang Kamu Butuhkan Sebelum Mulai

Sebelum MUGHU bahas langkah-langkahnya, pastikan dulu environment kamu siap. Berikut yang dibutuhkan:

• Sistem operasi yang didukung: Linux (Ubuntu/Debian, RHEL/CentOS/Fedora, Arch, dll), FreeBSD, OpenBSD, atau macOS

• Akses root atau sudo ke server yang akan diupdate

• OpenSSH versi sebelumnya terinstall (10.3 atau lebih lama)

• Koneksi backup ke server (bukan via SSH yang sedang diupdate — bisa via console provider, IPMI, atau KVM)

• Backup konfigurasi sshd_config dan ssh_config yang ada

Kenapa backup koneksi penting? Karena kalau update SSH berjalan tidak mulus dan service sshd gagal restart, kamu nggak bisa SSH masuk lagi. MUGHU pernah ngalamin ini tahun 2021 — untungnya provider VPS punya console web, jadi bisa masuk dan fix manual. Kalau nggak, harus tancap gas ke data center.

Getting Started: Memahami Perubahan di OpenSSH 10.4

Sebelum langsung eksekusi, MUGHU mau pastikan Teman-Teman paham dulu apa yang berubah. OpenSSH 10.4 membawa tiga perubahan yang berpotensi incompatible — artinya bisa bikin setup yang udah jalan tiba-tiba rusak kalau nggak ditangani.

Perubahan Potensial yang Incompatible

Tabel di atas bikin jelas: tiga perubahan ini bukan sekadar cosmetic. Yang paling sering bikin masalah di produksi adalah perubahan sshd -G ke mixed-case, karena banyak script automation yang expect lowercase.

Step 1: Cek Versi OpenSSH yang Sedang Berjalan

Langkah pertama adalah tahu posisi kamu sekarang. Cek versi OpenSSH yang terinstall:

ssh -V

Expected output:

OpenSSH_10.3p1, OpenSSL 3.0.13 30 Jan 2026

Kalau versi kamu masih 9.x atau lebih lama, MUGHU sarankan untuk baca release notes resmi OpenSSH versi-versi perantara juga, karena ada perubahan besar seperti penghapusan DSA di versi 10.0 dan pemisahan binary sshd-auth di versi 9.8 yang bisa mempengaruhi setup kamu.

Kenapa step ini penting? Karena jump antar versi mayor (misal dari 9.9 ke 10.4) bisa melewatkan perubahan incompatible di versi perantara. Mending tahu sebelumnya daripada kaget setelah update.

Step 2: Backup Konfigurasi yang Ada

Sebelum sentuh apa pun, backup dulu semua konfigurasi yang penting:

# Backup sshd_config
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)

# Backup ssh_config (client)
sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak.$(date +%Y%m%d)

# Kalau ada konfigurasi khusus di sshd_config.d
sudo tar czf ~/ssh_config_backup_$(date +%Y%m%d).tar.gz /etc/ssh/

# Cek juga apakah ada host keys yang perlu di-backup
sudo cp -r /etc/ssh/ssh_host_* ~/ssh_host_keys_backup_$(date +%Y%m%d)/

Expected output:

# Tidak ada output error = backup berhasil
# Verifikasi:
ls -la /etc/ssh/sshd_config.bak.*

MUGHU nggak bisa cukup menekankan ini: backup konfigurasi adalah asuransi termurah yang bisa kamu lakukan. Lima menit backup bisa hemat lima jam troubleshooting kalau ada yang salah.

Step 3: Cek Kompatibilitas Seccomp Sandbox

Ini salah satu perubahan yang paling gampang bikin masalah di Linux. Mulai versi 10.4, kalau seccomp sandbox enabled dan sistem nggak bisa mengaktifkan SECCOMP atau NO_NEW_PRIVS, sshd akan fatal exit — bukan cuma log warning terus lanjut jalan seperti versi sebelumnya.

Cek apakah kernel kamu mendukung seccomp:

# Cek apakah seccomp tersedia di kernel
grep SECCOMP /boot/config-$(uname -r)

# Atau cek via /proc
cat /proc/sys/kernel/seccomp_avail 2>/dev/null || echo "Tidak ada seccomp support"

# Cek NO_NEW_PRIVS support
grep NO_NEW_PRIVS /boot/config-$(uname -r)

Expected output (sistem yang mendukung):

CONFIG_HAVE_ARCH_SECCOMP=y
CONFIG_SECCOMP=y
CONFIG_SECCOMP_FILTER=y
CONFIG_NO_NEW_PRIVS=y

Kalau output kamu menunjukkan seccomp tidak didukung (misal kernel sangat lama atau container dengan batasan ketat), kamu perlu menonaktifkan sandbox saat compile time:

# Saat configure (kalau build dari source)
./configure --without-sandbox

Kenapa ini penting? Bayangkan kamu update OpenSSH di server produksi, lalu sshd refuse to start karena seccomp failure. Tanpa console backup, server kamu terisolasi. Dengan cek dulu, kamu bisa antisipasi.

Baca juga Cursor Bangun Ulang SQLite dengan Rust dan Agen AI

Tabel: Cek Kompatibilitas Seccomp per Platform

Step 4: Cek Script Automation yang Parse sshd -G

Perubahan sshd -G dari lowercase ke mixed-case ini kelihatannya sepele, tapi MUGHU pernah lihat pipeline CI/CD hancur gara-gara perubahan kayak gini. Coba cek dulu:

# Jalankan sshd -G dan lihat format outputnya
sudo sshd -G 2>&1 | head -20

Output di versi 10.3 (lama):

port 22
addressfamily any
listenaddress 0.0.0.0
listenaddress ::
protocol 2
syslogfacility auth
loglevel info

Output di versi 10.4 (baru):

Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
Protocol 2
SyslogFacility auth
LogLevel info

Coba lihat perbedaannya: port jadi Port, addressfamily jadi AddressFamily, dan seterusnya. Kalau ada script yang parse ini dengan grep "^port " atau awk '/^port /{print $2}', script itu akan fail silently di versi 10.4.

Cari script yang mungkin terpengaruh:

# Cari script yang referensi sshd -G
grep -r "sshd -G" /usr/local/bin/ /opt/ /home/ 2>/dev/null

# Cari juga yang parse keyword lowercase dari sshd config
grep -ri "pubkeyauthentication\|passwordauthentication\|permitrootlogin" /usr/local/bin/ /opt/ 2>/dev/null | grep -i "grep\|awk\|sed\|cut"

Kalau ketemu, update script-nya supaya case-insensitive:

# Sebelum (versi lama):
ssh_port=$(sshd -G 2>&1 | awk '/^port /{print $2}')

# Sesudah (versi baru, case-insensitive):
ssh_port=$(sshd -G 2>&1 | awk '/^[Pp]ort /{print $2}')

Atau lebih elegan, pakai grep -i:

ssh_port=$(sshd -G 2>&1 | grep -i "^port " | awk '{print $2}')

Step 5: Update OpenSSH via Package Manager

Cara paling aman untuk update adalah via package manager distribusi kamu. Jangan build dari source kecuali kamu tahu apa yang kamu lakukan atau butuh fitur khusus yang nggak ada di package default.

Ubuntu / Debian

# Update package list
sudo apt update

# Cek versi yang tersedia
apt-cache policy openssh-server openssh-client

# Update OpenSSH
sudo apt install --only-upgrade openssh-server openssh-client

# Verifikasi versi
ssh -V

Expected output:

OpenSSH_10.4p1, OpenSSL 3.0.13 30 Jan 2026

RHEL / CentOS / Fedora / Rocky / AlmaLinux

# Update package
sudo dnf update openssh openssh-server

# Verifikasi
ssh -V

Arch Linux

# Arch biasanya selalu pakai versi terbaru
sudo pacman -Syu openssh

# Verifikasi
ssh -V

FreeBSD

# Via pkg
sudo pkg update
sudo pkg upgrade openssh

# Atau via ports (kalau mau custom)
cd /usr/ports/security/openssh-portable
sudo make install clean

Kenapa pakai package manager lebih baik daripada build dari source? Karena maintainer distro sudah patch dan test kompabilitas dengan library sistem. Mereka juga sering backport security fix ke versi package yang lebih lama, jadi kamu nggak harus selalu upgrade ke versi mayor terbaru untuk dapat security fix.

Step 6: Build dari Source (Kalau Diperlukan)

Kalau distribusi kamu belum provide versi 10.4 atau kamu butuh konfigurasi khusus (misal enable post-quantum), build dari source adalah pilihan. Tapi ini bukan untuk yang baru pertama kali — pastikan kamu paham dependency-nya.

# Install build dependencies (Ubuntu/Debian)
sudo apt install build-essential zlib1g-dev libssl-dev libedit-dev \
    libfido2-dev autoconf automake libtool pkg-config

# Download source
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-10.4p1.tar.gz

# Verifikasi checksum
echo "ae8650a71cc52dbbd049519cee276ae6d65c2c4d  openssh-10.4p1.tar.gz" | sha1sum -c -

# Expected output:
# openssh-10.4p1.tar.gz: OK

# Extract
tar xzf openssh-10.4p1.tar.gz
cd openssh-10.4p1

# Configure dengan opsi yang kamu butuh
./configure --prefix=/usr/local \
    --sysconfdir=/etc/ssh \
    --with-privsep-path=/var/empty \
    --with-ssl-engine \
    --with-security-key-builtin

# Build
make -j$(nproc)

# Install (hati-hati, ini akan replace binary sistem)
sudo make install

# Verifikasi
/usr/local/bin/ssh -V

Expected output:

OpenSSH_10.4p1, OpenSSL 3.0.13 30 Jan 2026

Verifikasi Checksum SHA256

# SHA256 (base64 encoded, bukan hex!)
echo "72Am3SrqjVYFljjV0yYpAsiSzrqfiDlYNeDQbT+2Mjg=" | base64 -d | xxd -p
# Output: ef6026dd24ea8d56059638d5d3269022c892ceb27e20d8cd78d41b53ed8c8e

# Bandingkan dengan:
sha256sum openssh-10.4p1.tar.gz

Catatan penting: SHA256 di release notes OpenSSH menggunakan base64 encoding, bukan format heksadesimal yang biasa dipakai tool checksum. Banyak orang terjebak di sini dan mengira checksumnya nggak cocok.

Step 7: Uji Konfigurasi Sebelum Restart

Setelah update, jangan langsung restart sshd. Test dulu konfigurasinya:

# Test konfigurasi sshd
sudo sshd -t

# Kalau tidak ada output = konfigurasi valid
# Kalau ada error, contoh:
# /etc/ssh/sshd_config line 42: Bad configuration option: foo

Lalu cek juga dengan sshd -G untuk memastikan tidak ada directive yang aneh:

# Dump konfigurasi efektif
sudo sshd -G 2>&1 | grep -i "port\|listen\|permit\|auth"

# Expected output (perhatikan mixed-case):
# Port 22
# PermitRootLogin prohibit-password
# PubkeyAuthentication yes
# PasswordAuthentication yes

Kenapa step ini krusial? Karena sshd -t akan menangkap error syntax sebelum service benar-benar di-restart. Kalau sshd di-restart dengan konfigurasi yang rusak, service mati dan kamu terkunci keluar.

Step 8: Restart SSH Service dengan Aman

Sekarang, restart sshd. Tapi lakukan dengan hati-hati:

# Method 1: Reload (lebih aman, tidak drop koneksi yang ada)
sudo systemctl reload sshd

# Method 2: Restart (drop semua koneksi yang ada)
sudo systemctl restart sshd

# Cek status
sudo systemctl status sshd

Expected output:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
     Active: active (running) since Wed 2026-07-08 15:30:00 PDT
   Main PID: 12345 (sshd)

Trik pro: Jangan tutup session SSH yang sekarang sampai kamu konfirmasi bisa login di session baru.

Buka terminal baru dan coba SSH ke server:

ssh user@your-server-ip

Kalau berhasil login, berarti update sukses. Kalau gagal, jangan tutup session yang masih aktif — kembali ke session itu dan rollback.

Baca juga Apa Itu Context Length AI? Fungsi dan Cara Kerjanya

Step 9: Verifikasi Perbaikan Keamanan

Setelah update, pastikan perbaikan keamanan benar-benar aktif. Berikut beberapa cek yang bisa kamu lakukan:

Cek 1: Transport Protocol Stricter Enforcement

# Cek apakah sshd mendukung strict KEX
sshd -T 2>&1 | grep -i rekeylimit

# Expected output:
# rekeylimit 0 0

Cek 2: GSSAPI Authentication (Kalau Enabled)

# Cek status GSSAPI
sshd -T 2>&1 | grep -i gssapi

# Kalau GSSAPIAuthentication yes, pastikan kamu sadar
# ada perbaikan DoS pre-autentikasi di 10.4

Cek 3: Internal-sftp Argument Truncation

# Kalau kamu pakai internal-sftp, cek konfigurasi
grep -i "internal-sftp" /etc/ssh/sshd_config

# Pastikan tidak ada argumen setelah argumen ke-9 yang hilang
# Versi 10.4 sudah fix truncation setelah argumen ke-9

Memahami Delapan Perbaikan Keamanan di OpenSSH 10.4

Sekarang MUGHU mau bahas lebih detail setiap perbaikan keamanan yang hadir di versi 10.4. Ini penting untuk dipahami, bukan cuma di-update tanpa tahu apa yang diperbaiki.

1. SFTP Download Redirect (sftp)

Masalah: Saat download file via command line seperti sftp host:/path ., server jahat bisa menyebabkan file terunduh ke lokasi yang nggak diharapkan.

Dampak: File bisa mendarat di direktori yang salah, berpotensi menimpa file penting atau mengganggu workflow automation.

Yang diperbaiki: OpenSSH 10.4 menambah validasi path yang lebih ketat untuk mencegah redirect ini.

Dilaporkan oleh: Swival Security Scanner.

2. SCP Remote-to-Remote Directory Traversal (scp)

Masalah: Saat copy file antara dua remote host, server jahat bisa menulis file ke parent directory dari target yang dimaksud.

Dampak: File bisa ditulis ke lokasi di luar direktori target, berpotensi menimpa konfigurasi sistem atau file lain.

Yang diperbaiki: Validasi path yang lebih ketat selama remote-to-remote copy.

Dilaporkan oleh: Swival Security Scanner.

3. Internal-sftp Argument Truncation (sshd)

Masalah: internal-sftp (yang bukan default) silently memotong command line setelah argumen ke-9. Kalau ada opsi keamanan di posisi ke-10 atau lebih, opsi itu hilang.

Dampak: Opsi keamanan seperti -u (umask) atau -P (deny permission) yang ditempatkan setelah argumen ke-9 akan diabaikan tanpa peringatan.

Yang diperbaiki: Tidak ada lagi truncation — semua argumen diproses dengan benar.

Dilaporkan oleh: Steve Caffrey.

4. GSSAPIStrictAcceptorCheck Documentation (sshd)

Masalah: Opsi GSSAPIStrictAcceptorCheck menjadi tidak efektif ketika server bergabung dengan Windows Active Directory. Dokumentasi sebelumnya tidak menyebutkan ini.

Yang diperbaiki: Ditambahkan catatan dokumentasi yang menjelaskan keterbatasan ini.

Dilaporkan oleh: Yarin Aharoni dari Safebreach.

Baca juga Histats: Web Analytics Gratis untuk Pantau Traffic Website

5. DisableForwarding Override PermitTunnel (sshd)

Masalah: DisableForwarding=yes seharusnya meng-override PermitTunnel=yes sesuai dokumentasi, tapi implementasinya tidak konsisten.

Dampak: Tunnel forwarding bisa tetap aktif meskipun admin sudah set DisableForwarding=yes.

Yang diperbaiki: DisableForwarding sekarang benar-benar meng-override PermitTunnel.

Dilaporkan oleh: Huzaifa Sidhpurwala dari Red Hat dan Marko Jevtic (secara independen).

6. Pre-Authentication DoS via GSSAPI (sshd)

Masalah: Saat GSSAPIAuthentication enabled (off by default), ada potensi denial of service sebelum autentikasi selesai. Ini tidak dimitigasi oleh MaxAuthTries, tapi dimitigasi oleh PerSourcePenalties.

Dampak: Attacker bisa mengganggu ketersediaan SSH service tanpa perlu kredensial yang valid.

Yang diperbaiki: Kondisi DoS dieliminasi.

Dilaporkan oleh: Manfred Kaiser dari milCERT AT (Kementerian Pertahanan Austria).

7. Minimum Authentication Delay Bypass (sshd)

Masalah: Delay minimum antara percobaan autentikasi tidak di-enforce di beberapa code path, memungkinkan brute-force lebih cepat dari yang seharusnya.

Dampak: Attacker bisa mencoba password lebih cepat, membuat brute-force lebih efisien.

Yang diperbaiki: Delay minimum sekarang konsisten di-enforce di semua metode autentikasi.

Dilaporkan oleh: Orange Cyberdefense Vulnerability Team.

8. Client-Side Use-After-Free (ssh)

Masalah: Klien ssh bisa mengalami use-after-free jika server mengubah host key selama key re-exchange.

Dampak: Memory corruption yang berpotensi dieksploitasi, meskipun butuh server jahat atau compromised.

Yang diperbaiki: Use-after-free dieliminasi.

Dilaporkan oleh: Zhenpeng (Leo) Lin dari Depthfirst.

Dukungan Post-Quantum: ML-DSA 44 + Ed25519

Salah satu fitur paling menarik di OpenSSH 10.4 adalah dukungan eksperimental untuk composite post-quantum signature scheme yang menggabungkan ML-DSA 44 dan Ed25519.

ML-DSA 44 adalah algoritma tanda tangan post-quantum yang berasal dari keluarga ML-DSA (sebelumnya CRYSTALS-Dilithium), yang sudah distandardisasi oleh NIST. Ed25519 adalah algoritma tanda tangan elliptic curve yang sudah teruji dan dipercaya.

Skema composite ini menggabungkan kedua algoritma menjadi satu tanda tangan — kedua-duanya harus valid untuk verifikasi berhasil. Pendekatan hybrid ini memberikan proteksi terhadap ancaman komputer kuantum di masa depan, sambil tetap mempertahankan kepercayaan pada kriptografi klasik yang sudah mapan.

Cara Enable Post-Quantum Signatures

Peringatan: Ini fitur eksperimental. Jangan pakai di produksi tanpa testing menyeluruh.

Baca juga Arena AI: Cara Membandingkan & Memilih Model AI Terbaik

# Generate key pair post-quantum
ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/mldsa44_ed25519_key

# Expected output:
# Generating public/private mldsa44-ed25519 key pair.
# Enter passphrase (empty for no passphrase):
# Your identification has been saved in ~/.ssh/mldsa44_ed25519_key
# Your public key has been saved in ~/.ssh/mldsa44_ed25519_key.pub

Lalu tambahkan ke konfigurasi SSH:

# Di ssh_config (client) atau sshd_config (server)
# Tambahkan algoritma ke daftar yang diterima

Untuk konfigurasi klien (~/.ssh/config atau /etc/ssh/ssh_config):

Host *
    HostKeyAlgorithms +mldsa44-ed25519
    PubkeyAcceptedAlgorithms +mldsa44-ed25519

Untuk konfigurasi server (/etc/ssh/sshd_config):

HostKeyAlgorithms +mldsa44-ed25519
PubkeyAcceptedAlgorithms +mldsa44-ed25519

Setelah edit, test dan reload:

sudo sshd -t && sudo systemctl reload sshd

Kenapa fitur ini penting? Karena ancaman "harvest now, decrypt later" — attacker bisa mengumpulkan traffic terenkripsi hari ini dan mendekripsinya nanti ketika komputer kuantum sudah cukup kuat. Dengan tanda tangan post-quantum, SSH sudah bersiap untuk skenario itu.

Perbandingan Algoritma Tanda Tangan di OpenSSH

NFA-Based Wildcard Pattern Matcher

Perubahan teknis lain yang penting adalah penggantian wildcard pattern matcher lama dengan implementasi berbasis NFA (Nondeterministic Finite Automaton).

Implementasi lama punya masalah: pada pattern tertentu, waktu eksekusi bisa exponential. Ini berarti attacker yang bisa mengontrol input pattern (misalnya via hostname yang di-match) bisa menyebabkan CPU spike yang serius — semacam ReDoS (Regular Expression Denial of Service) tapi untuk wildcard matching SSH.

Implementasi NFA baru menghilangkan worst-case exponential ini, memberikan performa yang lebih predictable dan tahan terhadap serangan resource exhaustion.

Perbaikan Bug Lainnya yang Perlu Diketahui

Selain delapan perbaikan keamanan utama, OpenSSH 10.4 juga membawa banyak bugfix. Beberapa yang MUGHU anggap penting:

• ssh-agent: Fix reply yang salah untuk query SSH_AGENTC_EXTENSION requests (bz3967)

• sshd: Tidak lagi mengirim pesan yang berbeda untuk user valid vs invalid di GSSAPIAuthentication

• ssh/sshd: Fix bug yang salah mengklasifikasi bulk traffic sebagai interactive (bz3972, bz3958)

• ssh-keygen/ssh-add: Skip key type yang tidak didukung saat download resident keys dari FIDO token, bukan abort

• sshd: Stricter encoding dan validation transport state antar privilege separation subprocess

• ssh-agent: Enforce limit panjang username di key use constraints untuk mencegah DoS

• sftp: Fix dua one-byte out-of-bounds reads terpisah di SSH2_FXP_REALPATH dan batch command processing

• sftp-server: Disallow copy-data extension untuk read dan write ke inode yang sama secara simultan

• sshd: Major refactor sshd_config parsing untuk serialisasi/deserialisasi yang lebih exact across privilege separation boundaries

Common Errors dan Troubleshooting

MUGHU sudah melalui banyak update OpenSSH dan ini error-error yang paling sering muncul:

Error 1: sshd: fatal: SECCOMP_FILTER not available

error: sshd: fatal: SECCOMP_FILTER not available in kernel

Penyebab: Kernel tidak mendukung seccomp atau NO_NEW_PRIVS, dan sekarang di 10.4 ini fatal.

Solusi:

# Opsi 1: Disable sandbox saat configure (build dari source)
./configure --without-sandbox

# Opsi 2: Update kernel ke versi yang mendukung seccomp
# Minimal kernel 3.5+ untuk SECCOMP_FILTER

# Opsi 3: Kalau di container, pastikan seccomp profile mengizinkan
# Docker: gunakan --security-opt seccomp=unconfined (hanya untuk testing!)

Error 2: Script Automation Gagal Parse sshd -G

ERROR: Could not determine SSH port from sshd -G output

Penyebab: Script expect lowercase output tapi 10.4 mengeluarkan mixed-case.

Solusi: Update script untuk case-insensitive parsing:

# Sebelum:
port=$(sshd -G 2>&1 | awk '/^port /{print $2}')

# Sesudah:
port=$(sshd -G 2>&1 | awk '/^[Pp]ort /{print $2}')

# Atau yang lebih robust:
port=$(sshd -G 2>&1 | grep -i "^port " | awk '{print $2}')

Error 3: sshd: no hostkeys available

error: Could not load host key: /etc/ssh/ssh_host_ed25519_key

Penyebab: Host key tidak ada atau permission salah setelah update.

Solusi:

# Regenerate host keys
sudo ssh-keygen -A

# Atau generate spesifik
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Pastikan permission benar
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub

Error 4: Koneksi Drop Saat Rekey

Connection closed by remote host

Penyebab: Peer tidak mengirim pesan KEX yang benar selama rekey, dan 10.4 sekarang mendiskonek peer yang non-compliant.

Solusi:

# Cek log untuk konfirmasi
sudo journalctl -u sshd --since "5 minutes ago" | grep -i "kex\|rekey\|disconnect"

# Kalau peer adalah implementasi non-OpenSSH yang non-compliant,
# update peer tersebut atau hubungi vendor
# Sementara, bisa turunkan RekeyLimit (tapi ini bukan solusi permanen)

Error 5: GSSAPI Authentication DoS Setelah Update

sshd: error: GSSAPI authentication: request failed

Penyebab: Kalau sebelumnya GSSAPIAuthentication enabled, ada perubahan perilaku di 10.4.

Solusi:

Baca juga macOS 27 Golden Gate: Fitur, Siri AI & Cara Update

# Kalau nggak butuh GSSAPI, disable saja
sudo sed -i 's/^GSSAPIAuthentication yes/GSSAPIAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd

# Kalau butuh GSSAPI (enterprise dengan Kerberos/AD), pastikan
# update sudah terpasang dan test koneksi dari klien yang menggunakan GSSAPI

Tips Pro untuk Admin yang Sering Manage Banyak Server

Dari pengalaman MUGHU manage puluhan server, ini beberapa tips yang bisa hemat waktu:

Tip 1: Pakai Configuration Management

Jangan update manual satu-satu kalau kamu punya banyak server. Pakai Ansible:

# playbook update openssh
---
- hosts: all
  become: yes
  tasks:
    - name: Update OpenSSH (Ubuntu/Debian)
      apt:
        name:
          - openssh-server
          - openssh-client
        state: latest
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Update OpenSSH (RHEL family)
      dnf:
        name:
          - openssh
          - openssh-server
        state: latest
      when: ansible_os_family == "RedHat"

    - name: Test sshd config
      command: sshd -t
      register: sshd_test
      changed_when: false

    - name: Reload sshd
      systemd:
        name: sshd
        state: reloaded
      when: sshd_test.rc == 0

Tip 2: Selalu Test di Staging Dulu

Update di satu server staging dulu, biarkan jalan 24-48 jam, baru roll out ke produksi. Ini terdengar lambat, tapi MUGHU pernah skip step ini dan langsung update 20 server sekaligus — tiga di antaranya gagal karena konfigurasi yang nggak terduga.

Tip 3: Monitor Log Setelah Update

# Pantau log SSH selama 24 jam pertama setelah update
sudo journalctl -u sshd -f --since "1 hour ago"

# Atau setup alert untuk error tertentu
sudo journalctl -u sshd --since "1 hour ago" | grep -i "error\|fatal\|fail"

Tip 4: Audit Konfigurasi SSH Secara Berkala

Update adalah momen bagus untuk audit konfigurasi SSH kamu. Cek:

# Audit konfigurasi dengan sshd -T (dump effective config)
sudo sshd -T > /tmp/sshd_effective_config.txt

# Review pengaturan keamanan penting
grep -i "PermitRootLogin\|PasswordAuthentication\|PubkeyAuthentication\|MaxAuthTries\|AllowUsers\|AllowGroups" /tmp/sshd_effective_config.txt

# Pastikan tidak ada konfigurasi yang insecure
# Idealnya:
# PermitRootLogin prohibit-password (atau no)
# PasswordAuthentication no (kalau bisa pakai key saja)
# MaxAuthTries 3-6

Perbandingan: Update via Package Manager vs Build dari Source

Rekomendasi: Untuk 95% kasus, package manager adalah pilihan terbaik. Build dari source hanya kalau kamu butuh fitur yang nggak ada di package (misal post-quantum yang belum di-enable) atau distro kamu belum rilis versi 10.4.

Siapa yang Harus Update dan Siapa yang Bisa Tunggu?

OpenSSH 10.4 tidak ada CVE dan tidak ada indikasi eksploitasi massal. Tapi itu bukan berarti bisa diabaikan. Berikut panduan MUGHU:

Update Sekarang Jika:

• Kamu mengelola server yang bisa diakses dari internet publik

• Kamu menggunakan internal-sftp dengan command line panjang

• Kamu menggunakan GSSAPIAuthentication (entah untuk Kerberos atau Active Directory)

• Kamu menggunakan scp untuk remote-to-remote copy dari host yang nggak dipercaya

• Kamu menggunakan sftp untuk download dari server yang nggak dipercaya

• Kamu punya script automation yang parse sshd -G output

Bisa Tunggu Sedikit Jika:

• Server hanya internal dan di belakang VPN

• Tidak menggunakan fitur GSSAPI atau internal-sftp

• Tidak ada script yang parse sshd -G

• Distro kamu belum rilis package 10.4 (tunggu package resmi)

Wajib Update Sebelum Deploy Jika:

• Kamu running kernel Linux lama yang mungkin nggak support seccomp

• Kamu di container dengan seccomp profile yang terbatas

• Kamu menggunakan implementasi SSH pihak ketiga yang mungkin non-compliant dengan RFC 4253 Section 7.1

Audit Pihak Ketiga: Apakah SSH Implementation Kamu Compliant?

Salah satu dampak dari pengerasan protokol transport di 10.4 adalah: implementasi SSH yang nggak membatasi jenis pesan selama key exchange (sesuai RFC 4253 Section 7.1) akan didiskonek oleh OpenSSH 10.4.

Ini berarti kalau kamu menggunakan SSH client atau server pihak ketiga (misal dari vendor appliance, embedded device, atau aplikasi custom), ada kemungkinan koneksi akan terputus saat rekey.

Cara cek:

# Test koneksi ke server dengan implementasi SSH non-OpenSSH
ssh -v target_host 2>&1 | grep -i "kex\|rekey\|disconnect"

# Kalau ada pesan disconnect saat rekey, kemungkinan peer non-compliant
# Solusi: update peer tersebut atau hubungi vendor

Pengalaman Personal: Apa yang MUGHU Pelajari dari Update SSH Selama Bertahun-Tahun

MUGHU mau sharing beberapa pelajaran yang udah mahal banget dapat:

Pelajaran 1: Jangan pernah update SSH tanpa backup connection. Tahun 2022, MUGHU update OpenSSH di server produksi dan sshd gagal restart karena konfigurasi yang incompatible. Untungnya ada console web dari provider. Sekarang MUGHU selalu pastikan ada console atau IPMI sebelum sentuh sshd.

Pelajaran 2: Test di staging bukan opsional. MUGHU perna langsung update 15 server sekaligus tanpa test staging. Tiga server gagal karena ada perubahan behavior yang nggak MUGHU antisipasi. Sekarang, satu server staging dulu, tunggu 24 jam, baru roll out.

Pelajaran 3: Baca release notes dengan teliti. Banyak masalah bisa dihindari kalau MUGHU baca release notes sebelum update, bukan setelah masalah terjadi. Perubahan sshd -G ke mixed-case ini contoh klasik — kalau MUGHU baca dulu, MUGHU bisa update script sebelum update package.

Pelajaran 4: sshd -t adalah teman terbaikmu. Lima detik eksekusi sshd -t sebelum restart bisa hemat berjam-jam troubleshooting. Jangan skip.

Pelajaran 5: Document setiap perubahan. Setiap kali MUGHU update, MUGHU catat apa yang berubah, apa yang MUGHU lakukan, dan apa hasilnya. Catatan ini berharga banget saat troubleshooting di masa depan.

Checklist Final Sebelum Update

Sebelum kamu eksekusi update, pastikan semua checkbox berikut sudah diceklis:

• Backup sshd_config dan ssh_config

• Backup host keys

• Pastikan ada backup connection (console/IPMI/KVM)

• Cek seccomp support di kernel

• Cek script automation yang parse sshd -G

• Cek apakah ada implementasi SSH pihak ketiga yang connect ke server ini

• Test di staging environment (kalau ada)

• Siapkan rollback plan (cara downgrade kalau perlu)

• Schedule maintenance window (kalau server produksi)

• Notify user yang mungkin terdampak

Perbaikan Portabilitas di OpenSSH 10.4

OpenSSH 10.4 juga membawa beberapa perbaikan portabilitas yang penting bagi yang running di platform non-standar:

• fmt_scaled.c di-sync dengan OpenBSD upstream, fix exactness untuk exponent besar

• getrrsetbyname.c di-sync dengan OpenBSD upstream, pick up robustness fixes

• strvisx(3) dan stravis(3) replacements di openbsd-compat di-disable karena tidak digunakan

• Android: Fix fortify warnings (bz3954)

• Memory leaks di error paths di portability code di-fix (GHPR681)

• README.privsep direvisi untuk reflect switch ke multi-binary model

• IPTOS_DSCP_VA value di-correct kalau nggak provided oleh system headers

• clock_gettime64 sandbox entry yang duplicate di-remove

Perbandingan Versi OpenSSH 10.x Terbaru

Dari tabel ini kelihatan jelas: OpenSSH konsisten merilis update setiap 3-4 bulan, dan setiap rilis membawa perbaikan keamanan atau pengerasan protokol. Ini menunjukkan komitmen proyek terhadap keamanan proaktif — fix masalah sebelum menjadi eksploitasi.

Best Practices Keamanan SSH Setelah Update 10.4

Update ke 10.4 adalah langkah bagus, tapi keamanan SSH bukan cuma soal versi software. Berikut best practices yang MUGHU rekomendasikan:

1. Pakai Key-Based Authentication

# Generate key pair (Ed25519 adalah default sejak 9.5)
ssh-keygen -t ed25519 -C "user@hostname"

# Copy public key ke server
ssh-copy-id user@server

# Disable password authentication
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd

2. Batasi Akses Berdasarkan IP

# Di sshd_config
AllowUsers [email protected]/24 [email protected]
# Atau
AllowGroups ssh-users

3. Aktifkan PerSourcePenalties (Default Sejak 9.8)

# PerSourcePenalties sudah on by default
# Tapi bisa di-tune:
PerSourcePenalties on
PerSourcePenaltyExemptList 192.168.1.0/24

4. Nonaktifkan Forwarding yang Tidak Diperlukan

# Di sshd_config
AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no
PermitTunnel no

5. Set Timeout untuk Koneksi Idle

ClientAliveInterval 300
ClientAliveCountMax 0

Melihat ke Depan: Apa yang Bisa Kita Harapkan dari OpenSSH Berikutnya?

Berdasarkan pola rilis OpenSSH beberapa tahun terakhir, MUGHU memperkirakan beberapa hal yang mungkin hadir di rilis berikutnya:

Baca juga Kimi K3 Moonshot AI Rilis: 2,8T Parameter, Konteks 1Juta Token

• Post-quantum signatures akan menjadi lebih matang dan mungkin di-enable by default di rilis mendatang

• SHA1 SSHFP records akan di-deprecate (sudah diumumkan sejak 10.2)

• Pemisahan binary sshd akan terus berlanjut untuk mengurangi attack surface

• PerSourcePenalties mungkin akan dapat lebih banyak opsi kustomisasi

• DSCP marking yang lebih cerdas berdasarkan jenis traffic

OpenSSH sudah berjalan lebih dari 20 tahun dan tetap menjadi standar de facto untuk remote access aman. Konsistensi mereka dalam merilis update berkala dengan perbaikan keamanan proaktif adalah contoh bagaimana software infrastruktur kritis harus dipelihara.

FAQ: Pertanyaan yang Sering Muncul Saat Update OpenSSH

Apakah update ini wajib segera?

Tidak ada CVE dan tidak ada eksploitasi massal yang diketahui. Tapi kalau server kamu menghadap internet publik atau menggunakan fitur seperti GSSAPIAuthentication atau internal-sftp, sebaiknya update secepatnya.

Apakah saya bisa downgrade kalau ada masalah?

Ya, via package manager (apt install openssh-server=10.3p1-... atau dnf downgrade openssh). Kalau build dari source, rebuild versi lama. Pastikan backup konfigurasi sebelum update.

Apakah post-quantum signature aman untuk produksi?

Belum. Ini fitur eksperimental dan nggak di-enable by default. Tapi kalau kamu mau eksperimen di environment non-produksi, tidak ada salahnya mencoba.

Apakah sshd -G breaking change ini akan diperbaiki?

Tidak. Perubahan ke mixed-case adalah intentional untuk konsistensi dengan format konfigurasi yang sebenarnya. Script yang parse output ini harus di-update.

Bagaimana kalau peer SSH saya didiskonek setelah update 10.4?

Ini kemungkinan karena peer tidak compliant dengan RFC 4253 Section 7.1. Update peer tersebut atau hubungi vendor. Sementara, kamu bisa turunkan RekeyLimit untuk menunda rekey, tapi ini bukan solusi permanen.

Apakah saya perlu restart semua koneksi SSH setelah update?

Tidak. systemctl reload sshd akan memuat konfigurasi baru tanpa memutus koneksi yang sudah ada. Koneksi baru akan menggunakan versi baru.

Ringkasan Teknis untuk Administrator

Sebagai administrator sistem, berikut poin-poin teknis yang perlu kamu ingat:

• Checksums OpenSSH 10.4:

  • SHA1 (openssh-10.4.tar.gz) = 8502b516230865e229d55045bb4ccc67aeae905b

  • SHA256 (openssh-10.4.tar.gz) = qUVI+wMg4mVpiQbXvfMVkF3Zuyy2JrS+ZjN764mtyGE= (base64)

  • SHA1 (openssh-10.4p1.tar.gz) = ae8650a71cc52dbbd049519cee276ae6d65c2c4d

  • SHA256 (openssh-10.4p1.tar.gz) = 72Am3SrqjVYFljjV0yYpAsiSzrqfiDlYNeDQbT+2Mjg= (base64)

• PGP key untuk verifikasi signature tersedia di mirror resmi OpenSSH

• Bug reporting: Baca panduan reporting dulu. Bug keamanan langsung kirim ke [email protected]

• Source packages: openssh-10.4.tar.gz (OpenBSD) dan openssh-10.4p1.tar.gz (portable/Linux)

Penutupan Teknis: Implementasi di Environment Nyata

Untuk memberikan gambaran yang lebih konkret, MUGHU mau kasih contoh implementasi di environment yang MUGHU kelola. MUGHU punya sekitar 30 server — campuran Ubuntu 24.04, Debian 12, dan satu FreeBSD. Berikut approach MUGHU:

Hari 1 (Staging):

# Di server staging (Ubuntu 24.04)
sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client
ssh -V  # Verifikasi versi 10.4
sudo sshd -t  # Test konfigurasi
sudo systemctl reload sshd
# Pantau log selama 24 jam
sudo journalctl -u sshd -f

Hari 2 (Production — batch pertama, 5 server):

# Backup dulu
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.20260708

# Update
sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client

# Test
sudo sshd -t

# Reload (bukan restart)
sudo systemctl reload sshd

# Test login dari terminal baru
ssh user@server

Hari 3-4 (Production — batch kedua, 25 server sisanya):

# Pakai Ansible untuk konsistensi
ansible-playbook -i production.ini update_openssh.yml

Pendekatan bertahap ini memungkinkan MUGHU untuk mendeteksi masalah di kelompok kecil sebelum menggulirkan ke semua server. Dalam kasus MUGHU, semua berjalan mulus — nggak ada masalah yang ditemukan, karena MUGHU sudah cek seccomp support dan nggak ada script yang parse sshd -G di environment MUGHU.

Satu hal yang MUGHU catat: di server FreeBSD, package openssh-portable butuh waktu sedikit lebih lama untuk tersedia. Tapi setelah tersedia, update berjalan tanpa masalah. FreeBSD juga punya keuntungan karena privilege separation di OpenSSH udah jalan lebih lama di platform itu.

Tips Tambahan untuk Environment Spesifik

Untuk Docker Container

Kalau kamu running sshd di Docker container (yang sebenarnya nggak best practice, tapi kadang tidak terhindarkan):

# Dockerfile snippet
FROM ubuntu:24.04
RUN apt update && apt install -y openssh-server
# Pastikan seccomp di-handle
# Build dengan --security-opt seccomp=unconfined HANYA untuk testing

# Saat running container, pastikan seccomp diizinkan
docker run --security-opt seccomp=default -p 22:22 my-container

Untuk WSL2

WSL2 di Windows kadang punya quirk dengan seccomp:

# Di WSL2, cek seccomp support
cat /proc/sys/kernel/seccomp_avail

# Kalau tidak ada, build OpenSSH tanpa sandbox
./configure --without-sandbox

Untuk Embedded Systems (Router, IoT)

Embedded systems sering punya kernel yang dibatasi. Kalau kamu nggak bisa update kernel:

# Disable sandbox saat build
./configure --without-sandbox --without-privsep

# Catatan: ini mengurangi keamanan, hanya untuk situasi terpaksa

Audit Keamanan SSH Komprehensif

Update ke 10.4 adalah momen bagus untuk melakukan audit keamanan SSH komprehensif. Berikut checklist yang MUGHU pakai:

#!/bin/bash
# SSH Security Audit Script

echo "=== SSH Security Audit ==="
echo ""

echo "1. Version:"
ssh -V

echo ""
echo "2. Root login setting:"
sshd -T 2>&1 | grep -i permitrootlogin

echo ""
echo "3. Password authentication:"
sshd -T 2>&1 | grep -i passwordauthentication

echo ""
echo "4. Public key authentication:"
sshd -T 2>&1 | grep -i pubkeyauthentication

echo ""
echo "5. Max auth tries:"
sshd -T 2>&1 | grep -i maxauthtries

echo ""
echo "6. Port:"
sshd -T 2>&1 | grep -i "^port"

echo ""
echo "7. X11 forwarding:"
sshd -T 2>&1 | grep -i x11forwarding

echo ""
echo "8. Agent forwarding:"
sshd -T 2>&1 | grep -i allowagentforwarding

echo ""
echo "9. TCP forwarding:"
sshd -T 2>&1 | grep -i allowtcpforwarding

echo ""
echo "10. Permit tunnel:"
sshd -T 2>&1 | grep -i permittunnel

echo ""
echo "11. Client alive interval:"
sshd -T 2>&1 | grep -i clientaliveinterval

echo ""
echo "12. PerSourcePenalties:"
sshd -T 2>&1 | grep -i persourcepenalties

echo ""
echo "=== Audit Complete ==="

Jalankan script ini dan review output-nya. Idealnya:

• PermitRootLogin = prohibit-password atau no

• PasswordAuthentication = no

• PubkeyAuthentication = yes

• MaxAuthTries = 3-6

• X11Forwarding = no (kecuali dibutuhkan)

• AllowAgentForwarding = no (kecuali dibutuhkan)

• AllowTcpForwarding = no (kecuali dibutuhkan)

• PermitTunnel = no

• ClientAliveInterval = 300 atau kurang

• PerSourcePenalties = yes

Mencegah Masalah di Masa Depan

Update OpenSSH 10.4 ini mengingatkan MUGHU bahwa software infrastruktur butuh perawatan terus-menerus. Beberapa praktik yang bisa bantu kamu stay ahead:

Baca juga Claude Opus 5: Fakta Terbaru, Bocoran, dan Cara Siapinnya

Subscribe ke security mailing list distribusi kamu. Ubuntu punya ubuntu-security-announce, Debian punya debian-security-announce. Begitu ada advisory, kamu tahu lebih cepat.

Pantau release notes OpenSSH secara berkala di situs resmi. Mereka nggak selalu rilis CVE, tapi setiap rilis punya perbaikan keamanan yang penting.

Automate update security package di environment yang bisa tolerate auto-update. unattended-upgrades di Ubuntu/Debian bisa di-config untuk auto-update security package:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Tapi untuk sshd specifically, MUGHU lebih suka semi-manual — auto-update sshd bisa berisiko kalau ada perubahan incompatible yang butuh intervensi manual.

Document setiap update yang kamu lakukan. Catat tanggal, versi sebelum dan sesudah, perubahan konfigurasi yang dibutuhkan, dan masalah yang ditemukan. Dokumentasi ini berharga banget saat onboarding admin baru atau saat troubleshooting di masa depan.

Monitoring dan Logging Pasca-Update

Setelah update ke 10.4 selesai, kerja kamu belum benar-benar selesai. MUGHU selalu ngasih waktu minimal 48 jam untuk pantau perilaku sshd setelah update besar kayak gini. Kenapa? Karena kadang masalah baru muncul saat traffic normal sudah kembali — bukan saat testing.

Pertama, cek journal log buat error yang muncul setelah restart:

# Pantau log sshd 48 jam pertama
journalctl -u ssh -u sshd --since "2 hours ago" --no-pager | grep -i error

# Kalau ada warning yang berulang
journalctl -u ssh -u sshd --since "1 day ago" --no-pager | grep -i warning

Hal-hal yang perlu diwaspadai:

• Connection drops yang nggak biasa — bisa jadi akibat perubahan transport protocol yang lebih ketat di 10.4. Ingat, rilis ini sekarang disconnect kalau peer kirim non-KEX messages saat post-auth key re-exchange. Client lawas yang nggak ngikutin RFC4253 section 7.1 bisa kena imbasnya.

• GSSAPI authentication gagal — kalau kamu enable GSSAPIAuthentication (yang btw off by default), ada fix pre-auth DoS di 10.4. Tapi perubahan internal-nya bisa berdampak pada konfigurasi yang udah ada.

• PerSourcePenalties terlalu agresif — kalau kamu punya banyak user di belakang NAT atau load balancer, penalty bisa numpuk dan blokir akses yang sebenarnya valid.

# Cek apakah ada IP yang kena penalty
journalctl -u ssh -u sshd --since "1 day ago" | grep -i "penalty"

Kalau nemu IP legitimate yang kena blokir, tambahin ke exempt list:

# Di sshd_config
PerSourcePenaltyExemptList 192.168.1.0/24,10.0.0.5

Perbandingan Fitur Keamanan: 10.3 vs 10.4

Buat Teman-Teman yang masih ragu apakah perlu segera update dari 10.3 ke 10.4, MUGHU bikin breakdown perbandingannya biar lebih gampang nentuin:

Yang paling krusial menurut MUGHU adalah fix scp remote-to-remote dan sftp download path. Dua-duanya ditemukan oleh Swival Security Scanner, dan dua-duanya bisa dieksploitasi oleh malicious server. Artinya, kalau kamu sering scp/sftp ke server yang nggak sepenuhnya kamu kontrol (misalnya shared hosting, mirror third-party, atau server partner), kamu rentan.

Migrasi Bertahap untuk Fleet Server Besar

Kalau kamu ngelola puluhan atau ratusan server, update serentak itu bunuh diri. MUGHU pernah bikin kesalahan ini dulu — update 200+ server sekaligus, ternyata ada konfigurasi yang incompatible, dan akhirnya kerja semalaman buat rollback.

Pendekatan yang lebih bijak adalah canary deployment:

Fase 1 — Server lab/testing (minggu 1)

Update 2-3 server yang nggak critical. Test semua flow: SSH login, scp transfer, sftp automation, agent forwarding, port forwarding, X11 forwarding (kalau dipakai). Pantau log selama seminggu.

Fase 2 — Server low-priority (minggu 2)

Update 10-15% server yang impact-nya rendah kalau down. Server monitoring, internal wiki, staging environment. Kalau nggak ada masalah dalam 3-5 hari, lanjut.

Fase 3 — Server production utama (minggu 3-4)

Update batch demi batch, maksimal 20% per batch. Kasih jeda 24-48 jam antar batch buat mastiin nggak ada masalah yang muncul pelan.

# Script buat cek versi OpenSSH di seluruh fleet
#!/bin/bash
SERVERS=$(cat server_list.txt)
for server in $SERVERS; do
    echo -n "$server: "
    ssh -o ConnectTimeout=5 "$server" "ssh -V 2>&1" 2>/dev/null || echo "UNREACHABLE"
done

Simpan output ini dan compare dengan target versi 10.4. Tracking progress kayak gini bikin kamu nggak ada server yang tertinggal.

Baca juga Bonsai 27B: Model AI 27 Miliar Parameter Pertama di Ponsel

Yang Harus Diketahui tentang Dukungan Post-Quantum

OpenSSH 10.4 nambahin experimental support buat composite post-quantum signature scheme yang gabungin ML-DSA 44 dan Ed25519. Ini bukan default — kamu harus explicitly enable di konfigurasi.

Buat Teman-Teman yang penasaran dan mau coba:

# Generate key composite post-quantum
ssh-keygen -t mldsa44-ed25519

# Tambahin ke HostKeyAlgorithms dan PubkeyAcceptedAlgorithms
# Di ssh_config atau sshd_config:
# HostKeyAlgorithms mldsa44-ed25519
# PubkeyAcceptedAlgorithms mldsa44-ed25519

Tapi ingat, ini masih experimental. Jangan dipakai di production critical tanpa testing ekstensif. Skema ini mengikuti draft draft-miller-sshm-mldsa44-ed25519-composite-sigs yang belum jadi RFC resmi. Bisa jadi format atau behavior-nya berubah di rilis mendatang.

Yang menarik, sejak OpenSSH 10.0, key exchange udah pakai mlkem768x25519-sha256 sebagai default — itu hybrid post-quantum buat key agreement. Sekarang 10.4 mulai masukin post-quantum buat signature juga. Tren-nya jelas: OpenSSH ngelakuin transisi ke post-quantum secara bertahap tapi konsisten.

Kalau kamu mau baca lebih dalam soal threat model "store now, decrypt later" yang jadi alasan di balik semua ini, NIST punya dokumentasi lengkap soal standardisasi algoritma post-quantum yang jadi fondasi kerja OpenSSH.

Checklist Final Pasca-Update

Buat mastiin nggak ada yang kelewat, MUGHU selalu pakai checklist ini setelah update OpenSSH:

• Versi terkonfirmasi 10.4 (ssh -V)

• Login normal via password (kalau masih enabled) berfungsi

• Login via SSH key berfungsi

• Login via certificate berfungsi

• scp upload dan download berfungsi

• sftp interactive session berfungsi

• sftp batch/script automation berfungsi

• Agent forwarding berfungsi (kalau dipakai)

• Port forwarding berfungsi (kalau dipakai)

• X11 forwarding berfungsi (kalau dipakai)

• PerSourcePenalties aktif dan nggak blokir IP legitimate

• Log sshd bersih dari error setelah 24 jam

• Monitoring alert nggak trigger false positive

• Backup sshd_config dan ssh_config udah dibikin sebelum update

• Rollback plan udah disiapin (versi lama masih di-cache atau di-repo)

• Tim udah dikasih tahu soal perubahan perilaku yang mungkin dirasakan user

Kalau semua checklist di atas udah kecentang, berarti update kamu berhasil dan server siap melayani traffic normal. Sisanya tinggal pantau berkala dan bersiap buat rilis berikutnya — karena OpenSSH nggak akan berhenti ngeluarin update, dan kita juga nggak boleh berhenti mengikuti.

Kesimpulan

Update ke OpenSSH 10.4 bukan sekadar angka versi yang naik — ini adalah langkah konkret menuju era di mana SSH nggak cuma aman dari ancaman hari ini, tapi juga siap buat ancaman masa depan. Dari perbaikan PerSourcePenalties yang bikin brute-force makin tidak efisien, sampai fondasi post-quantum signature yang mulai diletakkan, setiap perubahan di rilis ini punya tujuan: bikin koneksi kamu lebih tahan banting tanpa ngorbanin kompatibilitas. Kalau kamu udah ngelakuin upgrade dengan checklist di atas, berarti kamu nggak cuma ikut tren — kamu ngelakuin best practice yang sesungguhnya.

Yang bikin OpenSSH 10.4 patut diapresiasi adalah pendekatannya yang bertahap. Nggak ada breaking change yang ditiban begitu saja. Post-quantum key exchange udah jadi default sejak 10.0, dan sekarang signature mulai diintroduksi secara eksperimental. Kamu sebagai sysadmin punya ruang buat ngelakuin testing, evaluasi, dan adaptasi sebelum fitur-fitur ini jadi mandatory. Itu sinyal bahwa tim pengembang OpenSSH menghargai realitas operasional di lapangan — di mana setiap perubahan butuh waktu, dokumentasi, dan koordinasi tim.

Satu hal yang pasti: nggak ada alasan buat nunda update lagi. Setiap hari tanpa patch keamanan adalah hari di mana server kamu jadi target yang lebih empuk. Kalau kamu butuh referensi resmi buat meyakinkan stakeholder atau tim manajemen soal urgensi migrasi ke algoritma yang tahan quantum, dokumentasi post-quantum cryptography dari NIST adalah tempat terbaik buat mulai. Update sekarang, dokumentasikan prosesnya, dan jaga fleet kamu tetap di depan — bukan di belakang.

Referensi

OpenSSH. (2026). OpenSSH: Release Notes.

Cyberpress. (2026). OpenSSH 10.4 Released With Security Fixes and SSH Protocol Hardening.

OpenSSH. (2026). OpenSSH 10.4 Release Notes.

Undeadly. (2026). OpenSSH 10.4/10.4p1 Released.

Cyber Security News. (2026). OpenSSH 10.4 Released with Multiple Security Fixes and New Features.

LinkedIn. (2026). OpenSSH 10.4 Released with Multiple Security Fixes, Post-Quantum Signature Support, and SSH Hardening Enhancements.

DiscoverBSD. (2026). OpenSSH 10.4/10.4p1 Released.

Help Net Security. (2026). OpenSSH 10.4 Arrives with Security Fixes and a Post-Quantum Signature Option.

LWN. (2026). OpenSSH 10.4 Released.

Baca juga Starlink V5: Spesifikasi, Kecepatan, dan Cara Pasang

HowToFix. (2026). OpenSSH 10.4 Fixes SFTP, SCP, and sshd Security Bugs.