Cara Memperkuat SSH di VPS dengan Aman

Mengapa SSH menjadi hal pertama yang harus diperkuat

SSH digunakan untuk mengendalikan server. Karena itu, SSH menjadi titik akses pertama yang dicoba oleh penyerang. Segera setelah VPS online, pemindai mulai menebak nama pengguna dan kata sandi pada port 22. Anda dapat memantau aktivitas ini di log dalam hitungan menit. Memperkuat SSH berarti menghapus hal-hal yang dapat ditebak penyerang: nonaktifkan login dengan kata sandi sepenuhnya, nonaktifkan login root, dan izinkan hanya kunci kriptografis. Setelah itu, upaya penebakan terus-menerus tidak akan berhasil karena tidak ada kata sandi yang dapat ditemukan.

Panduan ini mengasumsikan SSH sudah berfungsi. Jika Anda dapat login, Anda dapat memperkuat konfigurasinya. Lakukan langkah-langkah secara berurutan dan biarkan sesi saat ini tetap terbuka sampai sesi baru berhasil digunakan. Dengan demikian, kesalahan konfigurasi tidak akan mengunci Anda dari server.

Langkah 1: Pastikan autentikasi berbasis key berfungsi terlebih dahulu

Autentikasi berbasis key menggantikan password dengan pasangan key: private key yang tetap berada di komputer Anda dan public key yang Anda pasang di server. Server membuktikan bahwa Anda memiliki private key tanpa pernah memindahkannya dari komputer Anda. Sebelum menonaktifkan password, pastikan key berfungsi. Jika tidak, Anda dapat terkunci dari server.

Di komputer Anda sendiri, buat key jika belum memilikinya:

ssh-keygen -t ed25519

Salin bagian public key ke server:

ssh-copy-id user@your-server

Kemudian buka sesi SSH baru. Jika Anda dapat masuk tanpa diminta password, berarti key berfungsi dan Anda aman untuk menonaktifkan password. Jika proses berhenti dengan Permission denied (publickey), error tersebut dapat menyembunyikan lima masalah yang berbeda, dan output ssh -v memberi tahu masalah yang terjadi sebelum Anda mengubah hal lain. Jika key masih baru bagi Anda atau Anda menggunakan lebih dari satu komputer, dasar-dasar pengelolaan SSH key menjelaskan model lengkapnya: satu key untuk setiap perangkat, permission yang diwajibkan sshd, dan cara mencabut key ketika laptop hilang.

Langkah 2: Perkuat sshd dengan file drop-in

Jangan mengedit /etc/ssh/sshd_config secara langsung. Ubuntu 24.04 membaca file drop-in dari /etc/ssh/sshd_config.d/. File kecil di sana lebih rapi, tetap berlaku setelah peningkatan paket, dan mudah dihapus jika terjadi masalah. Nama file penting: sshd mempertahankan nilai pertama yang dibacanya untuk setiap pengaturan. Image cloud Ubuntu menyertakan 50-cloud-init.conf dengan PasswordAuthentication yes di direktori ini. Beri nama file Anda 00- agar diurutkan sebelum file tersebut dan menjadi nilai yang digunakan. File 99- akan kalah secara diam-diam. Buat file tersebut:

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

Masukkan konfigurasi berikut:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Setiap baris menutup satu celah. PasswordAuthentication no adalah pengaturan utama: jika autentikasi dengan kata sandi dinonaktifkan, serangan brute-force tidak memiliki kata sandi untuk dicoba. KbdInteractiveAuthentication no menutup jalur lain yang menggunakan kata sandi. PermitRootLogin no berarti penyerang harus mengetahui nama pengguna dan memiliki key Anda. Penyerang tidak cukup hanya menargetkan satu akun, yaitu root, yang ada di setiap server.

Langkah 3: Uji konfigurasi, lalu muat ulang

Periksa konfigurasi untuk menemukan kesalahan sebelum menerapkannya. Dengan demikian, salah ketik tidak akan membuat service gagal:

sudo sshd -t

Jika tidak menampilkan apa pun, konfigurasi valid. Muat ulang SSH:

sudo systemctl reload ssh

Kemudian periksa pengaturan yang benar-benar digunakan sshd. Dengan demikian, Anda dapat mengetahui jika drop-in dikalahkan oleh file lain:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Keduanya harus menampilkan no. Sekarang, tanpa menutup sesi saat ini, buka sesi baru dari terminal lain. Jika Anda dapat login menggunakan key, berarti proses selesai. Jika ada masalah, sesi pertama masih terbuka untuk melakukan perbaikan. Sesi yang tetap terbuka ini adalah pengaman, jadi jangan pernah melewatinya.

Langkah 4: Port nonstandar opsional

Memindahkan SSH dari port 22 ke port seperti 2222 tidak membuatnya lebih aman dalam arti yang sebenarnya, karena penyerang yang gigih akan memindai semua port. Perubahan ini hanya mengurangi kebisingan pada log, karena sebagian besar pemindai otomatis hanya mencoba port 22. Jika ingin menggunakannya, tambahkan Port 2222 ke file drop-in, izinkan port baru tersebut di firewall terlebih dahulu, lalu jalankan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket dan sambungkan dengan ssh -p 2222. Pada Ubuntu 24.04, ssh.socket mengelola port yang sedang listening, sehingga reload ssh biasa tetap membuat sshd menggunakan port 22; socket harus di-restart agar port baru diterapkan. Perlakukan perubahan ini sebagai kerapian konfigurasi, bukan perlindungan.

