Hardening SSH Access on Production Servers with KaliLinux.net

Akses SSH di server produksi bukan sudut kerja keamanan yang eksotis. Ini pintu yang selalu dibiarkan terbuka oleh administrator, sekaligus salah satu layanan pertama yang harus dipelajari analis keamanan junior untuk diaudit. Di KaliLinux.net, hardening SSH diperlakukan sebagai praktik defensif yang dimulai di lab terisolasi dan berakhir dengan konfigurasi server yang terverifikasi. Sistem Kali Linux memberimu alat yang sama seperti yang dipakai auditor berlisensi untuk memeriksa paparan OpenSSH sebelum menerapkan kontrol ke server milikmu atau yang punya izin tertulis untuk diuji.

Layanan OpenSSH produksi sering berjalan dengan default yang masuk akal, tetapi default bukan kebijakan. Penyerang memindai port 22 terus-menerus, dan opsi autentikasi yang salah konfigurasi membuatmu rentan terhadap credential stuffing, brute force, dan masalah kunci basi. Tujuan panduan ini sederhana: gunakan Kali Linux untuk memeriksa deployment SSH, pahami perubahan sisi server yang mengurangi resiko, lalu validasi perubahan itu tanpa menyentuh sistem yang bukan milikmu.

Mulai dengan audit SSH yang terkendali

Sebelum mengedit sshd_config pada apa pun yang penting, cek dulu apa yang sebenarnya diiklankan layanan. Kali Linux sudah membawa ssh-audit, skrip Python kecil yang terhubung ke server SSH dan melaporkan algoritma yang didukung, tipe host key, perilaku kompresi, dan kompatibilitas klien. Jalankan ke VM lab atau host staging yang boleh kau uji. Jangan jalankan ke server produksi orang lain.

Output ssh-audit bisa panjang, tapi baris pentingnya adalah peringatan. Alat ini menandai metode key exchange lemah, host key lama, dan cipher warisan. Banyak server produksi masih menerima diffie-hellman-group1-sha1 atau host key ssh-rsa karena tidak disentuh bertahun-tahun. Algoritma itu tidak lagi dianggap aman untuk deployment baru. Catatan rilis OpenSSH 8.8 menegaskan bahwa tanda tangan ssh-rsa dinonaktifkan secara default pada September 2021, jadi server yang masih mengandalkannya jelas tertinggal.

Inti audit bukan mengumpulkan amunisi. Tujuannya membuat baseline. Setelah mengubah pengaturan server, jalankan audit yang sama dan bandingkan outputnya. Loop itu lebih mudah dikelola kalau target berupa snapshot atau VM yang bisa diulang, sekaligus menjaga latihan tetap legal dan aman. Audit terkendali memberimu bukti sebelum dan sesudah, dan bukti lebih penting daripada intuisi saat membenarkan perubahan konfigurasi kepada tim.

Pengaturan OpenSSH modern yang mengurangi permukaan serangan

OpenSSH punya default bagus di rilis terbaru, tapi hardening produksi biasanya butuh beberapa perubahan eksplisit. Keputusan pertama apakah memindahkan SSH dari port 22. Perubahan port tidak menghentikan scanner yang gigih, tapi mengurangi volume noise login otomatis. Kalau kamu mengubah port, dokumentasikan dan perbarui aturan monitoring atau firewall pada hari yang sama.

Lebih penting dari port adalah kebijakan autentikasi. Di /etc/ssh/sshd_config, set PermitRootLogin ke no atau prohibit-password, karena login root langsung menghapus jejak audit administrator mana yang melakukan tindakan. Set PasswordAuthentication ke no setelah akses kunci berfungsi, dan set PubkeyAuthentication ke yes. Jaga MaxAuthTries rendah, biasanya 3 atau 4, dan set LoginGraceTime singkat seperti 30 atau 60 detik. Nilai kecil ini mengurangi waktu dan percobaan yang tersedia bagi penyerang yang menebak kredensial.

