Hardening SSH Server: 7 Langkah Wajib Amankan Akses 2026

Tolong ya, berhenti biarin SSH server kalian kebuka gitu-gitu aja. Aku udah handle kasus server kebobol lewat SSH berkali-kali, dan tiap kali tetep bikin gemes. Padahal hardening SSH linux server yang bener cuma butuh waktu sekitar 30 menit, dan hasilnya beda banget. Nek dipikir-pikir, kok ya masih banyak yang naif soal ini.

Bener-bener deh, kasus yang paling sering aku temuin di lapangan itu bukan exploit 0-day atau malware canggih. Gak. Yang paling umum justru yang itu-itu aja: port 22 kebuka, root login aktif, password lemah. Bot dari mana-mana nyoba brute force terus-terusan, dan begitu password ketebak, beres deh server kalian.

Masalahnya bukan cuma server down atau website error. Dampak-e iso nggawe revenue loss, data penting kebobol, client pada kabur, dan nek iki production environment, sampeyan bisa dapet surat cinta dari management atau bahkan klaim dari client gara-gara data bocor. Satu akses SSH yang bocor itu bisa jadi pintu masuk attacker buat nyusup ke seluruh infrastruktur — database, config file, kredensial, API keys, semuanya. Iki serius, bukan main-main.

Symptoms-nya gampang dikenali, kok. Log autentikasi biasanya nunjukin pola yang jelas: baris “Failed password for invalid user” berjejer dari IP yang beda-beda, kadang ratusan percobaan dalam semenit. Nah, nek wis ketok ngono, jangan diem aja — itu udah alarm pertama kalau server kalian lagi di-bruteforce.

sudo tail -n 100 /var/log/auth.log
sudo journalctl -u ssh --since "1 hour ago" | grep -i failed

Penyebabnya hampir selalu sama, dan ini yang bikin aku gemes. Pertama, root login masih enabled, jadi bot cuma butuh nebak password root — padahal root itu nama yang udah pasti ada, gak perlu ditebak. Kedua, password authentication masih nyala, padahal password manusia itu lemah dan gampang kena phishing atau keyboard-logging. Ketiga, port default 22 dibiarin polos tanpa tameng firewall. Keempat, gak ada fail2ban yang ngeban IP nakal. Kelima, user SSH gak pernah dibersihin — yang udah gak dipake tetep aktif. Keenam, masih banyak yang pake SSH key RSA 1024 yang udah usang. Kombinasi dari semua itu, dan kalian cuma nontonin server dibobol dari kursi. Fix-nya? Baca terus.

Oh iya, sebelum lanjut ke langkah-langkah, ini penting banget: pastikan kalian punya akses lain ke server selain SSH, misalnya console VPS dari panel penyedia hosting kalian atau out-of-band management. Jangan pernah ngunci akses satu-satunya. Sopo ngerti, nek sampeyan lock out, minta bantuan provider emang bisa, tapi itu nggawe malu dan buang-buang waktu.

Kenapa Hardening SSH Linux Server Itu Wajib Sebelum Production

Biar kalian paham kenapa ini bukan saran receh: SSH itu satu-satunya gerbang administrasi utama di server Linux. Semua orang yang akses server — entah lewat terminal, SFTP buat upload file, sampai Git deploy — pasti lewat SSH. Artinya, kalau gerbang ini bolong, semua yang ada di belakangnya jadi taruhan. Hardening SSH linux server bukan sekadar bikin repot attacker, tapi ngecilin attack surface dan mastiin kalau ada yang salah, impact-nya minimal.

Prinsip dasarnya simpel: hanya izinin apa yang dibutuhin, matiin yang gak dipake, dan catat semua yang masuk. Mirip kayak ngunci rumah — gak perlu rumahnya kedap kayak bunker, cukup kuncinya bagus, jendela yang gak kepake dirapatin, dan ada cctv yang nge-record kalau ada orang asing lewat. Nah, hardening SSH itu kerjanya gitu.

Step 1: Backup Konfigurasi SSH Sebelum Ngubah Apa Pun

Ini langkah yang paling sering aku skip pas awal-awal dulu, dan percaya deh, gak enak rasanya pas SSH gak bisa connect dan gak punya backup config asli. Command-nya singkat:

sudo cp -a /etc/ssh /etc/ssh.bak.$(date +%F)
ls -la /etc/ssh.bak.*

Simpen juga backup di tempat lain — misalnya scp ke workstation kalian. Karena kalau server-nya bener-bener kena, config backup di dalam server yang sama bisa ikut hilang. Paranoia? Mungkin. Tapi produksi gak pernah nolak paranoid.

Step 2: Generate SSH Key ed25519 dan Aktifkan Key-Based Auth

Langkah paling nentuin: pindah dari password ke SSH key. Password bisa ditebak, dipaksa, dipancing. SSH key gak — selama private key-nya gak bocor dan passphrase-nya kuat. Aku rekomendasikan ed25519 karena lebih cepet, lebih kecil, dan dianggap lebih aman daripada RSA 2048.

Generate di komputer kalian sendiri (bukan di server, biar private key gak pernah ninggalin device kalian):

ssh-keygen -t ed25519 -a 100 -C "admin@workstation"

Terus salin public key ke server. Bisa pakai ssh-copy-id selama password masih aktif:

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

