Cara Amankan SSH VPS dari Brute Force: 7 Langkah Gampang yang Wajib Dicoba

Halo Sobat Online! Coba bayangkan pintu depan rumahmu: setiap malam ada ratusan orang asing yang memutar kenop satu per satu, berharap menemukan satu pintu yang lupa dikunci. Itulah yang terjadi pada port 22 di VPS mana pun yang terhubung ke internet. Kabar baiknya, cara amankan SSH VPS ini jauh lebih sederhana daripada yang dibayangkan — dalam waktu sekitar 30 menit kita bisa memaksa semua bot itu pulang dengan tangan kosong.

Anggap SSH sebagai pintu layanan sebuah gedung. Sekarang pintunya masih bisa dibuka dengan tebakan kata sandi: cukup tahu alamatnya, lalu coba satu juta kombinasi sampai ketemu. Setelah tujuh langkah di bawah, pintu itu hanya bisa dibuka oleh kunci fisik yang kamu pegang (kunci kriptografi), dipantau kamera, dan penebak akan diblokir otomatis di percobaan ketiga.

Di panduan ini kita kerjakan berurutan: memasang kunci ed25519, mematikan login password dan root, menutup semua port dengan UFW, memasang fail2ban, mengaktifkan patch otomatis, sampai menguji hasilnya dari luar. Semua perintah bisa disalin-tempel, dan yang dibutuhkan hanya VPS Ubuntu 24.04/26.04 plus satu terminal.

Kenapa SSH Jadi Sasaran Favorit Bot?

SSH adalah satu-satunya pintu yang memberi akses level root dari jarak jauh. Kalau bot berhasil menebak password-nya, seluruh server — database, website, backup — ada di tangannya. Karena itu, mesin pemindai otomatis (scanner) menyisir seluruh rentang IPv4 tanpa henti, dan VPS baru biasanya sudah kebanjiran percobaan login dalam hitungan jam.

Cek dulu seberapa ramai “antrean” di pintu SSH-mu:


sudo journalctl -u ssh --since "24 hours ago" | grep -c "Failed password"
sudo journalctl -u ssh --since "24 hours ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
sudo lastb | head

Perintah pertama menghitung jumlah login gagal sehari terakhir, perintah kedua menampilkan IP yang paling rajin mencoba, dan lastb membaca catatan percobaan gagal dari log khusus. Angka ratusan sampai ribuan adalah hal normal untuk VPS yang belum dikunci — bukan tanda servermu sudah bobol, tapi tanda bahwa pintunya sedang digedor terus.

Cara Amankan SSH VPS: 7 Langkah yang Akan Kita Tempuh

Buat kunci ed25519 dan pastikan bisa login dengannya.
Matikan login password dan root lewat sshd_config.d.
Tutup semua port dengan UFW, sisakan SSH, HTTP, dan HTTPS.
Pasang fail2ban supaya penebak password diblokir otomatis.
Nyalakan patch keamanan otomatis (unattended-upgrades).
Kecilkan permukaan serangan: layanan mati, batasi user, 2FA bila perlu.
Uji dari luar dan pantau hasilnya.

Langkah 1: Buat Kunci Ed25519 dan Uji Sebelum Lanjut

Semua langkah berikut bertumpu pada satu syarat: kamu sudah bisa login tanpa password. Jadi kerjakan bagian ini lebih dulu, di komputer kamu:


ssh-keygen -t ed25519 -a 100 -C "laptop-utama"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@IP-VPS

Penjelasannya singkat: -t ed25519 memilih jenis kunci modern (lebih pendek dan lebih kuat daripada RSA), -a 100 memperbanyak putaran pengacakan untuk passphrase kunci, dan -C hanya memberi label komentar supaya kamu tahu kunci ini milik perangkat mana. Masukkan passphrase saat diminta — itu lapisan pengaman kalau file kunci di laptop ikut jatuh ke tangan orang lain.

Catatan penting soal versi: OpenSSH 10.0 (rilis April 2025) sudah menghapus dukungan algoritma tanda tangan DSA dan mematikan pertukaran kunci finite-field Diffie-Hellman di sisi server. Kalau VPS-mu memakai Ubuntu 26.04 LTS “Resolute Raccoon” (rilis April 2026), ia membawa OpenSSH 10.2. Artinya: kunci bertipe DSA sudah tidak bisa dipakai dan harus dibuat ulang, sedangkan ed25519 aman dipakai lintas versi.

Buka satu terminal baru dan pastikan login dengan kunci berhasil:


ssh -v user@IP-VPS 2>&1 | grep "Authenticated to"

Langkah 2: Matikan Login Password dan Root

Sekarang kunci sudah bekerja, saatnya menutup pintu tebak-tebakan. Jangan pernah mengedit /etc/ssh/sshd_config langsung — buat snippet agar perubahanmu tidak hilang saat paket diperbarui:


sudo nano /etc/ssh/sshd_config.d/99-hardening.conf


PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowAgentForwarding no

