Batasi upaya memasukkan kata sandi di Linux untuk mengamankan SSH dan layanan.

  • Analisis log otentikasi dan sesuaikan sshd_config untuk membatasi pengguna, port, protokol, dan upaya akses, sehingga mengurangi potensi serangan.
  • Gunakan Fail2ban untuk memantau layanan-layanan penting (SSH, web, basis data) dan secara otomatis memblokir IP yang sering mengalami kegagalan.
  • Gunakan kunci SSH sebagai pengganti kata sandi dan nonaktifkan PasswordAuthentication untuk menetralisir sepenuhnya serangan brute-force.
  • Perkuat dengan firewall, TCP wrapper, dan, jika perlu, 2FA, dengan menggabungkan beberapa lapisan pertahanan untuk melindungi server Linux Anda yang rentan.
Lorena Figueredo

17 menit

Batasi upaya memasukkan kata sandi di Linux untuk melindungi SSH dan layanan.

Jika Anda mengelola server Linux yang terhubung ke internet, cepat atau lambat Anda akan melihat hal berikut di log: ribuan upaya login SSH dari alamat IP acakBukan berarti mereka tidak menyukai Anda: mereka adalah bot otomatis yang menjelajahi rentang IP untuk mencari pintu yang kurang terlindungi.

Pada server kecil, upaya-upaya tersebut dapat berujung pada... Lonjakan penggunaan CPU, penurunan kinerja, dan bahkan gangguan layanan sesekali.Kabar baiknya adalah Linux menawarkan serangkaian alat untuk membatasi upaya memasukkan kata sandi, memblokir IP yang agresif, dan memperkuat SSH agar sangat sulit bagi penyerang.

Mendeteksi serangan brute-force SSH dan dampaknya pada server.

Sebelum kita mulai mengkonfigurasi apa pun, ada baiknya untuk memahami cara mendeteksi bahwa kita sedang mengalami suatu masalah. serangan brute-force terhadap SSH atau layanan lainnyadan apa dampaknya terhadap mesin tersebut.

Salah satu gejala yang sangat umum adalah melihat Peningkatan penggunaan CPU secara tiba-tiba tanpa adanya perubahan pada lalu lintas yang sah atau beban basis data.Sebagai contoh, Anda mungkin mengalami lonjakan penggunaan CPU selama beberapa menit sementara penggunaan memori dan disk tetap hampir stabil, yang biasanya menunjukkan proses yang membutuhkan banyak komputasi (seperti banyak upaya otentikasi) daripada kueri yang berat.

Untuk menganalisis apa yang terjadi dalam interval waktu tertentu, sangat bermanfaat untuk menggunakan journalctlAlat systemd untuk membaca log sistem, layanan, kernel, dan otentikasi. Contoh klasik dari sebuah kueri adalah:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

Dengan jenis kueri tersebut, Anda dapat meninjau secara detail. Pesan apa saja yang dicatat sistem selama periode lonjakan penggunaan CPU?: layanan yang memulai ulang, kegagalan otentikasi, kesalahan kernel, dll.

Dalam banyak kasus, Anda akan menemukan baris berulang yang terkait dengan SSH, seperti "Kata sandi gagal untuk" menunjukkan upaya masuk yang gagal.Itu praktis sama artinya dengan bot yang melakukan pengujian kredensial secara paksa.

Hitung jumlah upaya otentikasi yang gagal di /var/log/auth.log

Pada sistem Debian/Ubuntu, file kunci untuk melacak segala sesuatu yang berkaitan dengan otentikasi adalah /var/log/auth.logDi sinilah dicatat login yang berhasil, upaya login yang gagal, kejadian PAM, penguncian akun, dll.

Jika Anda ingin mengetahui berapa kali pola tersebut telah direkam "Kata sandi gagal" di log saat ini, kamu bisa memakai:

sudo grep 'Failed password' /var/log/auth.log | wc -l

Hasilnya bisa mengejutkan: bukan hal yang aneh untuk melihat Ribuan upaya gagal terakumulasi hanya dalam hitungan jam.Dan ingat, itu hanya file saat ini.

Karena log dirotasi, penting juga untuk meninjau file yang lebih lama. Anda dapat melihat interval waktu yang dicakup oleh log saat ini dengan sesuatu seperti:

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