Langkah 5: Tambahkan lapisan pertahanan berikutnya

SSH key yang diperkuat menjadi fondasi, lalu dua lapisan tambahan dapat diterapkan di atasnya.

Fail2ban memantau log dan memblokir alamat yang terus mengalami kegagalan. Dengan demikian, gangguan dari pemindai berkurang dan alamat tersebut dapat dikeluarkan lebih awal. Fail2ban cocok digunakan bersama autentikasi yang hanya mengizinkan key: lihat Fail2ban di Ubuntu untuk menghentikan serangan SSH.

Perlindungan yang lebih kuat adalah menonaktifkan akses SSH dari Internet publik sepenuhnya. Jika Anda menempatkan SSH di balik VPN WireGuard dan membatasi port 22 ke tunnel tersebut melalui firewall, pihak di luar VPN bahkan tidak dapat menjangkaunya. Dengan demikian, upaya menebak secara brute force menjadi mustahil, bukan sekadar lebih sulit. Semua ini mengasumsikan adanya firewall dengan kebijakan default-deny di bawahnya, yang dijelaskan dalam menyiapkan UFW pada VPS.

SSH hanyalah satu bagian dari checklist yang lebih besar: 10 menit pertama pada VPS baru mengurutkan langkah-langkahnya, sedangkan pembaruan keamanan otomatis di Ubuntu menjaga server tetap mendapatkan patch setelahnya. Mengunci akses SSH tidak melindungi service di baliknya. Jadi, jika VPS yang sama menjalankan password vault, melakukan hardening pada Vaultwarden mencakup dua hal yang tidak pernah disentuh oleh autentikasi berbasis key: admin token dan file backup-nya.

FAQ

Bagaimana cara menonaktifkan login berbasis kata sandi untuk SSH di Ubuntu 24.04?

Buat file drop-in di /etc/ssh/sshd_config.d/00-hardening.conf. Awalan 00 membuat file tersebut diurutkan sebelum 50-cloud-init.conf. Nilai PasswordAuthentication yes dalam file itu jika tidak demikian akan berlaku karena sshd mempertahankan nilai pertama yang dibacanya. Isi file dengan PasswordAuthentication no dan KbdInteractiveAuthentication no. Jalankan sudo sshd -t untuk memeriksa konfigurasinya, lalu jalankan sudo systemctl reload ssh. Pastikan login dengan key berfungsi dalam sesi baru sebelum mengandalkannya. Mengedit drop-in, bukan sshd_config, membuat perubahan tetap bertahan setelah upgrade paket dan mudah dibatalkan.

Haruskah saya menonaktifkan login root melalui SSH?

Ya. Atur PermitRootLogin no agar tidak ada yang dapat login langsung sebagai root. Login sebagai pengguna biasa, lalu gunakan sudo untuk tugas administrasi. root ada di setiap sistem Linux, sehingga membiarkannya dapat diakses memberi penyerang nama pengguna yang sudah diketahui untuk ditargetkan. Menonaktifkannya berarti penyerang harus mengetahui nama akun Anda dan memiliki key Anda.

Apakah mengganti port SSH membuat server saya lebih aman?

Tidak secara berarti. Memindahkan SSH dari port 22 membuat Anda tidak terlihat oleh scanner sederhana yang hanya memeriksa port 22, sehingga mengurangi kebisingan pada log. Namun, penyerang yang sebenarnya akan memindai semua port dan tetap menemukannya. Autentikasi yang hanya menggunakan key adalah langkah yang benar-benar mencegah pembobolan. Jika Anda mengganti port, buka port baru pada firewall terlebih dahulu, lalu jalankan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. Pada Ubuntu 24.04, socket mengelola listener, dan reload biasa membuat sshd tetap menggunakan port 22.

Apakah saya memerlukan Fail2ban jika menggunakan SSH key?

Fail2ban bersifat opsional, tetapi tetap berguna. Dengan autentikasi yang hanya menggunakan key, upaya menebak kata sandi tidak akan berhasil, sehingga Fail2ban bukan komponen yang mencegah penyerang masuk. Fail2ban membatasi laju kegagalan berulang dari satu alamat. Ini mengurangi kebisingan scanner dalam log dan mengeluarkan pelaku berulang lebih awal. Namun, serangan lambat yang terdistribusi tetap dapat berada di bawah ambang pemblokirannya. Jalankan Fail2ban di atas autentikasi berbasis key, dan sebaiknya tempatkan SSH di belakang VPN.

Bagaimana cara memulihkan akses jika saya terkunci dari SSH?

Gunakan konsol web dari provider Anda. Konsol ini mengakses server melalui koneksi serial atau VNC yang tidak melewati SSH. Dari sana, Anda dapat login, memperbaiki file drop-in sshd, dan me-reload service. Inilah alasan Anda harus menguji konfigurasi SSH baru di terminal kedua sebelum menutup sesi pertama. Autentikasi berbasis key juga harus sudah berfungsi sebelum Anda menonaktifkan kata sandi.