Pengaturan lain yang berguna misalnya AllowUsers atau AllowGroups untuk membatasi akun yang boleh login. Ini penting terutama di server dengan banyak akun layanan lokal. Akun MySQL atau backup tidak perlu akses SSH. Daftar izin eksplisit lebih mudah direview daripada daftar panjang nama yang ditolak. Setelah setiap perubahan, jalankan sshd -t untuk memvalidasi konfigurasi sebelum restart layanan. sshd_config yang rusak bisa menguncimu di luar, jadi jaga sesi kedua tetap terbuka kalau restart gagal.

Ganti password dengan autentikasi berbasis kunci

Password adalah bentuk autentikasi SSH paling lemah yang umum dipakai. Orang memakainya ulang, mengetiknya di depan orang lain, dan menyimpannya di dokumen bersama. Autentikasi berbasis kunci memberi tiap administrator identitas kriptografis yang kuat, dan bisa dicabut tanpa merubah semua shared secret. Generate pasangan kunci di workstation, bukan di server, dan lindungi private key dengan passphrase.

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/production_admin_ed25519

Perintah di atas membuat kunci Ed25519 dengan 100 putaran KDF, yang memperlambat tebakan offline kalau file private key sampai bocor. Letakkan public key di file ~/.ssh/authorized_keys server dan set permission 600 untuk file serta 700 untuk direktori .ssh. SSH akan menolak memakai authorized_keys kalau permission terlalu terbuka.

Setelah akses kunci terkonfirmasi untuk semua administrator, matikan autentikasi password di server. Lalu uji login berbasis kunci dari workstation Kali Linux. Kalau kamu nggak bisa login tanpa password, buka terminal kedua dan perbaiki masalah sebelum menutup sesi yang masih bekerja. Ini prosedur defensif standar, bukan trik. Ini mencegah kejadian umum di mana server terkunci karena path kunci salah atau bit permission terlewat. Tipe kunci modern seperti Ed25519 juga mempersingkat handshake dibanding kunci RSA lama, manfaat performa kecil di bastion sibuk.

Tambahkan fail2ban dan kontrol laju koneksi

Meski autentikasi password sudah mati, SSH tetap menerima percobaan login otomatis. Banyak percobaan itu langsung gagal karena tidak menawarkan kunci valid, tapi noise log membuat serangan nyata sulit terlihat. Fail2ban adalah layanan ringan yang memantau file log dan memblokir sementara alamat IP yang menunjukkan kegagalan berulang. Install lewat package manager normal dan aktifkan jail sshd.

Konfigurasi fail2ban dasar bisa pakai bantime = 600, maxretry = 3, dan findtime = 600. Artinya tiga percobaan gagal dalam sepuluh menit berujung blokir sepuluh menit. Setel nilainya sesuai lingkungan, tapi jangan set maxretry ke nol. Rate limiting bukan pengganti autentikasi berbasis kunci, tapi mengurangi volume log dan membuat scanner otomatis pindah.

Di lapisan jaringan, pertimbangkan menambah rate limit koneksi dengan firewall seperti nftables atau iptables. Di bastion SSH khusus, aturan yang hanya mengizinkan segelintir koneksi baru per menit dari satu IP bisa memperlambat alat brute force. Hati-hati dengan lingkungan NAT, karena banyak pengguna bisa berbagi satu IP publik. Rate limit yang terlalu agresif bisa mengunci satu kantor. Uji aturan di antarmuka lab sebelum menerapkan ke traffic produksi.

Validasi hasil dengan alat Kali Linux

Setelah perubahan server selesai, kembali ke mesin Kali Linux dan verifikasi hasilnya. Mulai dengan ssh-audit lagi dan bandingkan peringatan dengan baseline. Tujuannya bukan skor sempurna, karena kompatibilitas dengan klien lama bisa memaksa kompromi. Tujuannya menghilangkan algoritma dengan kelemahan yang diketahui dan memahami sisa peringatan.

Nmap juga bisa mengonfirmasi banner layanan dan status port. Scan sederhana seperti nmap -p 22 -sV pada target yang diotorisasi menunjukkan apakah layanan SSH masih terjangkau dan apakah banner sesuai versi OpenSSH yang diharapkan. Pakai Wireshark hanya jika perlu memeriksa negosiasi di lingkungan lab