SSH Hardening: Panduan Mengunci Server dari Serangan Brute Force 2026

Setiap server yang terekspos ke internet hampir pasti diserang. Cek saja log authentication di server mana pun yang IP-nya publik — akan terlihat puluhan hingga ribuan percobaan login dari bot yang mencoba kombinasi username dan password secara acak. Serangan ini menargetkan satu protokol: SSH.

Berita baiknya, SSH hardening adalah salah satu tugas keamanan yang paling berdampak dan paling mudah dilakukan. Artikel ini membahas langkah-langkah mengamankan SSH secara bertahap — dari dasar sampai lanjutan — lengkap dengan contoh konfigurasi yang bisa langsung diterapkan di server Ubuntu atau Debian.

Mengapa SSH Selalu Jadi Target

SSH adalah protokol standar untuk administrasi jarak jauh server Linux. Karena hampir semua server memilikinya aktif, port 22 menjadi target yang sangat menarik bagi botnet yang memindai internet secara masif. Bot tidak membedakan target — mereka hanya mencoba ribuan kombinasi password per menit, berharap ada satu yang berhasil.

Statistik dari berbagai honeypot menunjukkan serangan brute force SSH terjadi terus-menerus sepanjang hari, tidak pernah berhenti. Sebagian besar gagal, tapi cukup satu kombinasi lemah yang lolos, attacker langsung punya akses ke server. Hardening SSH adalah cara menutup pintu ini sebelum jadi masalah.

Langkah 1: Key-Based Authentication

Langkah paling fundamental adalah mematikan autentikasi password dan hanya mengizinkan login pakai SSH key. Pertama, buat pasangan key di mesin lokal (laptop atau workstation):

ssh-keygen -t ed25519 -C "[email protected]"

Key ed25519 lebih cepat dan dianggap lebih aman dibanding RSA dengan panjang yang sama. Setelah key dibuat, salin public key ke server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

Verifikasi dulu bahwa login pakai key berhasil sebelum mematikan password — jangan sampai terkunci di luar server sendiri. Setelah key terkonfirmasi jalan, ubah konfigurasi SSH di /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Lalu restart service SSH:

sudo systemctl restart ssh

Dengan password dimatikan, brute force kehilangan maknanya — bot tidak punya cara masuk karena password tidak lagi diterima.

Langkah 2: Nonaktifkan Login Root

Username root adalah target paling umum bot karena namanya pasti ada di semua sistem. Nonaktifkan login root langsung melalui SSH dan biasakan login sebagai user biasa, lalu naikkan privilege saat dibutuhkan:

PermitRootLogin no

User admin tetap bisa menjalankan perintah dengan sudo. Dengan cara ini, attacker harus menebak username (yang biasanya dibuat unik) dan tidak bisa langsung menyasar root. Kombinasi ini saja sudah mengurangi sebagian besar percobaan otomatis.

Langkah 3: Ganti Port dan Batasi IP

Memindahkan SSH dari port 22 ke port non-standar bukan pengaman utama, tapi sangat efektif mengurangi noise bot yang memindai port 22:

Port 22022

Setelah ganti port, semua koneksi SSH harus menyebut port baru: ssh -p 22022 user@server. Ini menurunkan volume serangan otomatis drastis karena kebanyakan bot hanya menargetkan port 22.

Langkah yang lebih kuat adalah membatasi IP yang boleh mengakses SSH. Di Ubuntu dengan UFW:

sudo ufw allow from 203.0.113.10 to any port 22022 proto tcp
sudo ufw deny 22022/tcp

Ganti 203.0.113.10 dengan IP kantor atau rumah. Dengan allowlist IP, siapa pun di luar daftar tidak bisa terhubung ke SSH sama sekali — serangan dari mana pun otomatis ditolak di level firewall.

Langkah 4: Pasang fail2ban

Kalau allowlist IP tidak memungkinkan (misalnya IP dinamis), fail2ban adalah lapisan pengaman berikutnya. fail2ban memantau log autentikasi dan memblokir IP yang gagal login berkali-kali:

sudo apt install fail2ban

Buat file jail lokal untuk SSH:

sudo nano /etc/fail2ban/jail.local

Isi dengan konfigurasi dasar:

[sshd]
enabled = true
maxretry = 5
bantime = 3600
findtime = 600

Artinya: 5 kali gagal dalam 10 menit, IP diblokir 1 jam. Restart fail2ban:

sudo systemctl restart fail2ban

Untuk memantau IP yang sedang diblokir:

sudo fail2ban-client status sshd

fail2ban bekerja cepat dan efektif — setelah beberapa hari berjalan, daftar banned IP biasanya sudah puluhan, dan serangan yang sampai ke layer aplikasi tinggal sedikit.

Langkah 5: Konfigurasi Lanjutan

Beberapa opsi tambahan yang patut dipertimbangkan untuk server production:

• Two-factor authentication. Gabungkan key dengan TOTP (Google Authenticator) untuk lapisan ganda. Pakai modul libpam-google-authenticator.
• Batas jumlah percobaan. Set MaxAuthTries 3 agar koneksi yang gagal berulang kali diputus cepat.
• Alamat bind. Kalau SSH hanya dipakai dari jaringan internal, bind ke IP internal saja: ListenAddress 10.0.0.5.
• Disable forwarding yang tidak perlu. Set AllowTcpForwarding no dan X11Forwarding no kecuali memang dibutuhkan.
• Batasi user. AllowUsers admin deploy memastikan hanya user tertentu yang bisa SSH.

Setiap opsi yang dimatikan mengurangi permukaan serangan. Prinsipnya: hanya aktifkan yang benar-benar dipakai.

Verifikasi Hasil Hardening

Setelah semua langkah diterapkan, verifikasi bahwa konfigurasi valid sebelum restart:

sudo sshd -t

Perintah ini memvalidasi sintaks sshd_config tanpa menerapkan perubahan. Kalau output kosong (tidak ada error), restart dengan aman:

sudo systemctl restart ssh

Jangan lupa membuka sesi SSH baru di terminal lain untuk memastikan login masih jalan sebelum menutup sesi lama. Ini kebiasaan yang menyelamatkan — satu kesalahan konfigurasi bisa mengunci akses ke server.

Memantau Aktivitas SSH

Hardening tidak berhenti di konfigurasi — aktivitas SSH perlu dipantau agar percobaan yang mencurigakan terlihat. Log autentikasi SSH ada di journal:

# Semua percobaan login SSH
journalctl -u ssh --since "1 day ago" | grep -i "authentication|failed|accepted"

# IP yang paling sering gagal login
journalctl -u ssh --since "1 day ago" -o json | grep -i "failed password" | grep -oP 'from K[0-9.]+' | sort | uniq -c | sort -rn | head -10

Pola yang patut diwaspadai: banyak percobaan dari satu IP dalam waktu singkat, username yang tidak umum, atau percobaan berhasil di luar jam kerja. Kalau fail2ban aktif, IP nakal otomatis diblokir — tapi memantau log tetap penting untuk melihat tren serangan dan memastikan konfigurasi bekerja.

Untuk audit jangka panjang, pertimbangkan mengirim log SSH ke sistem log terpusat atau menyimpannya dengan rotasi yang lebih panjang. Konfigurasi audit di Ubuntu juga bisa diaktifkan lewat auditd untuk mencatat perubahan pada sshd_config dan file otorisasi — berguna saat menyelidiki insiden atau memenuhi kebutuhan compliance.

Checklist Hardening Lengkap

Ringkasan semua langkah dalam satu checklist yang bisa dicentang saat mengonfigurasi server baru:

• Autentikasi. Key-based auth aktif, PasswordAuthentication no, key disimpan dengan permission 600 di ~/.ssh.
• Akses root. PermitRootLogin no, admin login sebagai user biasa dengan sudo.
• Permukaan serangan. MaxAuthTries 3, AllowTcpForwarding no (kecuali dibutuhkan), X11Forwarding no.
• Jaringan. Port alternatif atau allowlist IP di firewall, SSH hanya bind ke interface yang dibutuhkan.
• Deteksi. fail2ban aktif dengan maxretry dan bantime yang sesuai, log autentikasi dipantau.
• Verifikasi. sudo sshd -t lolos, sesi baru bisa login, sesi lama tetap aman.
• Opsi lanjutan. 2FA untuk akses admin, key diputar berkala, key lama dihapus dari authorized_keys.

Checklist ini bisa dijalankan dalam 15-30 menit untuk server baru. Untuk server lama yang sudah berjalan bertahun-tahun, terapkan bertahap dan uji setiap langkah — terutama yang berisiko mengunci akses seperti mematikan password atau mengganti port.

Yang sering dilupakan: hardening bukan sekali jalan. Key yang tidak pernah diputar, user yang tidak pernah dihapus, dan port yang diganti tapi tidak dicatat di dokumentasi semuanya menggerus keamanan seiring waktu. Jadikan audit SSH bagian dari rutinitas bulanan, bukan hanya pekerjaan awal.

Kesimpulan

SSH hardening adalah salah satu investasi keamanan termurah dengan dampak terbesar. Key-based auth mematikan brute force, login root yang dinonaktifkan menutup target paling umum, dan fail2ban memblokir IP nakal secara otomatis.

Urutan penerapannya bisa bertahap: mulai dari key auth dan matikan password, lalu nonaktifkan root, tambah fail2ban, dan terakhir pertimbangkan port alternatif atau allowlist IP. Setiap lapisan menambah waktu dan usaha yang harus dikeluarkan attacker — dan untuk sebagian besar kasus, itu sudah cukup membuat mereka pindah ke target lain.