Dengan begitu kamu akan tahu Tanggal catatan pertama dan terakhir yang ada di auth.logSisa upaya sebelumnya akan ada di auth.log.1 dan di file terkompresi auth.log.N.gz.

Untuk meninjau log lama yang telah dikompresi dan menghitung upaya kata sandi yang gagal, Anda dapat menggunakan:

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

Jika Anda menjumlahkan apa yang Anda lihat di auth.log, auth.log.1 dan auth.log.*.gz Anda akan mendapatkan gambaran yang baik tentang hal tersebut. Catatan sejarah serangan brute-force, dengan mempertimbangkan bahwa yang tertua mungkin sudah hilang karena rotasi.

Cara kerja rotasi log autentikasi

Cara dan frekuensi perputaran kayu gelondongan bergantung pada konfigurasi logrotateDi Ubuntu, rotasi auth.log biasanya didefinisikan di /etc/logrotate.d/rsyslog, di mana Anda biasanya akan menemukan sesuatu seperti:

weekly
rotate 4
compress

Itu artinya bahwa itu Log tersebut dirotasi setiap minggu, empat salinan lama disimpan, dan salinan lama tersebut dikompresi menjadi file .gz.Sebuah tugas cron harian bertanggung jawab untuk menjalankan logrotate dan menerapkan aturan-aturan ini.

Oleh karena itu, ketika Anda menghitung upaya brute-force Anda, anggaplah bahwa Anda hanya melihat data historis dari beberapa minggu yang lalu.Segala sesuatu yang terjadi lebih jauh ke masa lalu tidak akan lagi tercatat dalam sistem.

Identifikasi pengguna dan IP penyerang.

Selain jumlah total, penting untuk mengetahui Pengguna mana yang menjadi target dan dari alamat IP mana serangan tersebut berasal?Dengan sedikit perintah awk pada auth.log, Anda bisa mendapatkannya.

Untuk melihat nama pengguna mana yang dicoba dalam upaya yang gagal:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

Dan untuk melihat IP dengan aktivitas paling mencurigakan:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

Ini akan memungkinkan Anda untuk mendeteksi dengan cepat apakah mereka sedang menyerang. akun asli dari sistem Anda atau pengguna umum seperti root, admin, test, user, dll., dan IP mana yang harus Anda blokir paling mendesak.

Apakah benar-benar seserius itu sampai ada ribuan percobaan?

Harus diasumsikan bahwa, jika server Anda dapat diakses dari Internet dan memiliki SSH mendengarkan pada port 22 atau port lainnyaServer ini akan menerima jenis lalu lintas ini 24 jam sehari. Wajar jika melihat ribuan upaya yang gagal jika server telah berjalan dalam jangka waktu tertentu.

Nilai gravitasi sebenarnya bergantung pada pengaturan Anda:

konfigurasi Perkiraan risiko
Kata sandi lemah + akses SSH terbuka ke Internet Risiko kompromi sangat tinggi
Kata sandi yang kuat Risiko sedang, tetapi membutuhkan banyak sumber daya.
Fail2ban dikonfigurasi dengan benar Serangan berisiko rendah dan sangat terkendali.
Akses hanya dengan kunci SSH Risiko sangat mendekati nol dengan metode brute force.

Dengan kata lain: serangan otomatis sudah biasa terjadi, tetapi jika konfigurasi Anda longgar, Hanya satu kesalahan kata sandi saja sudah cukup untuk menyebabkan Anda kehilangan akses ke seluruh server.Itulah mengapa sangat penting untuk membatasi upaya akses, memblokir IP, dan, jika memungkinkan, menghilangkan kata sandi.

Pengamanan SSH dasar: opsi penting dalam sshd_config

Batasi upaya memasukkan kata sandi di Linux untuk melindungi SSH dan layanan.

Garis pertahanan pertama ada di dalam diri sendiri. Daemon SSH (sshd) dan file konfigurasinya /etc/ssh/sshd_config (dan file .d terkait). Beberapa arahan yang disetel dengan baik sangat mengurangi potensi serangan.