Kenapa snippet? Ubuntu menaruh baris Include /etc/ssh/sshd_config.d/*.conf di baris paling atas sshd_config, dan OpenSSH memakai nilai pertama yang ditemukan — jadi file di dalam folder sshd_config.d/ menang atas setelan di file utama.

PermitRootLogin no menutup login langsung sebagai root; pakai akun biasa lalu sudo.
PasswordAuthentication no dan KbdInteractiveAuthentication no mematikan login berbasis password sepenuhnya, termasuk lewat PAM.
MaxAuthTries 3 membatasi jumlah percobaan per koneksi, dan LoginGraceTime 30 memutus koneksi yang menggantung.

Sekarang bagian yang paling sering bikin orang frustrasi: **di Ubuntu 22.10 ke atas, sshd dijalankan lewat socket activation (unit ssh.socket), sehingga mengubah Port, ListenAddress, atau mengandalkan systemctl restart ssh saja tidak cukup**. Urutan yang benar:


sudo mkdir -p /run/sshd
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Perintah sshd -t menguji sintaks konfigurasi sebelum diterapkan. Di sistem dengan socket activation, folder /run/sshd kadang belum ada saat boot sehingga pengujian gagal dengan pesan Missing privilege separation directory — itu sebabnya kita buat foldernya lebih dulu. Setelah daemon-reload, perubahan Port/ListenAddress baru dibaca ulang oleh generator systemd (ini pernah dilaporkan sebagai bug Ubuntu dan sudah didokumentasikan resmi).

Aturan keselamatan: jangan tutup sesi SSH yang sedang terbuka. Buka terminal kedua, uji login, baru tutup yang lama. Kalau terkunci, pemulihannya harus lewat konsol/VNC dari panel provider, bukan lewat SSH.

Buktikan password benar-benar sudah mati:


ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@IP-VPS

Jawaban yang benar adalah Permission denied (publickey) — server menolak cara lama dan hanya menerima kunci.

Langkah 3: Tutup Semua Port dengan UFW

Pintu SSH sudah dikunci, tapi masih ada pintu lain yang berdiri terbuka tanpa penjaga. Di Ubuntu, UFW (Uncomplicated Firewall) secara bawaan belum aktif, jadi mari nyalakan dengan aturan deny by default:


sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Tiga catatan praktis:

sudo ufw app list menampilkan profil aplikasi yang tersedia (misalnya OpenSSH, Nginx Full). Pakai profil kalau kamu memakai port non-standar, supaya tidak salah izin.
Urutannya penting: izinkan OpenSSH lebih dulu, baru ufw enable. Kalau terbalik, kamu bisa langsung terkunci di luar server sendiri.
Kalau kamu memakai Docker, ketahui satu jebakan besarnya: container yang mem-publish port (-p 8080:80) menulis aturan iptables-nya sendiri di rantai FORWARD, bukan di rantai INPUT yang dikelola UFW. Akibatnya ufw deny 8080 bisa lapor sukses sementara port itu tetap terbuka ke internet. Dua penawarnya: publish hanya ke localhost (-p 127.0.0.1:8080:80) lalu biarkan Nginx yang menghadap publik, atau tulis aturan penapisan di rantai DOCKER-USER yang tidak pernah ditimpa Docker.

Kalau VPS-mu tersambung ke jaringan privat seperti Tailscale, batasi SSH hanya dari antarmuka itu — jauh lebih rapi daripada membuka port ke seluruh internet:


sudo ufw allow in on tailscale0

Langkah 4: Pasang fail2ban, Penjaga Pintu yang Menghitung Kesalahan

Firewall menutup pintu, tapi pintu SSH tetap harus terbuka. Di sinilah fail2ban bertugas: ia membaca log, lalu memblokir IP yang gagal berulang kali. Di Ubuntu 24.04 dan 26.04, paketnya sudah datang “setengah jadi” — file /etc/fail2ban/jail.d/defaults-debian.conf bawaan sudah menyetel banaction = nftables, backend = systemd, dan jail [sshd] dalam keadaan aktif.


sudo apt install fail2ban
sudo systemctl status fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Untuk menyetel kebijakan yang lebih tegas, jangan sentuh jail.conf (ia ditimpa saat paket di-upgrade). Buat override:


sudo nano /etc/fail2ban/jail.local


[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 103.0.0.10
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w

[sshd]
enabled = true
maxretry = 3

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log

[nginx-botsearch]
enabled = true
logpath = /var/log/nginx/access.log
maxretry = 2

Arti angka-angka di atas: maxretry = 3 berarti tiga kali gagal dalam findtime 10 menit, dan IP itu dikunci bantime satu jam. Dengan bantime.increment, pelanggar berulang dihukum dua kali lipat setiap kali, sampai maksimal satu minggu. Jangan lupa isi ignoreip dengan IP kantor/rumah dan IP monitor uptime — kalau tidak, alat monitoring sendiri yang kena ban. Dua jail terakhir menangkap serangan ke aplikasi web: percobaan autentikasi HTTP dan bot yang menyisir path seperti /.env atau /wp-admin.

Terapkan dan uji:


sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf
sudo fail2ban-client set sshd banip 203.0.113.5
sudo fail2ban-client set sshd unbanip 203.0.113.5

Kalau fail2ban-client status sshd mengeluh tidak bisa membaca journal, pastikan paket python3-systemd terpasang — backend systemd memerlukannya. Sebagai catatan versi: rilis resmi terbaru fail2ban di hulu adalah 1.1.0 (April 2024) dan itu pula yang dipakai Ubuntu 26.04, jadi paket dari apt sudah memadai.

Langkah 5: Biarkan Patch Keamanan Datang Sendiri

Server yang terkunci rapi tapi menunda patch keamanan tetap rapuh. Untungnya Ubuntu Server sudah menyertakan unattended-upgrades sejak instalasi:


systemctl status apt-daily-upgrade.timer
sudo unattended-upgrade --dry-run -d
cat /var/run/reboot-required

Timer apt-daily-upgrade.timer yang berstatus active berarti patch keamanan dipasang otomatis. Jalankan --dry-run untuk melihat paket apa yang akan dipasang tanpa benar-benar mengubah apa pun, dan cek /var/run/reboot-required — kalau file itu ada, ada pembaruan kernel yang perlu diikuti reboot. Reboot otomatis tidak dinyalakan secara bawaan, jadi jadwalkan sendiri di jam sepi.

Langkah 6: Kecilkan Permukaan Serangan

Semakin sedikit pintu, semakin sedikit hal yang harus dijaga:

Inventaris dulu, baru matikan. sudo ss -tulpn menampilkan semua port yang mendengarkan; matikan layanan yang tidak dipakai (sudo systemctl disable --now nama.service).
Batasi siapa yang boleh masuk. Tambahkan AllowUsers user1 user2 di snippet 99-hardening.conf supaya akun lain tidak bisa mencoba sama sekali.
Tambahkan 2FA bila perlu. Ubuntu menyediakan panduan resmi OpenSSH 2FA with TOTP/HOTP — cocok untuk VPS produksi yang dipegang banyak orang.
Pindah port SSH — opsional saja. Mengganti ke port lain hanya mengurangi noise di log, bukan menggantikan kunci dan fail2ban. Ingat konsekuensinya: setelah mengubahnya, wajib sudo systemctl daemon-reload lalu sudo systemctl restart ssh.socket, dan port baru harus diizinkan di UFW lebih dulu.

Langkah 7: Uji dari Luar dan Pantau

Sekarang buktikan hasilnya, dari komputer lain (bukan dari VPS-nya sendiri):


ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@IP-VPS
nmap -Pn -p 22,80,443 IP-VPS
sudo fail2ban-client status sshd
sudo ufw status numbered
sudo journalctl -u ssh --since "1 hour ago" | tail -20

Yang diharapkan: password ditolak, nmap hanya melaporkan port yang sengaja dibuka, Total banned di fail2ban bertambah seiring bot terus mengetuk, dan tidak ada percobaan login yang berhasil. Jadikan pemeriksaan singkat ini kebiasaan mingguan.

Kesalahan yang Sering Bikin Terkunci

Menutup sesi lama sebelum sesi uji berhasil. Selalu uji di terminal kedua.
**sshd -t gagal dengan Missing privilege separation directory.** Buat /run/sshd lebih dulu; normal pada sistem dengan socket activation.
Port tidak berubah setelah systemctl restart ssh. Di Ubuntu 22.10+ perlu systemctl daemon-reload lalu systemctl restart ssh.socket.
Menyalakan UFW sebelum mengizinkan OpenSSH. Satu perintah terbalik, terkunci.
Lupa ignoreip. IP sendiri atau IP monitor uptime ikut diblokir.
fail2ban gagal start di dalam container yang tidak punya systemd/journal — backend systemd butuh journal; mode container sebaiknya pakai backend = auto.
Mengandalkan Cloudflare untuk melindungi SSH. Cloudflare hanya mem-proxy lalu lintas HTTP/HTTPS di port 80 dan 443; port 22 tidak dilindungi oleh WAF-nya.

Kesimpulan

Dengan tujuh langkah tadi, cara amankan SSH VPS berubah dari pekerjaan menakutkan menjadi rutinitas 30 menit: kunci ed25519 menggantikan password, sshd_config.d/99-hardening.conf mematikan root dan tebak-tebakan, UFW menutup pintu lain, fail2ban memblokir penebak otomatis, dan patch keamanan masuk tanpa kamu ingat. Bot boleh terus mengetuk — pintunya sudah tidak punya kenop yang bisa diputar.

Sobat Online, jangan tunggu ada kejadian buruk untuk mulai. Malam ini, pasang kuncimu, uji di terminal kedua, lalu jalankan fail2ban-client status sshd besok pagi untuk melihat sendiri berapa IP yang sudah tertangkap. Selamat mengunci pintu, dan semoga log-mu selalu berisi kabar aman! 🔐