Cyber Security

SSH Hardening untuk Home Server — Dari Key-Based Auth sampai fail2ban

Written by Adam Muiz Updated: 21 Jul 2026 5 min read
SSH Hardening untuk Home Server — Dari Key-Based Auth sampai fail2ban

Beberapa waktu lalu aku iseng membuka log SSH di home server-ku — laptop bekas yang kujadikan server di sudut kamar. Yang kutemukan cukup membuka mata: ratusan percobaan login dari IP asing setiap harinya. Semuanya mencoba kombinasi username klasik seperti root, admin, ubuntu, lalu menebak password secara membabi buta. Server-ku bahkan tidak pakai port 22 standar, tapi bot-bot di internet tetap menemukannya.

Di sinilah aku sadar: memasang SSH di server itu seperti memasang pintu di rumah. Pintu saja tidak cukup — kamu butuh gembok yang bagus, dan kalau perlu kamera pengawas juga. Artikel ini merangkum langkah-langkah SSH hardening yang kuterapkan sendiri: key-based authentication, fail2ban, dan beberapa konfigurasi kecil yang efeknya besar.

Kenapa Password Saja Tidak Cukup?

Password itu ibarat gembok dengan kunci kombinasi. Sepanjang kuncinya cukup rumit, secara teori aman. Masalahnya, ada ribuan bot di internet yang tugasnya hanya satu: mencoba semua kombinasi, terus-menerus, tanpa lelah, tanpa bayaran. Ini namanya brute force attack.

Bayangkan ada orang asing berdiri di depan pagar rumahmu dan mencoba satu per satu kunci dari gantungan kunci raksasa berisi jutaan kunci. Mungkin dia tidak akan berhasil hari ini. Tapi kalau dia berdiri di sana selama setahun, peluangnya naik terus. Apalagi kalau kamu pakai password yang "lumayan umum" — tanggal lahir, nama pacar, atau P@ssw0rd123.

Solusi paling elegan: ganti gembok kombinasi dengan gembok yang hanya bisa dibuka oleh satu kunci fisik unik — dan kunci itu tidak bisa ditebak, tidak bisa difoto, tidak bisa ditebak dari bentuk gemboknya. Itulah key-based authentication.

Langkah 1: Key-Based Authentication

SSH key terdiri dari sepasang file: private key (kunci yang kamu simpan rapat di komputermu) dan public key (gembok yang kamu pasang di server). Server hanya akan membuka pintu untuk yang memegang private key yang cocok — dan menebak private key secara brute force secara praktis mustahil, karena ruang kemungkinannya astronomis.

Di komputer klien (laptop/PC yang biasa kamu pakai untuk SSH), generate key pair:

ssh-keygen -t ed25519 -C "adam@laptop-utama"

Aku sarankan ed25519 daripada RSA — lebih pendek, lebih cepat, dan lebih modern. Saat ditanya passphrase, isi. Passphrase ini lapisan pengaman ekstra: kalau private key-mu sampai dicuri, pencuri tetap butuh passphrase untuk memakainya.

Lalu kirim public key ke server:

ssh-copy-id -p 6393 [email protected]

Atau kalau ssh-copy-id tidak tersedia, cara manual:

cat ~/.ssh/id_ed25519.pub | ssh -p 6393 [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Tes dulu login pakai key di terminal baru. Jangan tutup sesi SSH yang sedang aktif — ini aturan emas saat oprek SSH. Kalau konfigurasi salah, kamu masih punya satu pintu terbuka untuk memperbaikinya.

Langkah 2: Matikan Login Password

Setelah key-based auth berjalan mulus, saatnya mencabut gembok kombinasi lama. Edit konfigurasi SSH server di /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitRootLogin no
MaxAuthTries 3

Penjelasan singkat:

  • PasswordAuthentication no — brute force password langsung jadi tidak relevan. Bot boleh mencoba jutaan kombinasi, server tidak akan pernah menanyakannya.
  • PermitRootLogin no — jangan pernah izinkan login langsung sebagai root. Login sebagai user biasa, lalu sudo. Kalau ada yang berhasil masuk, setidaknya dia tidak langsung jadi raja.
  • MaxAuthTries 3 — batasi percobaan per koneksi. Memperlambat penyerang dan membuat log lebih bersih.

Reload service SSH:

sudo systemctl reload ssh

Sekali lagi: tes login dari terminal baru sebelum menutup sesi lama.

Langkah 3: fail2ban — Satpam Otomatis

Key-based auth membuat brute force mustahil berhasil, tapi bot-bot itu tetap memenuhi log dan membuang resource. Di sinilah fail2ban berperan — seperti satpam yang mencatat wajah orang yang salah mencoba kunci tiga kali, lalu melarangnya mendekat selama sejam.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local, bagian [sshd]:

[sshd]
enabled = true
port = 6393
maxretry = 3
findtime = 600
bantime = 3600

Artinya: kalau satu IP gagal login 3 kali dalam 10 menit (findtime), blokir IP itu selama 1 jam (bantime). Jangan lupa sesuaikan port kalau kamu pakai port custom seperti aku.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Perintah terakhir menampilkan statistik jail: berapa IP yang sedang diblokir, berapa total yang pernah diblokir. Rasanya cukup memuaskan melihat daftar itu.

Langkah 4: Port Custom — Keamanan Lewat Ketidakterlihatan

Memindahkan SSH dari port 22 ke port lain (aku pakai 6393) sering diperdebatkan. Kritikus bilang ini "security through obscurity" — dan mereka benar, ini bukan mekanisme keamanan utama. Tapi sebagai pelengkap, efeknya nyata: log-ku yang tadinya penuh ratusan percobaan login per hari turun drastis.

Analoginya seperti memindahkan pintu rumah dari pinggir jalan raya ke gang kecil. Pagar dan gembok tetap yang menjaga — tapi setidaknya tidak setiap orang yang lewat iseng mencoba gagang pintunya.

# di /etc/ssh/sshd_config
Port 6393

Jangan lupa buka port baru di firewall sebelum menutup port 22, dan pastikan port barumu tidak bentrok dengan service lain.

Langkah 5: Batasi Siapa yang Boleh Masuk

Dua pengaman tambahan yang layak dipertimbangkan:

Batasi user — hanya izinkan user tertentu untuk SSH:

# di /etc/ssh/sshd_config
AllowUsers adam

Batasi IP — kalau kamu hanya akses dari jaringan tertentu (misalnya hanya dari LAN rumah atau lewat VPN seperti WireGuard/Tailscale), batasi di level firewall dengan nftables:

sudo nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 6393 accept
sudo nft add rule inet filter input tcp dport 6393 drop

Dengan ini, port SSH bahkan tidak terlihat dari luar jaringan. Tapi hati-hati: kalau kamu sedang di luar rumah dan VPN-mu bermasalah, kamu bisa terkunci dari servermu sendiri. Selalu punya rencana cadangan — aku sendiri mengandalkan tunnel Cloudflare sebagai jalur alternatif.

Checklist Akhir

  • Key-based auth aktif, login password dimatikan
  • PermitRootLogin no
  • fail2ban berjalan dan jail sshd aktif
  • Port custom (opsional, tapi membersihkan log)
  • AllowUsers dan/atau pembatasan IP di firewall
  • Sesi SSH lama tetap terbuka sampai semua konfigurasi terbukti berfungsi

Penutup

SSH hardening bukan pekerjaan sekali jadi. Ia lebih seperti merawat pagar rumah: sesekali periksa log (journalctl -u ssh), lihat siapa yang diblokir fail2ban, dan pastikan konfigurasi tidak berubah setelah update sistem. Lima langkah di atas sudah cukup membuat server kecilmu jadi target yang tidak menarik — bot akan menyerah dan pindah ke korban lain yang pintunya masih pakai gembok kombinasi.

Kalau kamu punya tips hardening lain yang terbukti ampuh di home server-mu, silakan berbagi di kolom komentar. Pengalaman lapangan selalu lebih berharga daripada teori.