Perlu diingat bahwa pada distribusi modern seperti Ubuntu 22.04 dan versi yang lebih baru, sshd pertama-tama membaca /etc/ssh/sshd_config dan kemudian file-file di /etc/ssh/sshd_config.d/*.conf dalam urutan abjad. Apa pun yang muncul kemudian dapat menimpa parameter yang telah ditentukan sebelumnya, jadi berhati-hatilah dengan apa yang Anda ubah.

Nonaktifkan akses tanpa kata sandi dan sesi yang tidak perlu.

Meskipun sudah terkonfigurasi dengan baik di sebagian besar distribusi modern, tidak ada salahnya untuk memastikannya. Login tanpa kata sandi yang ditentukan tidak diizinkan.Arahan utamanya adalah:

PermitEmptyPasswords no

Biasanya dikomentari atau secara eksplisit diatur ke "tidak". Selain itu, pastikan Anda menonaktifkan fitur yang tidak akan Anda gunakan, seperti... Penerusan X11 (X11Forwarding) Jika Anda tidak melakukan sesi grafis jarak jauh:

X11Forwarding no

Terkait protokol, jika karena alasan tertentu Anda mengelola sistem yang sangat lama, periksa apakah hanya tindakan tertentu yang diizinkan. Protokol SSH 2:

Protocol 2

Ubah port default dan batasi antarmuka mana yang digunakan untuk mendengarkan.

Trik sederhana lainnya, meskipun tidak sepenuhnya sempurna, adalah... Pindahkan akses SSH dari port 22 ke port non-standar.Ini tidak melindungi Anda dari penyerang serius, tetapi menyaring sejumlah besar gangguan otomatis yang hanya memindai 22.

Port 2222
ListenAddress 192.168.56.8

Selain mengubah port, Anda dapat menentukan alamat spesifik tempat SSH akan mendengarkan, misalnya, alamat IP internal Anda jika Anda ingin membatasinya ke jaringan tertentu. Namun, jika distribusi Anda menggunakan ssh.socket dari systemd, Anda mungkin perlu... Nonaktifkan soket dan kembali ke layanan ssh.service klasik. untuk menghormati konfigurasi port:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

Setiap kali Anda mengubah port, uji koneksi dari terminal lain sebelum menutup sesi utama, agar Anda tidak terjebak tanpa akses jarak jauh.

Blokir atau batasi akses root.

Pengguna root mudah menjadi sasaran penyerang, jadi hal itu masuk akal. mencegah koneksi melalui SSHbahkan dengan kata sandi. Anda mengontrol perilaku ini dengan arahan:

PermitRootLogin no

Pada banyak instalasi modern, fitur ini hadir dalam mode "larang kata sandi", yang mencegah login menggunakan kata sandi tetapi tetap membuka kemungkinan penggunaan sertifikat. Jika Anda ingin lebih aman, biarkan pengaturan tetap "tidak" dan gunakan akun biasa dengan sudo untuk administrasi.

Tentukan siapa yang dapat mengakses: AllowUsers dan AllowGroups

Secara default, setiap pengguna dengan shell yang valid dan kata sandi yang telah ditentukan Anda bisa mencoba terhubung melalui SSH. Namun, cara ini biasanya kurang ideal untuk server produksi, di mana mungkin hanya dua atau tiga akun yang seharusnya memiliki akses.

Untuk membatasi pengguna yang diizinkan, Anda memiliki arahan berikut. IzinkanPengguna y IzinkanGrup. Sebagai contoh:

AllowUsers harry hermione
AllowGroups gryffindor

Daftar tersebut dipisahkan oleh spasi dan semantiknya sama dengan "daftar putih": Hanya akun dan grup yang terdaftar yang dapat melakukan otentikasi.Perlu diingat juga bahwa AllowUsers lebih diutamakan daripada AllowGroups, jadi jangan mencampuradukkan keduanya kecuali Anda memahami urutan evaluasinya dengan jelas.

Praktik yang baik adalah bekerja terutama dengan kelompok-kelompok yang tipikal. sshusers atau admin dan tambahkan akun yang berwenang di sana, alih-alih menyimpan daftar pengguna satu per satu di dalam file.

Batasi upaya otentikasi dan waktu henti.

Lapisan perlindungan lainnya ada di Kurangi jumlah percobaan gagal yang diperbolehkan pada satu koneksi. dan berapa lama sesi dapat tetap tidak aktif. Untuk pertanyaan pertama, Anda dapat menggunakan:

MaxAuthTries 3

Dengan demikian, server akan menutup koneksi setelah tiga kali percobaan yang salah, yang Hal ini membuat serangan apa pun yang mencoba banyak kata sandi terhadap sesi SSH yang sama menjadi kurang efektif..

Terkait waktu idle, SSH memungkinkan Anda untuk mengakhiri koneksi yang tetap terbuka tanpa aktivitas melebihi ambang batas yang ditentukan. Interval Klien Aktif (dalam detik):

ClientAliveInterval 180

Setelah tiga menit tanpa lalu lintas, server akan mengirimkan pesan keepalive dan, jika klien tidak merespons, Sesi akan ditutup secara otomatis.Ini adalah cara untuk mengurangi risiko dari terminal yang terlupakan dan tidak terkunci.

Batasi akses berdasarkan alamat IP: TCP Wrappers dan Match

Dalam beberapa skenario, Anda mungkin tertarik pada... Hanya IP atau rentang IP tertentu yang dapat mengakses melalui SSH.Anda memiliki beberapa cara untuk melakukannya: dari firewall itu sendiri (iptables/nftables), melalui TCP Wrappers, hingga blok Match di sshd_config.

Dengan TCP Wrappers, yang masih digunakan di banyak distribusi, akses dikontrol dengan /etc/hosts.allow dan /etc/hosts.deny. Alurnya adalah: Pertama, hosts.allow dievaluasi, lalu hosts.deny.Contoh yang lebih spesifik adalah:

# /etc/hosts.deny
ALL: ALL
# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

Dengan konfigurasi tersebut, Hanya dua host tertentu yang dapat terhubung melalui SSH.dan sisanya akan ditolak. Ini sangat efektif di lingkungan tertutup, meskipun kurang fleksibel dibandingkan firewall modern yang baik.

Opsi lain, yang lebih umum pada SSH, adalah menggunakan blok. Cocok Di dalam sshd_config, Anda dapat menerapkan aturan berdasarkan alamat atau pengguna. Bayangkan Anda ingin pengguna "git" dapat masuk dari mana saja, tetapi pengguna administrator Anda "greg" hanya dapat masuk dari LAN 192.168.1.0/24. Anda dapat menggabungkan AllowUsers dengan aturan Match Address, meskipun Anda harus sangat berhati-hati untuk... Jangan menutup diri dari dirimu sendiri.

Fail2ban: Pemblokiran otomatis versus serangan brute force

Sekalipun Anda memperkuat SSH, bot tetap akan mencoba mengakses kredensial, menyebabkan penggunaan CPU dan banyaknya log yang tidak perlu. Untuk mengurangi hal ini, solusi berikut ini berperan. Fail2ban, sebuah sistem pencegahan intrusi berbasis log. yang secara otomatis memblokir IP dengan terlalu banyak kesalahan.

Fail2ban ditulis dalam Python dan bergantung pada "penjara" atau penjara, masing-masing terkait dengan suatu layanan dan satu atau lebih berkas log.Ketika mendeteksi pola kesalahan yang berulang (kegagalan kata sandi, akses terlarang, dll.), sistem akan memicu tindakan, biasanya aturan firewall untuk memblokir sumbernya.

Instal Fail2ban pada distribusi Linux umum

Instalasi dasarnya cukup mudah menggunakan pengelola paket distribusi Anda. Pada Ubuntu atau Debian, ini sudah cukup:

sudo apt update
sudo apt install fail2ban

Pada sistem berbasis RHEL (RHEL, CentOS, AlmaLinux, Rocky, dll.) perintah tipikalnya adalah dengan dnf atau yum, tergantung versinya:

sudo dnf install fail2ban

Paket tersebut biasanya menyertakan layanan systemd yang berjalan secara otomatis, meskipun ada baiknya untuk memeriksanya terlebih dahulu. Fail2ban berjalan saat booting dan aktif.:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Struktur konfigurasi: jail.conf, jail.local, dan jail.d

Konfigurasi tersebut berada di /etc/fail2ban/File utamanya adalah jail.conf, tetapi mengeditnya secara langsung tidak disarankan karena akan ditimpa saat pembaruan. Sebagai gantinya, Anda harus:

  • Buat atau edit /etc/fail2ban/jail.local untuk menimpa nilai default.
  • Atau tambahkan file tertentu ke /etc/fail2ban/jail.d/*.conf.

Fail2ban memuat konfigurasi dalam urutan ini:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

Semua yang Anda definisikan di jail.local akan lebih diutamakan daripada semua yang ada sebelumnya, jadi Anda dapat melakukan kustomisasi tanpa menyentuh file paket..

Parameter global penting: bantime, maxretry, ignoreip

Di dalam jail.conf (atau jail.local) Anda akan melihat bagian [DEFAULT] dengan parameter global yang memengaruhi semua jail kecuali jika ditimpa. Yang paling penting adalah:

  • ban waktu: waktu di mana sebuah IP akan diblokir (dalam detik) setelah melampaui jumlah kegagalan yang diizinkan.
  • coba lagi: jumlah maksimum percobaan gagal sebelum menerapkan larangan.
  • Cari waktu: jendela waktu di mana upaya-upaya tersebut dihitung (misalnya, 10m selama sepuluh menit).
  • abaikan: daftar IP atau rentang IP yang tidak boleh diblokir oleh Fail2ban (misalnya, IP publik Anda sendiri atau jaringan manajemen Anda).

Misalnya, Anda bisa memiliki sesuatu seperti ini di [DEFAULT]:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

Dengan konfigurasi tersebut, Alamat IP mana pun yang gagal lima kali dalam sepuluh menit akan diblokir selama sepuluh menit., kecuali jika termasuk dalam rentang yang diabaikan.

Konfigurasikan jail sshd untuk menghentikan serangan SSH.

Jail yang paling umum adalah jail SSH. Di banyak distribusi, jail ini sudah dikonfigurasi sebelumnya di jail.conf; Anda hanya perlu mengaktifkannya atau menyesuaikan nilainya di jail.local. Contoh sederhana:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

Dalam hal ini, Tiga upaya login yang gagal yang tercatat dalam auth.log dalam waktu sepuluh menit akan mengakibatkan pemblokiran selama sepuluh menit pada alamat IP penyerang.Fail2ban menyuntikkan aturan ke dalam firewall (iptables, nftables, atau UFW, tergantung pada sistem) sehingga koneksi dari IP tersebut bahkan tidak mencapai sshd.

Untuk menerapkan perubahan konfigurasi apa pun, ingatlah untuk memulai ulang layanan:

sudo systemctl restart fail2ban

Lihat status penjara dan IP yang diblokir

Fail2ban menyertakan utilitas kontrol yang sangat praktis, fail2ban-klienDengan alat ini, Anda dapat melihat penjara mana yang aktif dan IP mana yang telah diblokir. Misalnya:

sudo fail2ban-client status

Ini akan menampilkan sesuatu yang mirip dengan:

Status
|- Number of jail: 1
`- Jail list: sshd

Untuk informasi detail mengenai penjara SSHD:

sudo fail2ban-client status sshd

Output tersebut mencakup, antara lain, jumlah IP yang saat ini diblokir dan jumlah total alamat historis yang telah diblokir setidaknya sekali, ditambah daftar IP yang terus diperbarui.

Dengan data ini Anda bisa mendapatkan gambaran tentang Seberapa banyak lalu lintas berbahaya yang diterima server Anda dan seberapa efektif konfigurasi saat ini?.

Pemblokiran permanen dan waktu pemblokiran bertahap.

Jika Anda ingin menindak tegas pelanggar berulang, Fail2ban menawarkan dua strategi menarik: larangan permanen dan larangan bertahap.

Untuk memblokir secara permanen alamat IP apa pun yang melebihi ambang batas kegagalan, cukup masukkan:

bantime = -1

Dengan penyesuaian tersebut, IP yang dikenai sanksi tidak akan pernah otomatis tidak diblokir.Anda hanya dapat menghapusnya secara manual jika memang perlu.

Mekanisme yang lebih fleksibel adalah mekanisme bertahap, di mana setiap residivisme meningkatkan waktu larangan sesuai dengan faktor tertentu:

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

Dengan nilai-nilai ini, progresinya akan terlihat seperti ini:

  • Blok ke-1: 10 menit
  • Blok ke-2: 40 menit
  • Blok ke-3: 160 menit (~2 jam 40 menit)
  • Blok ke-4: sekitar 10,6 jam
  • Blok ke-5: beberapa 42 jam

Karena bantime.maxtime adalah -1, maka durasi dapat terus bertambah tanpa batas, sehingga para pemain besar yang berpengaruh tersingkir dari permainan selamanya.

Menggunakan Fail2ban di luar SSH: Apache, WordPress, MySQL, toko online…

Setelah Anda memahami cara kerja Fail2ban, langkah logis selanjutnya adalah memperluasnya ke... melindungi layanan sensitif lainnya selain SSH: panel administrasi web, CMS, basis data, dll.

Sebagai contoh, untuk toko online (Magento, PrestaShop, WooCommerce…) sangat masuk akal untuk membuat jail yang memantau Log akses Apache atau Nginx mencari banyak kode 401/403 di /admin atau /login.Konfigurasi minimal berbasis Apache bisa berupa:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

Dalam lingkungan WordPress, kombinasi yang umum adalah memantau. /wp-login.php dan /xmlrpc.phpIni adalah titik masuk klasik untuk serangan brute-force dan bot. Filter dapat ditempatkan di /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

Dan penjara yang sesuai di jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

Ide yang sama berlaku untuk basis data yang terekspos (sesuatu yang umumnya sebaiknya dihindari): jika Anda ingin melindungi MySQL dari upaya akses yang gagal secara terus-menerus, Anda dapat membuat filter untuk Pesan “Akses ditolak untuk pengguna” di log kesalahan:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

Lalu penjara:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

Pada server hosting dengan panel kontrol cPanel atau PleskFail2ban juga terintegrasi dengan baik: dapat memantau layanan email, Apache, FTP, dan bahkan panel kontrol itu sendiri, memblokir IP yang melanggar aturan dengan upaya login.

Autentikasi dengan kunci SSH: mengakhiri serangan kata sandi.

Semua hal di atas membantu, tetapi peningkatan kualitas yang sesungguhnya terjadi ketika Anda memutuskan Berhenti menggunakan kata sandi untuk SSH dan beralihlah ke kunci publik/pribadi.Pada titik itu, serangan kata sandi brute-force menjadi tidak masuk akal.

Idenya sederhana: setiap pengguna yang sah memiliki sepasang kunci, sebuah kunci pribadi yang tetap berada di perangkat Anda dan kunci publik yang disalin ke server di dalam file ~/.ssh/authorized_keys milik pengguna yang bersangkutan.

Saat klien terhubung, klien tidak mengirimkan kunci pribadi; klien mengirimkan kunci publik dan kemudian menandatangani tantangan server. dengan tanda tangan privat. Server memeriksa tanda tangan tersebut terhadap tanda tangan publik, dan hanya jika cocok barulah akses diizinkan.

Mengapa kunci SSH menggagalkan serangan brute force kata sandi?

Dalam skema kata sandi klasik, penyerang hanya perlu mencoba berbagai rangkaian teks hingga salah satunya cocok dengan kata sandi yang tersimpan (atau hash-nya). Meskipun kata sandi yang baik memiliki banyak kombinasi yang mungkin, Kita berbicara tentang orde besaran seperti 10¹⁰ kemungkinan untuk kata sandi rata-rata..

Kunci SSH 256-bit tipikal (seperti yang ada di Ed25519) bergerak dalam ruang pencarian dengan urutan sebagai berikut: 10⁶¹⁷ kombinasiDalam praktiknya, secara matematis mustahil bagi penyerang untuk menebak kunci privat dengan metode brute force menggunakan komputer modern.

Namun yang lebih penting lagi, server bahkan tidak mencoba menghitung apa pun jika Kunci publik yang diberikan tidak ada di authorized_keys.Dalam hal ini, koneksi akan langsung diputus, tanpa memanggil PAM atau proses otentikasi tradisional, sehingga konsumsi CPU selama serangan besar-besaran sangat minimal.

Buat dan verifikasi kunci SSH pada klien.

Sebelum mengakses server, periksa apakah mesin Anda sudah memiliki pasangan kunci SSH yang dihasilkan. Cukup tampilkan isi dari ~/.ssh:

ls -l ~/.ssh

Jika Anda melihat file seperti id_ed25519 dan id_ed25519.pub Jika Anda menggunakan id_rsa dan id_rsa.pub, Anda sudah memiliki pasangan yang valid. Ed25519 lebih modern dan ringan, jadi biasanya ini adalah pilihan terbaik saat ini.

Jika Anda tidak memiliki kunci, buat kunci baru dengan:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

Perintah tersebut akan membuat dua file:

  • id_ed25519: kunci pribadi, yang tidak boleh Anda bagikan.
  • id_ed25519.pub: kunci publik, yang dapat Anda salin ke server.

Anda dapat melihat isi kunci publik dengan:

cat ~/.ssh/id_ed25519.pub

Salin kunci publik ke server dan uji akses.

Di server, pastikan direktori ~/.ssh ada untuk pengguna yang akan Anda gunakan untuk masuk (misalnya, git atau pengguna administrator Anda) dan bahwa direktori tersebut memiliki izin 700:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Kemudian tambahkan isi dari file id_ed25519.pub milik klien Anda ke ~/.ssh/authorized_keys (membuat file jika belum ada) dan memberikan izin 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Ingatlah untuk mengganti YOUR_PUBLIC_KEY dengan baris lengkap yang Anda lihat menggunakan `cat` di mesin Anda. Dari situ, Anda dapat menguji koneksi dengan secara eksplisit menentukan kunci jika Anda mau.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

Jika semuanya baik-baik saja, Server tidak akan meminta kata sandi dan Anda akan langsung masuk ke shell.Pada titik itu, Anda siap mempertimbangkan untuk menonaktifkan otentikasi kata sandi.

Nonaktifkan sepenuhnya PasswordAuthentication pada server.

Setelah Anda memverifikasi bahwa Anda dapat mengakses akun Anda dengan kata sandi Anda dari setidaknya satu perangkat (idealnya dua, jika Anda kehilangan salah satunya), ada baiknya Nonaktifkan login kata sandi untuk SSHIni langsung menggagalkan setiap upaya untuk menggunakan kekerasan brutal.

Sebelum mengubah konfigurasi, ada baiknya untuk melihat file mana yang mendefinisikan PasswordAuthentication, karena di banyak instalasi modern Terdapat file .d yang menimpa nilai sshd_config utama.:

sudo grep -R "PasswordAuthentication" /etc/ssh/

Biasanya kita akan menemukan hal seperti ini:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

Dalam hal ini, konfigurasi efektif akan menjadi "ya" karena file 50-cloud-init.conf dimuat setelahnya dan menimpa nilainya. Anda dapat memverifikasi hasil akhir yang diterapkan sshd dengan:

sudo sshd -T | grep passwordauthentication

Untuk menonaktifkan kata sandi asli, edit file yang bersangkutan (misalnya /etc/ssh/sshd_config.d/50-cloud-init.conf) dan biarkan:

PasswordAuthentication no

Kemudian, mulai ulang layanan SSH:

sudo systemctl restart ssh

Dan periksa kembali dengan:

sudo sshd -T | grep passwordauthentication

Jika mengembalikan "tidak", Upaya masuk menggunakan kata sandi akan langsung ditolak.Program seperti PuTTY akan menampilkan kesalahan karena tidak dapat memberikan kredensial berupa kata sandi, tetapi klien Anda yang memiliki kunci akan tetap berfungsi tanpa masalah.

Menggabungkan kunci SSH dengan Fail2ban dan langkah-langkah lainnya

Jika Anda menghilangkan PasswordAuthentication dari persamaan, nilai Fail2ban untuk SSH menjadi lebih bermanfaat daripada penting, karena Bot tersebut bahkan tidak memiliki kolom untuk memasukkan kata sandi.Meskipun demikian, disarankan untuk tetap mengaktifkan sshd jail karena berfungsi sebagai lapisan tambahan untuk melindungi dari upaya-upaya yang tidak biasa atau penyalahgunaan kunci.

Jika kombinasi ini Hanya kunci SSH + Fail2ban + penguncian root + daftar AllowUsers/AllowGroups yang disetel dengan baik Tambahkan firewall yang ketat (iptables/nftables, UFW, firewalld) dan, jika perlu, daftar kontrol akses dengan TCP Wrappers, dan Anda akan mengurangi kemungkinan intrusi brute-force hingga ke tingkat yang dapat diabaikan.

Di lingkungan yang lebih sensitif, Anda dapat melangkah lebih jauh dan memperkenalkan otentikasi dua faktor (2FA) untuk SSHmenggunakan modul seperti Google Authenticator atau yang serupa melalui PAM, atau bahkan membatasi siapa yang dapat mengakses port SSH menggunakan VPN khusus.

Dengan semua elemen ini terintegrasi dengan baik—deteksi log, konfigurasi sshd yang cermat, penggunaan Fail2ban yang ekstensif, kunci SSH sebagai pengganti kata sandi, dan, bila perlu, kontrol berbasis IP—server Linux dapat menangani serangan brute-force terus-menerus pada SSH dan layanan-layanan lain yang terekspossambil tetap menjaga akses yang nyaman dan aman bagi administrator.