Bayangkan Anda baru saja selesai men-deploy sebuah server untuk aplikasi produksi. Semua service sudah berjalan mulus, database sudah terkoneksi, dan aplikasi bisa diakses publik. Tapi ada satu hal yang sering luput dari perhatian banyak sysadmin pemula: keamanan akses SSH.
Padahal, SSH (Secure Shell) adalah pintu masuk utama menuju server Anda. Jika pintu ini tidak dikunci dengan benar, siapa pun di luar sana bisa mencoba masuk kapan saja — dan mereka memang mencobanya, bahkan tanpa henti.
Coba cek log /var/log/auth.log atau /var/log/secure di server Anda yang terhubung ke internet. Kemungkinan besar Anda akan menemukan ratusan hingga ribuan percobaan login yang gagal, datang dari berbagai negara, dalam hitungan jam saja. Ini bukan serangan yang ditargetkan secara khusus ke server Anda — ini adalah bot otomatis yang menyisir seluruh internet, mencari server dengan konfigurasi SSH default yang lemah.
Berita baiknya, mengamankan SSH tidak memerlukan biaya tambahan atau tools mahal. Cukup dengan lima langkah konfigurasi yang tepat, tingkat risiko brute force pada server Anda bisa ditekan secara drastis. Artikel ini akan membahas kelima langkah tersebut secara detail, disertai contoh konfigurasi nyata yang bisa langsung Anda terapkan.
Mengapa SSH Sering Jadi Target Serangan?
SSH berjalan pada port 22 secara default di hampir semua distribusi Linux — Ubuntu, Debian, CentOS, Rocky Linux, hingga RHEL. Karena port ini sudah menjadi “pengetahuan umum”, para penyerang cukup melakukan port scanning massal untuk menemukan server yang membuka port tersebut ke publik.
Setelah menemukan target, mereka menjalankan skrip otomatis yang mencoba ribuan kombinasi username dan password secara berulang — teknik ini disebut brute force attack. Jika server menggunakan password yang lemah, atau bahkan masih memakai kredensial default, risiko server dibobol menjadi sangat tinggi.
Analoginya seperti rumah dengan pintu depan yang terkenal di seluruh kompleks. Semua orang tahu di mana pintunya, jam berapa biasanya dibuka, dan jenis kunci apa yang dipakai. Maling tidak perlu mencari-cari lagi — mereka tinggal fokus mencoba berbagai kunci sampai salah satu cocok.
Dengan memahami pola serangan ini, kita bisa menyusun strategi pertahanan berlapis atau yang dikenal dengan istilah defense in depth — di mana setiap lapisan keamanan mempersulit penyerang, meskipun satu lapisan berhasil ditembus.
Pembahasan Utama: 5 Langkah Konfigurasi SSH yang Aman
Langkah 1: Mengganti Port Default SSH
Port 22 adalah port yang paling sering di-scan oleh bot serangan otomatis. Mengganti port default ke angka lain (misalnya 2222, 22022, atau angka acak lainnya) tidak membuat server 100% aman, tetapi secara signifikan mengurangi jumlah percobaan serangan otomatis yang menyasar server Anda — teknik ini sering disebut security through obscurity.
Cara konfigurasi:
Edit file konfigurasi SSH:
sudo nano /etc/ssh/sshd_config
Cari baris berikut dan ubah:
Port 22
menjadi:
Port 2222
Simpan file, lalu restart layanan SSH:
sudo systemctl restart sshd
Penting: Sebelum memutuskan koneksi SSH yang sedang aktif, pastikan Anda membuka koneksi SSH baru terlebih dahulu menggunakan port baru untuk memastikan konfigurasi berhasil. Jangan lupa juga membuka port baru tersebut di firewall (UFW, firewalld, atau iptables) dan security group jika menggunakan cloud provider seperti AWS, GCP, atau Azure.
Langkah 2: Menonaktifkan Login Langsung Sebagai Root
User root adalah akun dengan hak akses tertinggi di sistem Linux. Jika penyerang berhasil menebak password root, mereka mendapatkan kendali penuh atas server. Karena itu, praktik terbaik adalah menonaktifkan login SSH langsung sebagai root, dan mewajibkan penggunaan user biasa yang kemudian melakukan eskalasi hak akses menggunakan sudo.
Cara konfigurasi:
Buat terlebih dahulu user baru jika belum ada:
sudo adduser namauser
sudo usermod -aG sudo namauser
Edit konfigurasi SSH:
sudo nano /etc/ssh/sshd_config
Cari baris:
PermitRootLogin yes
Ubah menjadi:
PermitRootLogin no
Restart layanan SSH:
sudo systemctl restart sshd
Dengan begitu, walaupun password root bocor, penyerang tetap tidak bisa login langsung sebagai root melalui SSH.
Langkah 3: Menggunakan Autentikasi Berbasis SSH Key
Password, betapa pun rumitnya, tetap rentan terhadap brute force dan phishing. SSH Key menggunakan pasangan kunci kriptografi (public key dan private key) yang jauh lebih sulit ditebak dibandingkan kombinasi karakter password biasa.
Cara konfigurasi:
Generate SSH key di komputer lokal Anda (bukan di server):
ssh-keygen -t ed25519 -C "email@contoh.com"
Salin public key ke server:
ssh-copy-id -p 2222 namauser@ip-server
Setelah berhasil login menggunakan key, nonaktifkan autentikasi password di server:
sudo nano /etc/ssh/sshd_config
Ubah baris berikut:
PasswordAuthentication no
PubkeyAuthentication yes
Restart SSH:
sudo systemctl restart sshd
Tips penting: Selalu simpan private key di tempat yang aman, jangan pernah dibagikan, dan gunakan passphrase tambahan saat generate key untuk lapisan keamanan ekstra.
Langkah 4: Mengaktifkan Fail2Ban untuk Memblokir Percobaan Login Berulang
Fail2Ban adalah tool yang memantau log autentikasi dan secara otomatis memblokir alamat IP yang melakukan percobaan login gagal secara berulang dalam periode waktu tertentu.
Instalasi di Ubuntu/Debian:
sudo apt update
sudo apt install fail2ban -y
Instalasi di CentOS/Rocky Linux/RHEL:
sudo dnf install epel-release -y
sudo dnf install fail2ban -y
Buat file konfigurasi lokal agar tidak menimpa file default:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Cari bagian [sshd] dan sesuaikan:
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
Konfigurasi di atas berarti: jika ada 5 kali percobaan login gagal dalam 10 menit, IP tersebut akan diblokir selama 1 jam.
Aktifkan dan jalankan Fail2Ban:
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
Cek status pemblokiran:
sudo fail2ban-client status sshd
Langkah 5: Membatasi Akses SSH Hanya dari IP yang Diizinkan
Langkah paling kuat dari semuanya adalah membatasi akses SSH hanya dari IP tertentu — misalnya IP kantor, IP rumah, atau VPN perusahaan. Dengan begitu, meskipun port SSH terbuka, hanya sumber IP tertentu yang bisa mencoba melakukan koneksi sama sekali.
Menggunakan UFW (Ubuntu):
sudo ufw allow from 103.xx.xx.xx to any port 2222
sudo ufw deny 2222
Menggunakan firewalld (CentOS/Rocky Linux):
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="103.xx.xx.xx" port protocol="tcp" port="2222" accept'
sudo firewall-cmd --reload
Menggunakan Security Group (Cloud Provider):
Jika server berada di AWS, GCP, atau Azure, atur inbound rule pada security group agar port SSH hanya menerima koneksi dari IP statis Anda, bukan dari 0.0.0.0/0 (semua IP).
Studi Kasus Sederhana
Sebuah tim developer men-deploy VPS baru untuk staging environment tanpa mengubah konfigurasi default SSH. Dalam waktu kurang dari 24 jam, log menunjukkan lebih dari 3.000 percobaan login gagal dari berbagai IP asing. Untungnya, password root yang digunakan cukup kuat sehingga serangan gagal.
Setelah kejadian ini, tim menerapkan kelima langkah di atas. Hasilnya, dalam sebulan berikutnya, jumlah percobaan login yang tercatat turun drastis karena port sudah diganti, dan sebagian besar bot otomatis langsung diblokir Fail2Ban pada percobaan pertama sebelum sempat melakukan brute force lebih lanjut.
Kesalahan yang Sering Terjadi
1. Lupa membuka port baru di firewall setelah mengganti port SSH Penyebab: Fokus mengubah sshd_config tapi lupa update firewall. Dampak: Server menjadi tidak bisa diakses sama sekali (locked out). Solusi: Selalu test koneksi baru sebelum menutup sesi lama, dan pastikan firewall/security group sudah mengizinkan port baru.
2. Menonaktifkan password authentication sebelum SSH key benar-benar berhasil login Penyebab: Terburu-buru menerapkan best practice tanpa verifikasi. Dampak: Admin terkunci total dari server jika key bermasalah. Solusi: Selalu buka sesi SSH kedua menggunakan key terlebih dahulu, baru nonaktifkan password authentication di sesi pertama.
3. Menggunakan bantime terlalu singkat di Fail2Ban Penyebab: Konfigurasi default tidak disesuaikan. Dampak: IP penyerang cepat kembali mencoba setelah blokir berakhir. Solusi: Sesuaikan bantime menjadi lebih lama (misalnya 24 jam) untuk serangan berulang, atau gunakan bantime.increment untuk penalti progresif.
4. Tidak melakukan backup konfigurasi sebelum melakukan perubahan Penyebab: Merasa perubahan kecil dan sepele. Dampak: Sulit rollback jika terjadi kesalahan konfigurasi. Solusi: Selalu backup file dengan sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sebelum mengedit.
5. Whitelist IP statis yang ternyata dinamis Penyebab: Menganggap IP rumah/kantor selalu sama. Dampak: Admin ter-lockout ketika ISP mengganti IP. Solusi: Gunakan VPN dengan IP tetap, atau kombinasikan dengan metode autentikasi lain sebagai jalur darurat.
Tips dan Rekomendasi Tambahan
- Gunakan
AllowUsers namauserdisshd_configuntuk membatasi user mana saja yang boleh login via SSH. - Aktifkan two-factor authentication (2FA) menggunakan Google Authenticator PAM module untuk lapisan keamanan tambahan.
- Nonaktifkan
X11Forwardingjika tidak diperlukan untuk mengurangi permukaan serangan. - Monitor log secara berkala menggunakan tools seperti
logwatchatau integrasikan dengan sistem monitoring seperti Grafana + Loki. - Selalu update sistem dan paket OpenSSH secara rutin untuk menutup celah keamanan yang baru ditemukan.
- Pertimbangkan penggunaan VPN atau Bastion Host sebagai gerbang tunggal menuju seluruh server produksi, sehingga port SSH server utama tidak perlu terbuka ke publik sama sekali.
Kesimpulan
Mengamankan SSH bukanlah proses satu langkah, melainkan kombinasi beberapa lapisan pertahanan yang saling melengkapi. Kelima langkah yang telah dibahas — mengganti port default, menonaktifkan login root, menggunakan SSH Key, mengaktifkan Fail2Ban, dan membatasi akses berdasarkan IP — merupakan fondasi dasar yang wajib diterapkan pada setiap server produksi.
Perlu diingat, tidak ada konfigurasi yang membuat server 100% aman. Namun dengan menerapkan prinsip defense in depth, setiap lapisan keamanan akan mempersulit penyerang, memperkecil risiko, dan memberi waktu lebih bagi Anda untuk mendeteksi serta merespons ancaman sebelum kerusakan terjadi.
Keamanan server bukan proyek yang selesai sekali dikerjakan, melainkan proses berkelanjutan yang perlu terus dipantau dan diperbarui seiring berkembangnya ancaman siber.
Frequently Asked Questions (FAQ)
Pertanyaan: Apakah mengganti port SSH default benar-benar efektif mencegah serangan? Jawaban: Mengganti port tidak membuat server sepenuhnya aman, tetapi sangat efektif mengurangi jumlah serangan otomatis dari bot yang hanya menyasar port 22, sehingga log server menjadi lebih bersih dan mudah dipantau.
Pertanyaan: Apakah aman menonaktifkan password authentication sepenuhnya? Jawaban: Ya, selama Anda sudah memastikan SSH Key berhasil digunakan untuk login terlebih dahulu. Selalu uji koneksi baru sebelum menutup sesi lama untuk menghindari terkunci dari server.
Pertanyaan: Bagaimana jika saya perlu login SSH dari IP yang berubah-ubah? Jawaban: Gunakan VPN dengan IP statis, atau kombinasikan Fail2Ban dan SSH Key sebagai lapisan keamanan utama alih-alih hanya mengandalkan whitelist IP.
Pertanyaan: Apakah Fail2Ban bisa memblokir IP secara permanen? Jawaban: Secara default tidak, Fail2Ban memblokir sementara sesuai bantime yang diatur. Namun Anda bisa mengonfigurasi bantime.increment agar durasi blokir bertambah setiap kali IP yang sama mengulangi pelanggaran.
Pertanyaan: Apakah langkah-langkah ini cukup untuk server produksi skala besar? Jawaban: Kelima langkah ini adalah fondasi dasar yang wajib ada. Untuk skala besar, sebaiknya ditambahkan lapisan keamanan lain seperti bastion host, 2FA, monitoring terpusat, dan audit keamanan berkala.
Sudah menerapkan kelima langkah keamanan SSH di atas pada server Anda? Yuk share pengalaman Anda di kolom komentar — apakah pernah mengalami percobaan brute force di server sendiri?
Jangan lupa bagikan artikel ini ke rekan sysadmin atau developer lain yang mungkin masih menggunakan konfigurasi SSH default. Ikuti terus konten seputar Linux, DevOps, dan Cybersecurity di blog ini, dan jangan lewatkan artikel-artikel terkait lainnya seputar server hardening dan infrastruktur IT.