Kalau gak punya ssh-copy-id (macOS atau Windows lama), tempel manual ke ~/.ssh/authorized_keys di server. Setelah itu, test login dari terminal baru pake key-nya. Kalau udah masuk, baru lanjut ke step berikutnya. Ini urutannya penting — jangan matiin password sebelum key-nya kebukti jalan.

Step 3: Matikan Root Login dan Password Authentication

Edit file konfigurasi SSH server:

sudo nano /etc/ssh/sshd_config

Pastikan baris-baris ini seperti berikut:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
KbdInteractiveAuthentication no

Setelah itu, validasi config-nya dulu sebelum reload — ini penyelamat hidup:

sudo sshd -t
sudo systemctl reload ssh

Kalau sshd -t gak ngasih error, berarti config aman. Tapi jangan langsung tutup session kalian yang sekarang. Buka terminal baru, coba login lagi pake key. Nek iso mlebu, baru deh aman. Ini step yang kalau dilewatin bisa bikin kalian lock out total.

Step 4: Ganti Port Default dan Amankan dengan Firewall

Ganti port 22 ke port acak seperti 22022, 42022, atau yang lain. Jangan salah paham: ini bukan tameng utama — attacker yang niat tetep bakal nge-scan. Tapi ini nge-filter 99% noise bot yang cuma nge-scan port 22. Lumayan banget buat ngurangin log spam dan beban CPU.

Di sshd_config, ubah:

Port 22022

Reload lagi, terus atur firewall. Kalau pakai UFW (Ubuntu/Debian):

sudo ufw allow 22022/tcp
sudo ufw delete allow 22/tcp
sudo ufw enable
sudo ufw status

Kalau pakai RHEL/CentOS, ganti dengan firewalld: sudo firewall-cmd –permanent –add-port=22022/tcp, remove port 22, lalu reload. Dan pastikan update config client plus port forward di router atau load balancer kalau ada.

Step 5: Batasi User yang Boleh Masuk SSH

Selanjutnya, limit siapa aja yang punya hak login SSH. Jangan biarin semua user masuk. Buat grup khusus, atau langsung sebut user-nya satu-satu.

sudo groupadd sshusers
sudo usermod -aG sshusers admin
sudo usermod -aG sshusers deploy

Di sshd_config tambahkan:

AllowGroups sshusers
DenyUsers root

Dengan begitu, user yang gak masuk grup sshusers gak bakal bisa login SSH sama sekali, mau dia punya password bener sekalipun. Lapisan ekstra yang murah dan efektif.

Step 6: Pasang fail2ban untuk Auto-Ban IP Nakal

fail2ban itu kayak satpam yang otomatis ngusir orang yang mentok-meletok di depan pintu. Kalau ada IP yang gagal login berkali-kali, fail2ban bakal ngeban-nya otomatis lewat firewall. Aku udah bahas lengkap soal ini di artikel panduan lengkap fail2ban, tapi intinya gini:

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

Edit /etc/fail2ban/jail.local dan pastikan jail sshd aktif:

[sshd]
enabled = true
port = 22022
maxretry = 5
bantime = 3600

Lalu aktifkan:

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

Nek wis jalan, kalian bakal liat jumlah banned IP yang naek. Dan log auth kalian jadi jauh lebih bersih. Ini salah satu upgrade paling kerasa yang bisa kalian lakuin — selain tentu saja dipasang bareng sama firewall yang bener.

Step 7: Perketat Session dan Limit Percobaan Login

Terakhir, atur session biar gak dibiarin menggantung selamanya dan percobaan login dibatesin. Tambahkan baris-baris ini ke sshd_config:

MaxAuthTries 3
MaxStartups 10:30:60
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 0
X11Forwarding no

Penjelasan singkat: MaxAuthTries 3 ngelimit percobaan password per koneksi, MaxStartups ngebatesin koneksi bersamaan yang belum terautentikasi biar gak gampang kena resource exhaustion, LoginGraceTime 60 detik ngasih deadline buat login, ClientAliveInterval plus ClientAliveCountMax 0 bakal nutup otomatis session yang idle lebih dari 5 menit, dan X11Forwarding no matiin fitur yang jarang dipake tapi bisa jadi lubang. Lengkap.

Troubleshooting: Error Umum Saat Hardening SSH

Gak semua berjalan mulus, dan gak apa-apa. Ini tabel error yang paling sering muncul, biar kalian gak panik pas pertama kali ngeliatnya.

Kalau ada error di luar tabel ini, langkah paling masuk akal: buka backup config, jalanin sudo sshd -t, dan bandingin. Selalu kembalikan ke kondisi yang paling terakhir kebukti jalan. Nek isih angel, bisa coba artikel aku soal mengamankan VPS dengan UFW buat ngelengkapin firewall-nya.

FAQ Seputar Hardening SSH Linux Server

Satu lagi: kalau kalian masih nyari cara ngatur user dan akses dengan rapi, mampir ke artikel best practice manajemen user Linux. Dan buat server yang udah jalan, cek juga cara monitoring log server biar serangan berikutnya ketangkep lebih awal.

Tolong ya, jangan jadiin artikel ini cuma jadi bookmark yang gak pernah dibuka lagi. Satu server yang kebobol itu bisa nyeret reputasi kalian, data client, dan waktu berjam-jam buat bersihin sisa-sisa serangan. Lakuin langkah-langkah di atas, mulai dari yang paling gampang, dan rasain bedanya. Take it seriously — server kalian yang nanggung kalau kalian cuek.