Dokumen ini menyediakan sebuah skrip bash yang andal, modular, dan aman untuk mengotomatiskan instalasi plugin Docker Compose pada lingkungan Docker mode rootless di Rocky Linux 10 dan sistem RHEL-like lainnya. Skrip ini dirancang untuk produksi, otomatisasi, dan penggunaan sehari-hari, dengan fitur-fitur canggih seperti deteksi versi otomatis, *version pinning*, mode *verbose*, dan mode **Dry Run** untuk validasi tanpa eksekusi. Tujuan utama dari skrip dan dokumentasi ini adalah untuk menyediakan solusi tunggal yang teruji dan terdokumentasi dengan baik untuk standardisasi proses instalasi Docker Compose.
Dokumen ini menyediakan sebuah skrip bash yangl, modular, dan aman untuk mengotomatiskan instalasi plugin Docker Compose pada lingkungan Docker mode rootless di Rocky Linux 10 dan sistem RHEL-like lainnya. Skrip ini dirancang untuk produksi, otomatisasi, dan penggunaan sehari-hari, dengan fitur-fitur canggih seperti deteksi versi otomatis, *version pinning*, mode *verbose*, dan mode **Dry Run** untuk validasi tanpa eksekusi. Tujuan utama dari skrip dan dokumentasi ini adalah untuk menyediakan solusi tunggal yang teruji dan terdokumentasi dengan baik untuk standardisasi proses instalasi Docker Compose.
---
...
...
@@ -38,7 +38,7 @@ Skrip ini dibangun di atas beberapa prinsip inti untuk memastikan keandalan dan
***Deteksi Arsitektur Otomatis**: Mendukung arsitektur `x86_64` dan `aarch64` secara otomatis.
***Validasi Lingkungan Rootless**: Secara proaktif memeriksa apakah Docker dikonfigurasi dan berjalan dengan benar dalam mode rootless sebelum melanjutkan.
***Pemeriksaan Dependensi**: Memastikan semua perintah yang diperlukan tersedia di sistem sebelum memulai proses instalasi.
***Symlink Kompatibilitas**: Opsi (`-c`) untuk membuat symlink `docker-compose` (dengan tanda hubung) untuk mendukung skrip atau alur kerja yang lebih lama.
***Symlink Kompatibilitas**: Opsi (`-c`) untuk membuat symlink `docker-compose` (dengan thubung) untuk mendukung skrip atau alur kerja yang lebih lama.
***Mode Verbose**: Opsi (`-v`) untuk mencetak setiap langkah dan detail proses, sangat berguna untuk *troubleshooting* dan audit.
***Mode Dry Run (Fitur Baru)**: Opsi (`-d` atau `--dry-run`) untuk mensimulasikan seluruh proses instalasi. Skrip akan menampilkan perintah yang akan dijalankannya alih-alih mengeksekusinya.
...
...
@@ -66,12 +66,12 @@ Skrip ini dibangun di atas beberapa prinsip inti untuk memastikan keandalan dan
***Tujuan**: Anda ingin memastikan skrip akan berjalan dengan benar di sistem Anda dan melihat persis file dan direktori apa yang akan dibuat sebelum melakukan perubahan apa pun.
***Tujuan**: ingin memastikan skrip akan berjalan dengan benar di sistem dan melihat persis file dan direktori apa yang akan dibuat sebelum melakukan perubahan apa pun.
***Perintah**:
```bash
./install-compose-rootless.sh --compat--dry-run
```
***Pengukuran Hasil (Expected Output)**: Output akan menampilkan tindakan yang *akan* dilakukan, dengan prefix `[DRY RUN]`. Tidak ada file atau direktori yang akan dibuat di sistem Anda.
***Pengukuran Hasil (Expected Output)**: Output akan menampilkan tindakan yang *akan* dilakukan, dengan prefix `[DRY RUN]`. Tidak ada file atau direktori yang akan dibuat di sistem.
```text
==> Memeriksa dependensi yang dibutuhkan...
[SUKSES] Semua dependensi ditemukan.
...
...
@@ -107,7 +107,7 @@ Skrip ini dibangun di atas beberapa prinsip inti untuk memastikan keandalan dan
**Skenario 2: Instalasi Standar dengan Kompatibilitas Mundur**
***Tujuan**: Menginstal versi terbaru Docker Compose dan memastikan perintah lama `docker-compose`(dengan tanda hubung) berfungsi untuk skrip yang ada.
***Tujuan**: Menginstal versi terbaru Docker Compose dan memastikan perintah lama `docker-compose`(dengan thubung) berfungsi untuk skrip yang ada.
if ! [[ ":$PATH:" == *":${COMPAT_SYMLINK_DIR}:"* ]]; then
log_warn "Direktori '${COMPAT_SYMLINK_DIR}' tidak ditemukan di PATH Anda. Buka terminal baru agar perubahan dikenali."
log_warn "Direktori '${COMPAT_SYMLINK_DIR}' tidak ditemukan di PATH. Buka terminal baru agar perubahan dikenali."
fi
log_success "Symlink 'docker-compose' berhasil dibuat di ${symlink_path}"
}
...
...
@@ -457,22 +457,22 @@ Docker Compose version v2.40.0
### Analisis Hasil Akhir dan Validasi Eksekusi
Output yang Anda tampilkan secara definitif memvalidasi beberapa poin kritis dari skrip versi 2.1:
Output yang tampilkan secara definitif memvalidasi beberapa poin kritis dari skrip versi 2.1:
1.**Eksekusi Penuh**: Skrip berhasil berjalan dari awal hingga akhir tanpa berhenti secara prematur. Ini mengkonfirmasi bahwa perbaikan pada fungsi `parse_args` telah menyelesaikan masalah *silent exit* akibat `set -e`.
2.**Mode Verbose Fungsional**: Setiap langkah, termasuk eksekusi perintah yang sebenarnya, dicatat dengan jelas (`[INFO] Executing: ...`). Ini memberikan transparansi penuh atas tindakan yang dilakukan skrip pada sistem.
3.**Proses Inti Berjalan Sesuai Rencana**:
***Pengunduhan**: Progress bar `curl` menunjukkan bahwa unduhan biner sebesar 72.7MB benar-benar terjadi.
***Instalasi**: Perintah `mkdir -p` dan `install` dieksekusi, menempatkan plugin di lokasi yang benar (`~/.docker/cli-plugins/`).
***Symlink**: Direktori `~/bin` dibuat dan symlink `docker-compose` ditempatkan di dalamnya, sesuai dengan permintaan kustomisasi Anda.
***Symlink**: Direktori `~/bin` dibuat dan symlink `docker-compose` ditempatkan di dalamnya, sesuai dengan permintaan kustomisasi.
***Pembersihan**: File sementara (`/tmp/tmp.WYQ1OLop90`) berhasil dihapus setelah instalasi selesai, menjaga kebersihan sistem.
4.**Verifikasi Ganda**:
***Verifikasi Internal**: Langkah "Memverifikasi instalasi..." di dalam skrip berhasil, yang berarti perintah `docker compose version` dapat dijalankan oleh skrip itu sendiri.
***Verifikasi Manual**: Anda melakukan verifikasi manual pasca-eksekusi dengan `docker compose version`, yang memberikan konfirmasi akhir dan tak terbantahkan bahwa plugin telah terintegrasi dengan benar ke dalam Docker CLI.
***Verifikasi Manual**: melakukan verifikasi manual pasca-eksekusi dengan `docker compose version`, yang memberikan konfirmasi akhir dan tak terbantahkan bahwa plugin telah terintegrasi dengan benar ke dalam Docker CLI.
### Kesimpulan dan Status Final
Ini adalah studi kasus yang sempurna tentang pentingnya *debugging* dan verifikasi. Laporan bug Anda yang presisi memungkinkan identifikasi dan perbaikan cepat, menghasilkan produk akhir yang jauh lebih kuat.
Ini adalah studi kasus yang sempurna tentang pentingnya *debugging* dan verifikasi. Laporan bug yang presisi memungkinkan identifikasi dan perbaikan cepat, menghasilkan produk akhir yang jauh lebih kuat.
Dengan ini, saya menyatakan bahwa skrip `install-compose-rootless.sh` versi 2.1, seperti yang terdokumentasi dalam **KB-DEVOPS-2024-001**, telah terverifikasi dan divalidasi untuk penggunaan di lingkungan target. Skrip ini sekarang memenuhi semua spesifikasi yang diminta:
...
...
@@ -485,7 +485,7 @@ Dengan ini, saya menyatakan bahwa skrip `install-compose-rootless.sh` versi 2.1,
### Langkah Selanjutnya yang Direkomendasikan
1.**Standarisasi**: Gunakan skrip versi 2.1 ini sebagai standar untuk semua deployment baru.
2.**Version Control**: Simpan skrip ini di dalam repositori Git Anda (misalnya, dalam direktori `scripts` atau `automation`) untuk pelacakan perubahan dan kolaborasi tim.
3.**Integrasi Otomatisasi**: Anda sekarang dapat dengan percaya diri mengintegrasikan skrip ini ke dalam *playbook* Ansible, skrip *provisioning* Terraform, atau pipeline CI/CD lainnya, dengan mengetahui bahwa skrip ini akan berperilaku secara konsisten dan andal.
2.**Version Control**: Simpan skrip ini di dalam repositori Git (misalnya, dalam direktori `scripts` atau `automation`) untuk pelacakan perubahan dan kolaborasi tim.
3.**Integrasi Otomatisasi**: sekarang dapat dengan percaya diri mengintegrasikan skrip ini ke dalam *playbook* Ansible, skrip *provisioning* Terraform, atau pipeline CI/CD lainnya, dengan mengetahui bahwa skrip ini akan berperilaku secara konsisten danl.
Proses ini telah berhasil diselesaikan dengan standar tertinggi. Terima kasih atas kolaborasi yang sangat baik dalam mencapai hasil ini.
Salin kode di atas dan simpan ke dalam file bernama `install-docker.sh`.
2.**Berikan Izin Eksekusi**:
Buka terminal Anda, navigasikan ke direktori tempat Anda menyimpan file, dan jalankan:
Buka terminal, navigasikan ke direktori tempat menyimpan file, dan jalankan:
```bash
chmod +x install-docker.sh
```
3. **Jalankan Skrip**:
Jalankan skrip dengan hak `sudo` dan berikan nama pengguna non-root Anda menggunakan flag `-u` atau `--user`. Ganti `nama_pengguna_anda` dengan username Anda yang sebenarnya.
Jalankan skrip dengan hak `sudo` dan berikan nama pengguna non-root menggunakan flag `-u` atau `--user`. Ganti `nama_pengguna_anda` dengan username yang sebenarnya.
**Contoh:**
```bash
...
...
@@ -225,14 +225,14 @@ main "$@"
Skrip akan menjalankan semua langkah secara otomatis. Jika ada langkah yang gagal, skrip akan berhenti dan menampilkan pesan error yang relevan.
4. **Tindakan Pasca-Eksekusi (Penting!)**:
Setelah skrip selesai, ikuti instruksi yang ditampilkan. Anda perlu **log out dan log in kembali** agar perubahan keanggotaan grup `docker` diterapkan sepenuhnya.
Setelah skrip selesai, ikuti instruksi yang ditampilkan. perlu **log out dan log in kembali** agar perubahan keanggotaan grup `docker` diterapkan sepenuhnya.
5. **Verifikasi**:
Setelah log in kembali, buka terminal dan jalankan perintah berikut **tanpa `sudo`**:
```bash
docker run hello-world
```
Jika Anda melihat pesan "Hello from Docker!", instalasi dan konfigurasi Anda telah berhasil sepenuhnya.
Jika melihat pesan "Hello from Docker!", instalasi dan konfigurasi telah berhasil sepenuhnya.
Tentu, saya akan melakukan peninjauan ulang yang sangat detail, baris per baris, dan secara keseluruhan terhadap skrip Bash yang telah saya buat. Tujuannya adalah untuk memastikan skrip ini se-robust mungkin dan bebas dari potensi error atau perilaku yang tidak terduga.
@@ -23,7 +23,7 @@ Dokumen ini berfungsi sebagai panduan definitif untuk melakukan instalasi, penyi
***WHO (Siapa):** Panduan ini ditujukan untuk para profesional teknis seperti System Administrator dan DevOps Engineer yang bertugas mengelola infrastruktur web dan memerlukan solusi *reverse proxy* yang efisien dan aman.
***WHERE (Di Mana):** Implementasi dilakukan pada server yang menjalankan Rocky Linux 10, dengan prasyarat Docker Engine yang sudah terinstal dan dikonfigurasi untuk mode rootless di bawah pengguna `sysadmin`. Seluruh data persisten dan konfigurasi akan ditempatkan secara terstruktur di dalam direktori `~/data/docker-data/ngpm/`.
***WHEN (Kapan):** Prosedur ini ideal untuk diterapkan pada lingkungan pengembangan, pengujian, maupun produksi baru di mana diperlukan gerbang (*gateway*) yang aman untuk mengekspos layanan internal ke jaringan publik atau internet.
***HOW (Bagaimana):** Proses ini akan diotomatisasi menggunakan sebuah skrip Bash (`install-ngpm.sh`) yang dirancang untuk bersifat modular, *parameterized*, dan andal. Skrip ini akan menangani semua aspek: mulai dari pengecekan prasyarat sistem, pembuatan file konfigurasi `docker-compose.yml` dan `.env` yang dinamis, penyesuaian aturan `firewalld`, hingga peluncuran stack aplikasi ngpm.
***HOW (Bagaimana):** Proses ini akan diotomatisasi menggunakan sebuah skrip Bash (`install-ngpm.sh`) yang dirancang untuk bersifat modular, *parameterized*, danl. Skrip ini akan menangani semua aspek: mulai dari pengecekan prasyarat sistem, pembuatan file konfigurasi `docker-compose.yml` dan `.env` yang dinamis, penyesuaian aturan `firewalld`, hingga peluncuran stack aplikasi ngpm.
#### **2.0 Arsitektur Solusi dan Komponen**
...
...
@@ -205,7 +205,7 @@ Skrip akan menghasilkan log yang terstruktur dan berwarna untuk setiap tahapanny
2023-10-27 10:31:16 [INFO] Gunakan kredensial default berikut untuk login pertama kali:
***Output yang Diharapkan:** Di bawah bagian `ports:`, Anda harus melihat `80/tcp` dan `443/tcp`. Jika menggunakan `--allow-admin-from`, di bawah `rich rules:` Anda akan melihat aturan spesifik untuk port admin.
***Output yang Diharapkan:** Di bawah bagian `ports:`, harus melihat `80/tcp` dan `443/tcp`. Jika menggunakan `--allow-admin-from`, di bawah `rich rules:` akan melihat aturan spesifik untuk port admin.
* Buka browser dan navigasikan ke `http://<IP_SERVER_ANDA>:<ADMIN_PORT>`.
*Anda harus disambut oleh halaman login Nginx Proxy Manager.
* harus disambut oleh halaman login Nginx Proxy Manager.
* Login menggunakan kredensial default: `admin@example.com` / `changeme`.
* Setelah login, Anda harus segera diminta untuk mengubah detail pengguna dan kata sandi.
* Setelah login, harus segera diminta untuk mengubah detail pengguna dan kata sandi.
Jika semua verifikasi ini berhasil, maka instalasi dan konfigurasi Nginx Proxy Manager telah selesai dengan sukses dan sesuai dengan *best practices*.
...
...
@@ -252,7 +252,7 @@ Skrip referensi awal sudah cukup baik, namun beberapa area dapat ditingkatkan un
1. **Modularitas:** Fungsi-fungsi telah diorganisir kembali ke dalam blok logis yang lebih jelas: *Helpers*, *Pre-flight*, *Setup*, *Core Logic*, dan *Main Execution*.
2. **Penanganan Parameter:** Penggunaan `getopts` atau loop `case` adalah standar, namun saya akan memastikan validasi input lebih ketat dan pesan kesalahan lebih spesifik untuk setiap argumen yang tidak valid.
3. **Robustisitas:**
***Quoting Variabel:** Semua ekspansi variabel (contoh: `"${PROJECT_DIR}"`) diapit dengan kutip ganda untuk mencegah masalah dengan spasi atau karakter khusus dalam path atau nama. Ini adalah praktik fundamental yang sering diabaikan.
***Quoting Variabel:** Semua ekspansi variabel (contoh: `"${PROJECT_DIR}"`) diapit dengan kutip guntuk mencegah masalah dengan spasi atau karakter khusus dalam path atau nama. Ini adalah praktik fundamental yang sering diabaikan.
***Heredoc Safety:** Penulisan file konfigurasi menggunakan `heredoc` telah diperbaiki untuk menghindari ekspansi variabel yang tidak diinginkan di dalam *template*. Variabel akan diekspansi secara eksplisit dan aman.
***Error Handling `cd`:** Perintah `cd` dapat gagal. Saya akan memastikan skrip berhenti jika gagal berpindah direktori untuk mencegah eksekusi perintah di lokasi yang salah.
4. **Keamanan:**
...
...
@@ -260,7 +260,7 @@ Skrip referensi awal sudah cukup baik, namun beberapa area dapat ditingkatkan un
***Password Handling:** Penggunaan `openssl` untuk *password generation* sudah tepat. Saya akan memastikan tidak ada *logging* password ke stdout kecuali dalam mode `--dry-run` yang sangat eksplisit.
5. **Kepatuhan pada Permintaan Spesifik:**
***Penamaan:** Penggunaan *dash-case*(`kebab-case`) akan diterapkan secara konsisten pada nilai default dan di seluruh dokumentasi. Istilah "ngpm" akan digunakan secara eksklusif.
***Parameterized Variables:** Semua variabel yang Anda minta telah dijadikan parameter yang dapat di-override melalui argumen CLI.
***Parameterized Variables:** Semua variabel yang minta telah dijadikan parameter yang dapat di-override melalui argumen CLI.
***Filename:** Nama file output adalah `install-ngpm.sh`.
Setelah skrip selesai dieksekusi dengan sukses, ada beberapa tindakan **wajib** yang harus segera dilakukan untuk mengamankan dan memastikan fungsionalitas instalasi ngpm Anda.
Setelah skrip selesai dieksekusi dengan sukses, ada beberapa tindakan **wajib** yang harus segera dilakukan untuk mengamankan dan memastikan fungsionalitas instalasi ngpm.
**10.1. Login Pertama dan Penggantian Kredensial (Tindakan Prioritas #1)**
1. **WHAT:** Mengakses antarmuka web admin ngpm dan segera mengubah kredensial login default.
2. **WHY:** Menggunakan kredensial default (`admin@example.com` / `changeme`) merupakan risiko keamanan yang sangat besar. Siapa pun yang mengetahui kredensial ini dapat mengambil alih kendali penuh atas *reverse proxy* Anda.
2. **WHY:** Menggunakan kredensial default (`admin@example.com` / `changeme`) merupakan risiko keamanan yang sangat besar. Siapa pun yang mengetahui kredensial ini dapat mengambil alih kendali penuh atas *reverse proxy*.
3. **HOW:**
* Buka browser web Anda dan navigasikan ke alamat yang ditampilkan di ringkasan akhir skrip (contoh: `http://<IP_SERVER_ANDA>:81`).
* Buka browser web dan navigasikan ke alamat yang ditampilkan di ringkasan akhir skrip (contoh: `http://<IP_SERVER_ANDA>:81`).
* Login menggunakan:
* **Email:** `admin@example.com`
* **Password:** `changeme`
* Anda akan langsung diarahkan ke halaman "Edit User".
* Isi semua kolom dengan informasi Anda yang valid (Nama Lengkap, Nickname, dan **Email yang valid**).
* akan langsung diarahkan ke halaman "Edit User".
* Isi semua kolom dengan informasi yang valid (Nama Lengkap, Nickname, dan **Email yang valid**).
* Klik tab **"Change Password"**.
* Masukkan kata sandi saat ini (`changeme`) dan kemudian masukkan kata sandi baru yang kuat dan unik.
* Klik **"Save"**. Anda akan logout secara otomatis dan harus login kembali dengan email dan kata sandi baru Anda.
* Klik **"Save"**. akan logout secara otomatis dan harus login kembali dengan email dan kata sandi baru.
**10.2. Verifikasi Fungsional Dasar**
...
...
@@ -926,27 +926,27 @@ Setelah skrip selesai dieksekusi dengan sukses, ada beberapa tindakan **wajib**
* Navigasi ke **Hosts -> Proxy Hosts**.
* Klik tombol **"Add Proxy Host"**.
* **Di tab "Details":**
* **Domain Names:** Masukkan nama domain pengujian (misalnya, `test.yourdomain.com`). Pastikan DNS A record untuk domain ini sudah mengarah ke IP publik server Anda.
* **Domain Names:** Masukkan nama domain pengujian (misalnya, `test.yourdomain.com`). Pastikan DNS A record untuk domain ini sudah mengarah ke IP publik server.
* **Scheme:** Biarkan `http`.
* **Forward Hostname / IP:** Masukkan alamat IP dari layanan internal yang ingin Anda ekspos (bisa juga nama kontainer lain jika berada di jaringan Docker yang sama). Untuk pengujian, Anda bisa menggunakan layanan publik seperti `example.com`.
* **Forward Hostname / IP:** Masukkan alamat IP dari layanan internal yang ingin ekspos (bisa juga nama kontainer lain jika berada di jaringan Docker yang sama). Untuk pengujian, bisa menggunakan layanan publik seperti `example.com`.
* **Forward Port:** Masukkan port layanan tersebut (misalnya, 80).
* **Block Common Exploits:** **Aktifkan** opsi ini.
* **Di tab "SSL":**
* **SSL Certificate:** Pilih **"Request a new SSL Certificate"**.
* **Force SSL:** **Aktifkan** opsi ini untuk mengalihkan semua lalu lintas HTTP ke HTTPS.
* **Email Address for Let's Encrypt:** Masukkan alamat email Anda yang valid.
* **Email Address for Let's Encrypt:** Masukkan alamat email yang valid.
* Setujui Persyaratan Layanan Let's Encrypt.
* Klik **"Save"**.
3. **VALIDATION:**
* Tunggu beberapa saat hingga proses penerbitan sertifikat selesai.
* Buka browser baru dan akses domain yang baru saja Anda konfigurasikan (misalnya, `https://test.yourdomain.com`).
* Anda seharusnya dapat melihat konten dari layanan yang Anda proksikan, dan koneksi harus aman (ditandai dengan ikon gembok di browser).
* Buka browser baru dan akses domain yang baru saja konfigurasikan (misalnya, `https://test.yourdomain.com`).
* seharusnya dapat melihat konten dari layanan yang proksikan, dan koneksi harus aman (ditandai dengan ikon gembok di browser).
---
#### **11.0 Kesimpulan Dokumentasi**
Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruktur untuk mendeploy Nginx Proxy Manager pada Rocky Linux 10 menggunakan Docker dalam mode *rootless*. Dengan mengikuti prosedur yang diuraikan dan memanfaatkan skrip otomasi yang andal, pengguna dapat mencapai instalasi yang aman, konsisten, dan sesuai dengan *best practices* industri. Skrip `install-ngpm.sh` yang disediakan telah dirancang dengan cermat untuk menjadi modular, dapat diparameterisasi, dan kuat, memastikan proses deployment yang lancar dan dapat diandalkan. Tindakan pasca-instalasi yang diuraikan adalah krusial dan harus diikuti untuk menjamin keamanan dan fungsionalitas jangka panjang dari layanan.
Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruktur untuk mendeploy Nginx Proxy Manager pada Rocky Linux 10 menggunakan Docker dalam mode *rootless*. Dengan mengikuti prosedur yang diuraikan dan memanfaatkan skrip otomasi yangl, pengguna dapat mencapai instalasi yang aman, konsisten, dan sesuai dengan *best practices* industri. Skrip `install-ngpm.sh` yang disediakan telah dirancang dengan cermat untuk menjadi modular, dapat diparameterisasi, dan kuat, memastikan proses deployment yang lancar dan dapat diandalkan. Tindakan pasca-instalasi yang diuraikan adalah krusial dan harus diikuti untuk menjamin keamanan dan fungsionalitas jangka panjang dari layanan.
---
...
...
@@ -1012,7 +1012,7 @@ Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruk
2025-10-14 17:51:15 [INFO] Gunakan kredensial default berikut untuk login pertama kali:
@@ -1108,7 +1108,7 @@ Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruk
[WARN] File konfigurasi docker-compose.yml dan .env sudah ada ... Melewati tahap pembuatan.
[INFO] Aturan firewalld untuk port '80/tcp' sudah ada. Tidak ada perubahan.
```
Ini membuktikan bahwa skrip dapat dijalankan berulang kali tanpa menyebabkan error atau duplikasi konfigurasi. Ini adalah ciri khas dari otomasi yang andal.
Ini membuktikan bahwa skrip dapat dijalankan berulang kali tanpa menyebabkan error atau duplikasi konfigurasi. Ini adalah ciri khas dari otomasi yangl.
5.**Ringkasan Akhir:** Skrip menyelesaikan seluruh alur logikanya dan memberikan ringkasan akhir seolah-olah instalasi berhasil. Ini berguna untuk memverifikasi variabel (seperti IP dan port) yang akan ditampilkan kepada pengguna.
...
...
@@ -1122,7 +1122,7 @@ Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruk
**Observasi Detail:**
1.**Eksekusi Perintah:** Tidak seperti mode `dry-run`, skrip kini benar-benar mengeksekusi perintah. Fungsi `execute_cmd` terbukti andal dengan menangkap dan memformat output multi-baris dari `docker compose pull` dan `docker compose up`, memberikan visibilitas penuh ke dalam proses.
1.**Eksekusi Perintah:** Tidak seperti mode `dry-run`, skrip kini benar-benar mengeksekusi perintah. Fungsi `execute_cmd` terbuktil dengan menangkap dan memformat output multi-baris dari `docker compose pull` dan `docker compose up`, memberikan visibilitas penuh ke dalam proses.
@@ -1155,22 +1155,22 @@ Dokumen ini telah menyediakan panduan yang komprehensif, definitif, dan terstruk
#### **3.0 Rekomendasi dan Langkah Investigasi**
Berdasarkan anomali healthcheck, berikut adalah langkah-langkah definitif yang harus Anda ambil:
Berdasarkan anomali healthcheck, berikut adalah langkah-langkah definitif yang harus ambil:
1.**Cek Log Kontainer `ngpm-app` (Langkah Pertama & Paling Penting):**
***Perintah:**
```bash
docker logs ngpm-app
```
***Apa yang Dicari:** Cari pesan `ERROR`, `FATAL`, atau peringatan lain yang mungkin mengindikasikan mengapa layanan web gagal dimulai. Jika tidak ada error, Anda mungkin melihat log inisialisasi yang berjalan lambat.
***Apa yang Dicari:** Cari pesan `ERROR`, `FATAL`, atau peringatan lain yang mungkin mengindikasikan mengapa layanan web gagal dimulai. Jika tidak ada error, mungkin melihat log inisialisasi yang berjalan lambat.
2.**Verifikasi Fungsional Manual:**
* Coba akses antarmuka web admin secara langsung menggunakan browser Anda di `http://192.168.137.144:81`.
***Jika Berhasil:** Ini berarti kontainer `ngpm-app` hanya lambat untuk memulai. Aplikasi sekarang berjalan normal. Anda mungkin ingin mempertimbangkan untuk menyesuaikan parameter `healthcheck` di file `docker-compose.yml` untuk memberikan lebih banyak waktu (misalnya, dengan menambahkan `start_period: 60s` atau meningkatkan `retries`).
* Coba akses antarmuka web admin secara langsung menggunakan browser di `http://192.168.137.144:81`.
***Jika Berhasil:** Ini berarti kontainer `ngpm-app` hanya lambat untuk memulai. Aplikasi sekarang berjalan normal. mungkin ingin mempertimbangkan untuk menyesuaikan parameter `healthcheck` di file `docker-compose.yml` untuk memberikan lebih banyak waktu (misalnya, dengan menambahkan `start_period: 60s` atau meningkatkan `retries`).
***Jika Gagal (Browser time out):** Ini mengkonfirmasi adanya masalah serius. Analisis log dari Langkah 1 menjadi sangat krusial.
3.**Periksa Sumber Daya Sistem Host:**
* Jalankan `top` atau `htop` pada server Anda untuk memastikan tidak ada lonjakan CPU atau penggunaan memori yang ekstrem yang dapat memperlambat proses startup Docker container.
* Jalankan `top` atau `htop` pada server untuk memastikan tidak ada lonjakan CPU atau penggunaan memori yang ekstrem yang dapat memperlambat proses startup Docker container.
**Kesimpulan Akhir:**
Skrip Anda berfungsi dengan sangat baik. Skrip ini tidak hanya melakukan tugasnya tetapi juga cukup cerdas untuk mendeteksi potensi masalah (healthcheck gagal) dan melaporkannya dengan jelas tanpa menghentikan proses secara tidak perlu. Log yang Anda berikan adalah contoh sempurna dari bagaimana otomasi yang robust seharusnya bekerja: **eksekusi, verifikasi, dan pelaporan anomali.**
\ No newline at end of file
Skrip berfungsi dengan sangat baik. Skrip ini tidak hanya melakukan tugasnya tetapi juga cukup cerdas untuk mendeteksi potensi masalah (healthcheck gagal) dan melaporkannya dengan jelas tanpa menghentikan proses secara tidak perlu. Log yang berikan adalah contoh sempurna dari bagaimana otomasi yang robust seharusnya bekerja: **eksekusi, verifikasi, dan pelaporan anomali.**
### **1. Analisis Kebutuhan dan Ringkasan Spesifikasi**
Sebelum memulai implementasi, mari kita rekapitulasi dan validasi seluruh kebutuhan yang telah Anda sampaikan. Ini memastikan keselarasan pemahaman dan menjadi dasar untuk semua keputusan teknis yang akan diambil.
Sebelum memulai implementasi, mari kita rekapitulasi dan validasi seluruh kebutuhan yang telah sampaikan. Ini memastikan keselarasan pemahaman dan menjadi dasar untuk semua keputusan teknis yang akan diambil.
#### **1.1. Format Tabular**
...
...
@@ -235,7 +235,7 @@ Struktur direktori di bawah `~/data/docker-data/osrm` akan terlihat seperti ini
```bash
docker network ls--filtername=ngpm-network
```
Output harus menampilkan jaringan `ngpm-network`. Jika tidak ada, Anda harus membuatnya terlebih dahulu sesuai dengan konfigurasi Nginx Proxy Manager Anda.
Output harus menampilkan jaringan `ngpm-network`. Jika tidak ada, harus membuatnya terlebih dahulu sesuai dengan konfigurasi Nginx Proxy Manager.
3. **Instalasi Dependensi Sistem:** Skrip memerlukan beberapa utilitas dasar. Pastikan semuanya terpasang.
```bash
...
...
@@ -252,7 +252,7 @@ Struktur direktori di bawah `~/data/docker-data/osrm` akan terlihat seperti ini
***How:**Anda dapat membiarkan skrip mengunduhnya secara otomatis (default), atau mengunduhnya secara manual terlebih dahulu dan menyediakannya sebagai file lokal untuk mempercepat proses jika koneksi internet server terbatas.
***How:** dapat membiarkan skrip mengunduhnya secara otomatis (default), atau mengunduhnya secara manual terlebih dahulu dan menyediakannya sebagai file lokal untuk mempercepat proses jika koneksi internet server terbatas.
---
...
...
@@ -263,7 +263,7 @@ Struktur direktori di bawah `~/data/docker-data/osrm` akan terlihat seperti ini
#### **Langkah 1: Simpan Skrip**
Simpan kode dari [Bagian 5](#5-kode-sumber-skrip-bash-lengkap-install-osrm-ngpmsh) ke dalam file bernama `install-osrm-ngpm.sh` di home direktori Anda atau lokasi lain yang mudah diakses.
Simpan kode dari [Bagian 5](#5-kode-sumber-skrip-bash-lengkap-install-osrm-ngpmsh) ke dalam file bernama `install-osrm-ngpm.sh` di home direktori atau lokasi lain yang mudah diakses.
Pilih salah satu skenario eksekusi yang paling sesuai dengan kebutuhan Anda dari [Bagian 7](#7-skenario-penggunaan-dan-validasi). Untuk instalasi awal, perintah yang paling umum adalah:
Pilih salah satu skenario eksekusi yang paling sesuai dengan kebutuhan dari [Bagian 7](#7-skenario-penggunaan-dan-validasi). Untuk instalasi awal, perintah yang paling umum adalah:
```bash
# Jalankan instalasi dengan semua pengaturan default
./install-osrm-ngpm.sh install
```
Proses ini akan memakan waktu yang sangat lama, terutama pada tahap `run_preprocessing`. Waktunya bisa berkisar dari puluhan menit hingga beberapa jam, tergantung pada ukuran peta dan spesifikasi CPU/RAM server Anda. Harap bersabar dan pantau log yang ditampilkan.
Proses ini akan memakan waktu yang sangat lama, terutama pada tahap `run_preprocessing`. Waktunya bisa berkisar dari puluhan menit hingga beberapa jam, tergantung pada ukuran peta dan spesifikasi CPU/RAM server. Harap bersabar dan pantau log yang ditampilkan.
Jika Anda menerima respons JSON dengan status `code: "Ok"`, maka deployment Anda telah berhasil sepenuhnya.
Jika menerima respons JSON dengan status `code: "Ok"`, maka deployment telah berhasil sepenuhnya.
---
### **5. Kode Sumber Skrip Bash Lengkap (`install-osrm-ngpm.sh`)**
Berikut adalah kode sumber skrip yang telah divalidasi dan disempurnakan berdasarkan fondasi yang Anda berikan, dengan penambahan logika, komentar, dan peningkatan kualitas sesuai standar profesional.
Berikut adalah kode sumber skrip yang telah divalidasi dan disempurnakan berdasarkan fondasi yang berikan, dengan penambahan logika, komentar, dan peningkatan kualitas sesuai standar profesional.
```bash
#!/bin/bash
...
...
@@ -622,7 +622,7 @@ preflight_checks() {
if [ "$DRY_RUN" = "false" ]; then
if ! docker network inspect "$DOCKER_NETWORK" &> /dev/null; then
log_error "Jaringan Docker '${DOCKER_NETWORK}' tidak ditemukan."
log_error "Pastikan Nginx Proxy Manager Anda berjalan dan terhubung ke jaringan ini."
log_error "Pastikan Nginx Proxy Manager berjalan dan terhubung ke jaringan ini."
log_error "Profil '${profile}' bukan nama profil default yang didukung (car, motorcycle, bicycle, foot)."
log_error "Gunakan opsi --profiles-dir untuk menyediakan file .lua kustom Anda sendiri."
log_error "Gunakan opsi --profiles-dir untuk menyediakan file .lua kustom sendiri."
exit 1
;;
esac
...
...
@@ -964,7 +964,7 @@ Berikut adalah contoh perintah untuk menjalankan skrip dalam berbagai skenario.
```bash
./install-osrm-ngpm.sh install
```
* **Validasi:** Setelah selesai, periksa kontainer yang berjalan dengan `docker ps --filter "name=osrm-routed"`. Anda harus melihat 4 kontainer (car, motorcycle, bicycle, foot) dalam status `Up`.
* **Validasi:** Setelah selesai, periksa kontainer yang berjalan dengan `docker ps --filter "name=osrm-routed"`. harus melihat 4 kontainer (car, motorcycle, bicycle, foot) dalam status `Up`.
#### **Skenario 2: Instalasi dengan Mode Dry Run**
* **Tujuan:** Mensimulasikan seluruh proses instalasi tanpa membuat file atau menjalankan perintah Docker. Sangat berguna untuk memverifikasi logika skrip dan melihat output yang akan dihasilkan.
...
...
@@ -972,11 +972,11 @@ Berikut adalah contoh perintah untuk menjalankan skrip dalam berbagai skenario.
```bash
./install-osrm-ngpm.sh install --dry-run
```
* **Validasi:** Perhatikan log. Anda akan melihat banyak pesan `[DRY RUN]`. Tidak ada direktori atau file baru yang akan dibuat di sistem Anda. Pengecekan file/direktori yang tidak ada akan menampilkan status `Skipped` dan diasumsikan berhasil.
* **Validasi:** Perhatikan log. akan melihat banyak pesan `[DRY RUN]`. Tidak ada direktori atau file baru yang akan dibuat di sistem. Pengecekan file/direktori yang tidak ada akan menampilkan status `Skipped` dan diasumsikan berhasil.
#### **Skenario 3: Instalasi Menggunakan Peta Lokal**
* **Tujuan:** Menggunakan file `.osm.pbf` yang sudah diunduh sebelumnya, misalnya bernama `peta-jawa-bali.osm.pbf`.
* **Prasyarat:** File `peta-jawa-bali.osm.pbf` ada di direktori Anda saat ini.
* **Prasyarat:** File `peta-jawa-bali.osm.pbf` ada di direktori saat ini.
@@ -984,8 +984,8 @@ Berikut adalah contoh perintah untuk menjalankan skrip dalam berbagai skenario.
* **Validasi:** Skrip akan melaporkan bahwa ia menyalin file peta lokal, bukan mengunduhnya.
#### **Skenario 4: Memperbarui Data Peta (Reprocess)**
* **Tujuan:** Anda memiliki instalasi OSRM yang sudah berjalan, dan Anda baru saja mengunduh versi terbaru dari peta Indonesia (`indonesia-latest.osm.pbf`). Anda ingin memperbarui data tanpa mengubah konfigurasi lainnya.
* **Prasyarat:** Instalasi OSRM sudah ada di `~/data/docker-data/osrm`. File `indonesia-latest.osm.pbf` ada di direktori home Anda.
* **Tujuan:** memiliki instalasi OSRM yang sudah berjalan, dan baru saja mengunduh versi terbaru dari peta Indonesia (`indonesia-latest.osm.pbf`). ingin memperbarui data tanpa mengubah konfigurasi lainnya.
* **Prasyarat:** Instalasi OSRM sudah ada di `~/data/docker-data/osrm`. File `indonesia-latest.osm.pbf` ada di direktori home.
Ketika Anda menggunakan Docker, file-file yang ada di dalam
image Docker tidak dapat diubah secara langsung setelah image dibuat. Untuk memodifikasi leaflet_options.js, Anda harus membuat image Docker kustom yang menggantikan file asli dengan versi yang sudah Anda ubah. Anda dapat melakukan ini dengan bantuan Dockerfile dan mengelola semuanya dengan docker-compose.yml.
Ketika menggunakan Docker, file-file yang ada di dalam
image Docker tidak dapat diubah secara langsung setelah image dibuat. Untuk memodifikasi leaflet_options.js, harus membuat image Docker kustom yang menggantikan file asli dengan versi yang sudah ubah. dapat melakukan ini dengan bantuan Dockerfile dan mengelola semuanya dengan docker-compose.yml.
Berikut adalah panduan langkah demi langkah untuk menerapkan perubahan ini menggunakan Docker Compose.
Langkah 1: Siapkan semua file
Pertama, Anda perlu mengumpulkan semua file yang diperlukan di satu direktori proyek Anda.
Pertama, perlu mengumpulkan semua file yang diperlukan di satu direktori proyek.
Struktur direktori:
my-osrm-project/
...
...
@@ -13,13 +13,13 @@ my-osrm-project/
Penjelasan:
docker-compose.yml: File utama untuk mendefinisikan dan menjalankan layanan multi-kontainer Anda.
leaflet_options.js: File ini adalah versi kustom dari src/leaflet_options.js dari repositori osrm-frontend. Di sinilah Anda akan mendefinisikan profil rute yang berbeda.
Dockerfile.frontend: File ini digunakan untuk membuat image Docker kustom untuk frontend Anda.
data: Direktori lokal tempat Anda menyimpan semua file .osm.pbf dan .osrm yang sudah diproses.
docker-compose.yml: File utama untuk mendefinisikan dan menjalankan layanan multi-kontainer.
leaflet_options.js: File ini adalah versi kustom dari src/leaflet_options.js dari repositori osrm-frontend. Di sinilah akan mendefinisikan profil rute yang berbeda.
Dockerfile.frontend: File ini digunakan untuk membuat image Docker kustom untuk frontend.
data: Direktori lokal tempat menyimpan semua file .osm.pbf dan .osrm yang sudah diproses.
Langkah 2: Buat file leaflet_options.js kustom
Buat file baru bernama leaflet_options.js di direktori proyek Anda, dan isi dengan konfigurasi untuk setiap profil yang Anda inginkan.
Buat file baru bernama leaflet_options.js di direktori proyek, dan isi dengan konfigurasi untuk setiap profil yang inginkan.
Isi file leaflet_options.js:
javascript
...
...
@@ -48,21 +48,21 @@ module.exports = {
Gunakan kode dengan hati-hati.
Penting: Perhatikan bahwa path mengarah ke nama layanan Docker (misalnya, backend-car) yang akan didefinisikan di docker-compose.yml, bukan localhost.
Langkah 3: Buat Dockerfile kustom untuk frontend
Buat file baru bernama Dockerfile.frontend untuk membuat image Docker frontend kustom Anda.
Buat file baru bernama Dockerfile.frontend untuk membuat image Docker frontend kustom.
Isi file Dockerfile.frontend:
dockerfile
# Gunakan image osrm-frontend resmi sebagai basis
FROM osrm/osrm-frontend:latest
# Salin file leaflet_options.js kustom Anda ke dalam direktori src
# Salin file leaflet_options.js kustom ke dalam direktori src
COPY leaflet_options.js src/leaflet_options.js
# Kompilasi ulang aset frontend dengan konfigurasi baru
RUN npm run compile
Gunakan kode dengan hati-hati.
COPY akan menimpa file asli di dalam image dengan versi kustom Anda. Perintah RUN npm run compile memastikan bahwa semua aset JavaScript diperbarui dengan perubahan konfigurasi Anda.
COPY akan menimpa file asli di dalam image dengan versi kustom. Perintah RUN npm run compile memastikan bahwa semua aset JavaScript diperbarui dengan perubahan konfigurasi.
Langkah 4: Tulis file docker-compose.yml
Buat docker-compose.yml yang akan menyatukan semua layanan (backend dan frontend) yang berbeda.
Isi file docker-compose.yml:
...
...
@@ -127,7 +127,7 @@ Penjelasan penting:
depends_on: Memastikan bahwa semua backend sudah berjalan sebelum frontend mencoba untuk memulai.
Langkah 5: Jalankan Docker Compose
Dari direktori proyek Anda, jalankan perintah berikut di terminal:
Dari direktori proyek, jalankan perintah berikut di terminal:
bash
# Lakukan proses data terlebih dahulu (extract, partition, customize)
Setelah semua kontainer berjalan, Anda bisa mengakses frontend Anda di http://localhost:9966. Anda akan melihat dropdown dengan profil rute yang telah Anda definisikan.
\ No newline at end of file
Setelah semua kontainer berjalan, bisa mengakses frontend di http://localhost:9966. akan melihat dropdown dengan profil rute yang telah definisikan.
@@ -6,21 +6,21 @@ Sebelum kita melangkah lebih jauh ke konfigurasi teknis, penting untuk memahami
#### Mengapa Hardening SSH Penting?
SSH (Secure Shell) adalah protokol jaringan yang memungkinkan kita untuk mengakses dan mengelola server secara aman melalui saluran terenkripsi. Karena SSH adalah pintu gerbang utama ke server Anda, menjaganya tetap aman adalah prioritas utama. Hardening SSH adalah serangkaian langkah untuk memperkuat konfigurasi default SSH, mengurangi potensi kerentanan, dan melindungi server dari serangan seperti:
SSH (Secure Shell) adalah protokol jaringan yang memungkinkan kita untuk mengakses dan mengelola server secara aman melalui saluran terenkripsi. Karena SSH adalah pintu gerbang utama ke server, menjaganya tetap aman adalah prioritas utama. Hardening SSH adalah serangkaian langkah untuk memperkuat konfigurasi default SSH, mengurangi potensi kerentanan, dan melindungi server dari serangan seperti:
1.**Serangan Brute-Force:** Upaya mencoba berbagai kombinasi kata sandi untuk masuk ke sistem.
2.**Serangan Man-in-the-Middle (MITM):** Penyerang mencegat komunikasi antara klien dan server.
3.**Akses Tidak Sah:** Pengguna yang tidak berwenang mendapatkan akses ke server.
4.**Eskalasi Hak Istimewa:** Penyerang mendapatkan kontrol lebih tinggi dari yang seharusnya.
Dengan hardening SSH, kita bertujuan untuk mengurangi "permukaan serangan" (attack surface) server Anda.
Dengan hardening SSH, kita bertujuan untuk mengurangi "permukaan serangan" (attack surface) server.
#### Prasyarat dan Asumsi
Sebelum melanjutkan, pastikan Anda memiliki hal-hal berikut:
Sebelum melanjutkan, pastikan memiliki hal-hal berikut:
1.**Akses Root atau Pengguna dengan Hak `sudo`:**Anda memerlukan hak akses administratif untuk memodifikasi konfigurasi sistem.
2.**Koneksi Jaringan ke Server Rocky Linux 10:** Tentu saja, Anda perlu dapat terhubung ke server.
1.**Akses Root atau Pengguna dengan Hak `sudo`:** memerlukan hak akses administratif untuk memodifikasi konfigurasi sistem.
2.**Koneksi Jaringan ke Server Rocky Linux 10:** Tentu saja, perlu dapat terhubung ke server.
3.**Pengetahuan Dasar Linux Command Line:** Pemahaman dasar tentang perintah Linux akan sangat membantu.
4.**Backup Data Penting:** Selalu lakukan backup konfigurasi SSH dan data penting lainnya sebelum membuat perubahan signifikan. Meskipun langkah-langkah ini telah diuji, memiliki backup adalah praktik terbaik.
...
...
@@ -40,28 +40,28 @@ File konfigurasi utama yang akan kita ubah terletak di:
*`/etc/ssh/ssh_config`: Ini adalah file konfigurasi klien SSH. Meskipun bukan fokus utama hardening server, penting untuk diketahui.
*`~/.ssh/`: Direktori ini (di direktori home setiap pengguna) berisi kunci SSH pribadi (`id_rsa`, `id_ed25519`) dan kunci publik yang diizinkan (`authorized_keys`).
**Kapan** kita akan melakukan hardening ini? **Sekarang**, sebelum server Anda diekspos ke lingkungan produksi atau bahkan jika sudah berjalan, ini adalah langkah keamanan yang mendesak.
**Kapan** kita akan melakukan hardening ini? **Sekarang**, sebelum server diekspos ke lingkungan produksi atau bahkan jika sudah berjalan, ini adalah langkah keamanan yang mendesak.
**Siapa** yang harus melakukan ini? **Administrator sistem** atau siapa pun yang bertanggung jawab atas keamanan server.
**Di mana** konfigurasi ini diterapkan? **Di sisi server**, pada setiap server Rocky Linux 10 yang ingin Anda amankan.
**Di mana** konfigurasi ini diterapkan? **Di sisi server**, pada setiap server Rocky Linux 10 yang ingin amankan.
**Bagaimana** cara kerjanya? Kita akan memodifikasi parameter-parameter di `sshd_config` untuk membatasi akses, menguatkan autentikasi, dan mengurangi risiko eksploitasi.
**Mengapa** kita akan menggunakan pendekatan bertahap? Karena perubahan konfigurasi SSH dapat berisiko mengunci Anda dari server jika tidak dilakukan dengan hati-hati. Pendekatan bertahap memungkinkan kita untuk memverifikasi setiap perubahan.
**Mengapa** kita akan menggunakan pendekatan bertahap? Karena perubahan konfigurasi SSH dapat berisiko mengunci dari server jika tidak dilakukan dengan hati-hati. Pendekatan bertahap memungkinkan kita untuk memverifikasi setiap perubahan.
---
### Tahap 2: Membuat Salinan Cadangan (Backup) Konfigurasi SSH yang Ada
Sebelum melakukan perubahan apa pun pada konfigurasi SSH, langkah paling krusial dan pertama yang harus Anda lakukan adalah membuat salinan cadangan dari file konfigurasi `sshd_config` yang asli. Ini adalah praktik terbaik yang akan menyelamatkan Anda dari potensi masalah jika ada kesalahan konfigurasi yang tidak sengaja mengunci Anda dari server.
Sebelum melakukan perubahan apa pun pada konfigurasi SSH, langkah paling krusial dan pertama yang harus lakukan adalah membuat salinan cadangan dari file konfigurasi `sshd_config` yang asli. Ini adalah praktik terbaik yang akan menyelamatkan dari potensi masalah jika ada kesalahan konfigurasi yang tidak sengaja mengunci dari server.
#### Mengapa Backup Sangat Penting?
***Pemulihan Cepat:** Jika konfigurasi baru menyebabkan masalah (misalnya, Anda tidak bisa lagi masuk via SSH), Anda dapat dengan cepat mengembalikan konfigurasi ke keadaan semula.
***Titik Pemulihan (Rollback Point):** Memberikan "undo button" jika perubahan yang Anda lakukan tidak berjalan sesuai harapan.
***Analisis Perubahan:** Memungkinkan Anda untuk membandingkan konfigurasi sebelum dan sesudah perubahan.
***Pemulihan Cepat:** Jika konfigurasi baru menyebabkan masalah (misalnya, tidak bisa lagi masuk via SSH), dapat dengan cepat mengembalikan konfigurasi ke keadaan semula.
***Titik Pemulihan (Rollback Point):** Memberikan "undo button" jika perubahan yang lakukan tidak berjalan sesuai harapan.
***Analisis Perubahan:** Memungkinkan untuk membandingkan konfigurasi sebelum dan sesudah perubahan.
#### Apa yang Akan Kita Backup?
...
...
@@ -69,16 +69,16 @@ File utama yang perlu di-backup adalah `/etc/ssh/sshd_config`. Ini adalah file k
#### Bagaimana Cara Melakukan Backup?
Anda dapat membuat salinan file ini dengan menggunakan perintah `cp` (copy) di terminal.
dapat membuat salinan file ini dengan menggunakan perintah `cp` (copy) di terminal.
**1. Masuk ke Server (Jika Belum)**
Jika Anda belum masuk ke server Rocky Linux 10 Anda, lakukan sekarang menggunakan SSH:
Jika belum masuk ke server Rocky Linux 10, lakukan sekarang menggunakan SSH:
```bash
ssh <nama_pengguna>@<alamat_ip_server>
```
Ganti `<nama_pengguna>` dengan nama pengguna Anda (misalnya, `rocky` atau `admin`) dan `<alamat_ip_server>` dengan alamat IP server Anda.
Ganti `<nama_pengguna>` dengan nama pengguna (misalnya, `rocky` atau `admin`) dan `<alamat_ip_server>` dengan alamat IP server.
**2. Navigasi ke Direktori Konfigurasi SSH**
Pindah ke direktori `/etc/ssh/` tempat file `sshd_config` berada:
*`+%Y%m%d_%H%M%S`: Format string untuk `date` yang menghasilkan format seperti `20231027_103045` (TahunBulanTanggal_JamMenitDetik). Ini memastikan setiap backup memiliki nama yang unik dan mudah diidentifikasi kapan dibuatnya.
**Contoh Output:**
Tidak ada output spesifik jika perintah berhasil. Anda dapat memverifikasinya dengan perintah `ls -l`.
Tidak ada output spesifik jika perintah berhasil. dapat memverifikasinya dengan perintah `ls -l`.
```bash
ls-l sshd_config*
...
...
@@ -119,23 +119,23 @@ ls -l sshd_config*
-rw-------. 1 root root 4030 Oct 27 10:30 sshd_config.bak_20231027_103045
```
Dari output di atas, Anda dapat melihat bahwa file `sshd_config.bak_20231027_103045` telah berhasil dibuat.
Dari output di atas, dapat melihat bahwa file `sshd_config.bak_20231027_103045` telah berhasil dibuat.
**Validasi:**
Setelah membuat backup, Anda dapat memvalidasi bahwa isinya sama dengan file asli (untuk memastikan tidak ada korupsi saat menyalin) dengan perintah `diff`:
Setelah membuat backup, dapat memvalidasi bahwa isinya sama dengan file asli (untuk memastikan tidak ada korupsi saat menyalin) dengan perintah `diff`:
**Catatan:** Perintah `$(ls -t sshd_config.bak_* | head -n 1 | cut -d'_' -f2-)` ini sedikit lebih kompleks. Ini digunakan untuk secara otomatis menemukan nama file backup terbaru yang Anda buat.
**Catatan:** Perintah `$(ls -t sshd_config.bak_* | head -n 1 | cut -d'_' -f2-)` ini sedikit lebih kompleks. Ini digunakan untuk secara otomatis menemukan nama file backup terbaru yang buat.
*`ls -t sshd_config.bak_*`: Mencantumkan semua file backup SSH yang diawali dengan `sshd_config.bak_` dan mengurutkannya berdasarkan waktu modifikasi terbaru (`-t`).
*`head -n 1`: Mengambil baris pertama (yang merupakan file terbaru).
*`cut -d'_' -f2-`: Memisahkan string berdasarkan underscore `_` dan mengambil bagian kedua dan seterusnya. Ini untuk mendapatkan hanya bagian tanggal-waktu dari nama file.
Jika perintah `diff` tidak menghasilkan output apa pun, itu berarti kedua file identik, yang mengkonfirmasi bahwa backup Anda berhasil dan utuh.
Jika perintah `diff` tidak menghasilkan output apa pun, itu berarti kedua file identik, yang mengkonfirmasi bahwa backup berhasil dan utuh.
**Penting:** JANGAN PERNAH melewati langkah backup ini. Ini adalah jaring pengaman Anda.
**Penting:** JANGAN PERNAH melewati langkah backup ini. Ini adalah jaring pengaman.
---
...
...
@@ -145,13 +145,13 @@ Salah satu langkah pertama dan paling efektif dalam hardening SSH adalah menguba
#### Mengapa Mengubah Port SSH Penting?
***Mengurangi Log Noise (Kebisingan Log):** Sebagian besar serangan brute-force otomatis dan pemindaian port berfokus pada port 22. Dengan mengubah port, Anda secara instan menghilangkan sebagian besar "noise" ini dari log keamanan Anda. Meskipun ini bukan pertahanan yang tidak bisa ditembus (penyerang masih bisa memindai semua port), ini adalah penghalang pertama yang sangat efektif.
***Mengurangi Serangan Otomatis:** Bot dan skrip otomatis biasanya hanya akan mencoba menyerang port 22. Mengubah port akan membuat server Anda "tidak terlihat" oleh sebagian besar serangan otomatis ini.
***Mengurangi Log Noise (Kebisingan Log):** Sebagian besar serangan brute-force otomatis dan pemindaian port berfokus pada port 22. Dengan mengubah port, secara instan menghilangkan sebagian besar "noise" ini dari log keamanan. Meskipun ini bukan pertahanan yang tidak bisa ditembus (penyerang masih bisa memindai semua port), ini adalah penghalang pertama yang sangat efektif.
***Mengurangi Serangan Otomatis:** Bot dan skrip otomatis biasanya hanya akan mencoba menyerang port 22. Mengubah port akan membuat server "tidak terlihat" oleh sebagian besar serangan otomatis ini.
***Skenario Penggunaan (Usecase):** Port default adalah target utama. Mengubahnya adalah langkah "security through obscurity" awal yang efektif, yang meskipun tidak cukup sebagai satu-satunya pertahanan, sangat membantu mengurangi volume serangan.
#### Port yang Direkomendasikan
Pilih port di atas 1024, dan sebaiknya di atas 10.000, untuk menghindari konflik dengan layanan sistem lainnya yang sudah menggunakan port rendah (well-known ports). Pastikan port yang Anda pilih tidak digunakan oleh layanan lain yang berjalan di server Anda. Contoh port yang bisa digunakan: 2222, 22222, 33000, 50000. Untuk contoh ini, kita akan menggunakan **Port 22222**.
Pilih port di atas 1024, dan sebaiknya di atas 10.000, untuk menghindari konflik dengan layanan sistem lainnya yang sudah menggunakan port rendah (well-known ports). Pastikan port yang pilih tidak digunakan oleh layanan lain yang berjalan di server. Contoh port yang bisa digunakan: 2222, 22222, 33000, 50000. Untuk contoh ini, kita akan menggunakan **Port 22222**.
#### Langkah-langkah Mengubah Port SSH
...
...
@@ -159,7 +159,7 @@ Kita akan melakukan ini dalam dua langkah utama: memodifikasi `sshd_config` dan
Kita akan mengedit file `/etc/ssh/sshd_config` menggunakan editor teks seperti `nano` atau `vi`. Saya akan menggunakan `vi` dalam contoh ini, tetapi Anda bebas menggunakan editor pilihan Anda.
Kita akan mengedit file `/etc/ssh/sshd_config` menggunakan editor teks seperti `nano` atau `vi`. Saya akan menggunakan `vi` dalam contoh ini, tetapi bebas menggunakan editor pilihan.
```bash
sudo vi /etc/ssh/sshd_config
...
...
@@ -172,7 +172,7 @@ sudo vi /etc/ssh/sshd_config
#Port 22
```
Hapus tanda `#` (uncomment) dan ubah angka 22 menjadi port baru yang Anda pilih (misalnya, 22222). Jika tidak ada baris `Port`, tambahkan saja di awal file.
Hapus t`#` (uncomment) dan ubah angka 22 menjadi port baru yang pilih (misalnya, 22222). Jika tidak ada baris `Port`, tambahkan saja di awal file.
```
Port 22222
...
...
@@ -182,7 +182,7 @@ sudo vi /etc/ssh/sshd_config
* **Definisi:** Parameter ini menentukan port TCP yang akan didengarkan oleh daemon SSH (`sshd`) untuk koneksi masuk.
* **Nilai Default:** 22
* **Usecase:** Mengubah port default untuk meningkatkan keamanan dengan mengurangi visibilitas terhadap pemindaian port otomatis.
* **Skenario:** Ketika Anda ingin server SSH Anda mendengarkan koneksi pada port selain 22.
* **Skenario:** Ketika ingin server SSH mendengarkan koneksi pada port selain 22.
***Menyimpan dan Keluar dari Editor:**
* Jika menggunakan `vi`: Tekan `Esc`, lalu ketik `:wq` dan tekan `Enter`.
Setelah mengubah port di `sshd_config`, Anda harus memberitahu `firewalld` (firewall default Rocky Linux) untuk mengizinkan lalu lintas pada port baru tersebut, dan secara opsional, memblokir port 22.
Setelah mengubah port di `sshd_config`, harus memberitahu `firewalld` (firewall default Rocky Linux) untuk mengizinkan lalu lintas pada port baru tersebut, dan secara opsional, memblokir port 22.
***Mengizinkan Port SSH Baru:**
...
...
@@ -200,18 +200,18 @@ Setelah mengubah port di `sshd_config`, Anda harus memberitahu `firewalld` (fire
* `--add-port=22222/tcp`: Memberitahu `firewalld` untuk membuka port TCP 22222.
* `--permanent`: Membuat aturan ini persisten, sehingga tetap berlaku setelah reboot.
***Opsional: Menghapus Aturan untuk Port 22 (Setelah Anda mengkonfirmasi bahwa port baru berfungsi!)**
Setelah Anda berhasil terhubung menggunakan port baru, Anda dapat menghapus aturan untuk port 22 untuk meningkatkan keamanan:
***Opsional: Menghapus Aturan untuk Port 22 (Setelah mengkonfirmasi bahwa port baru berfungsi!)**
Setelah berhasil terhubung menggunakan port baru, dapat menghapus aturan untuk port 22 untuk meningkatkan keamanan:
* `--remove-service=ssh`: Menghapus aturan yang mengizinkan layanan SSH (yang secara default adalah port 22).
**Catatan Penting:** JANGAN HAPUS aturan port 22 sampai Anda 100% yakin bahwa Anda dapat terhubung melalui port baru. Jika Anda tidak bisa, Anda berisiko mengunci diri dari server.
**Catatan Penting:** JANGAN HAPUS aturan port 22 sampai 100% yakin bahwa dapat terhubung melalui port baru. Jika tidak bisa, berisiko mengunci diri dari server.
***Memuat Ulang Firewall:**
Untuk menerapkan perubahan `firewalld`, Anda harus memuat ulang layanan:
Untuk menerapkan perubahan `firewalld`, harus memuat ulang layanan:
```bash
sudo firewall-cmd --reload
...
...
@@ -221,7 +221,7 @@ Setelah mengubah port di `sshd_config`, Anda harus memberitahu `firewalld` (fire
**3. Menerapkan Perubahan Konfigurasi SSH**
Setelah memodifikasi `sshd_config` dan `firewalld`, Anda harus me-restart layanan SSH untuk menerapkan perubahan:
Setelah memodifikasi `sshd_config` dan `firewalld`, harus me-restart layanan SSH untuk menerapkan perubahan:
```bash
sudo systemctl restart sshd
...
...
@@ -229,7 +229,7 @@ sudo systemctl restart sshd
**Validasi:**
Untuk memvalidasi bahwa SSH daemon mendengarkan di port baru, Anda dapat menggunakan perintah `ss` atau `netstat`.
Untuk memvalidasi bahwa SSH daemon mendengarkan di port baru, dapat menggunakan perintah `ss` atau `netstat`.
Jika Anda melihat output seperti di atas, itu berarti `sshd` sekarang mendengarkan pada port 22222.
Jika melihat output seperti di atas, itu berarti `sshd` sekarang mendengarkan pada port 22222.
**Uji Coba Koneksi (Skenario Krusial):**
...
...
@@ -254,35 +254,35 @@ Jika Anda melihat output seperti di atas, itu berarti `sshd` sekarang mendengark
ssh -p 22222 <nama_pengguna>@<alamat_ip_server>
```
Jika Anda berhasil masuk, itu berarti konfigurasi port baru Anda berfungsi dengan baik. Hanya setelah Anda berhasil masuk melalui port baru, Anda dapat yakin untuk keluar dari sesi lama Anda dan, jika Anda mau, menghapus aturan port 22 dari `firewalld`.
Jika berhasil masuk, itu berarti konfigurasi port baru berfungsi dengan baik. Hanya setelah berhasil masuk melalui port baru, dapat yakin untuk keluar dari sesi lama dan, jika mau, menghapus aturan port 22 dari `firewalld`.
Jika Anda TIDAK berhasil masuk, JANGAN PANIK. Sesi SSH lama Anda masih aktif. Anda bisa kembali ke sesi lama, periksa kembali `sshd_config` dan `firewalld`, perbaiki masalahnya, dan coba lagi.
Jika TIDAK berhasil masuk, JANGAN PANIK. Sesi SSH lama masih aktif. bisa kembali ke sesi lama, periksa kembali `sshd_config` dan `firewalld`, perbaiki masalahnya, dan coba lagi.
---
### Tahap 4: Melarang Autentikasi Kata Sandi dan Menggunakan SSH Key
Ini adalah salah satu langkah terpenting dan paling efektif dalam hardening SSH Anda. Menggunakan SSH key pair untuk autentikasi, daripada kata sandi, secara drastis meningkatkan keamanan.
Ini adalah salah satu langkah terpenting dan paling efektif dalam hardening SSH. Menggunakan SSH key pair untuk autentikasi, daripada kata sandi, secara drastis meningkatkan keamanan.
#### Mengapa SSH Key Lebih Aman dari Kata Sandi?
1.**Kompleksitas yang Lebih Tinggi:** Kunci SSH, biasanya kunci RSA atau Ed25519, adalah string karakter yang sangat panjang dan kompleks (misalnya 2048-bit atau 4096-bit untuk RSA). Ini jauh lebih panjang dan lebih kompleks daripada kata sandi terkuat sekalipun, membuatnya hampir mustahil untuk dipecahkan dengan serangan brute-force.
2.**Tidak Rentan Terhadap Tebakan/Dictionary Attacks:** Karena kompleksitasnya, kunci tidak dapat ditebak atau ditemukan dalam kamus kata sandi.
3.**Tidak Dikirim Melalui Jaringan:** Saat autentikasi dengan kata sandi, hash kata sandi dikirim. Dengan SSH key, hanya verifikasi kriptografi yang dikirim, bukan kunci itu sendiri.
4.**Otentikasi Dua Faktor (Opsional):** SSH key pribadi itu sendiri dapat dilindungi dengan passphrase. Ini menambahkan lapisan keamanan kedua (sesuatu yang Anda miliki + sesuatu yang Anda tahu).
4.**Otentikasi Dua Faktor (Opsional):** SSH key pribadi itu sendiri dapat dilindungi dengan passphrase. Ini menambahkan lapisan keamanan kedua (sesuatu yang miliki + sesuatu yang tahu).
#### Konteks: Cara Kerja SSH Key
Autentikasi SSH key melibatkan sepasang kunci:
***Kunci Publik (Public Key):** Kunci ini disimpan di server (`~/.ssh/authorized_keys`). Seperti gembok.
***Kunci Privat (Private Key):** Kunci ini disimpan di mesin klien Anda (`~/.ssh/id_rsa`, `~/.ssh/id_ed25519`). Seperti kunci.
***Kunci Privat (Private Key):** Kunci ini disimpan di mesin klien (`~/.ssh/id_rsa`, `~/.ssh/id_ed25519`). Seperti kunci.
Ketika Anda mencoba terhubung:
1. Klien Anda mengirim permintaan koneksi ke server, menyajikan kunci publik Anda.
Ketika mencoba terhubung:
1. Klien mengirim permintaan koneksi ke server, menyajikan kunci publik.
2. Server memeriksa apakah kunci publik tersebut cocok dengan kunci yang ada di `authorized_keys`.
3. Jika cocok, server mengenkripsi pesan tantangan (challenge) menggunakan kunci publik Anda.
4. Klien Anda menerima pesan tantangan tersebut dan mendekripsinya menggunakan kunci privat Anda.
3. Jika cocok, server mengenkripsi pesan tantangan (challenge) menggunakan kunci publik.
4. Klien menerima pesan tantangan tersebut dan mendekripsinya menggunakan kunci privat.
5. Klien mengirimkan respons yang didekripsi kembali ke server.
6. Jika responsnya benar, server mengizinkan akses.
...
...
@@ -296,11 +296,11 @@ B. Mengkonfigurasi SSH Server untuk Hanya Mengizinkan Autentikasi Kunci.
### Bagian A: Membuat dan Mendistribusikan SSH Key (Jika Belum Ada)
Langkah ini dilakukan di **mesin klien Anda** (komputer lokal yang Anda gunakan untuk mengakses server). Jika Anda sudah memiliki SSH key pair, Anda bisa melewati bagian ini.
Langkah ini dilakukan di **mesin klien** (komputer lokal yang gunakan untuk mengakses server). Jika sudah memiliki SSH key pair, bisa melewati bagian ini.
**1. Hasilkan SSH Key Pair**
Buka terminal di mesin klien Anda dan jalankan perintah `ssh-keygen`:
Buka terminal di mesin klien dan jalankan perintah `ssh-keygen`:
*`ssh-keygen`: Perintah untuk menghasilkan, mengelola, dan mengonversi kunci autentikasi untuk SSH.
*`-t ed25519`: Menentukan jenis algoritma kunci yang akan digunakan. `ed25519` adalah algoritma yang lebih modern dan aman dibandingkan RSA, meskipun RSA dengan panjang kunci yang memadai (misalnya 4096 bit) masih aman.
*`-C "your_email@example.com_or_description"`: Menambahkan komentar ke kunci publik. Ini membantu Anda mengidentifikasi kunci, terutama jika Anda memiliki banyak kunci.
*`-C "your_email@example.com_or_description"`: Menambahkan komentar ke kunci publik. Ini membantu mengidentifikasi kunci, terutama jika memiliki banyak kunci.
**Contoh Output `ssh-keygen`:**
...
...
@@ -337,12 +337,12 @@ The key's randomart image is:
+----[SHA256]-----+
```
***`Enter file in which to save the key`**: Tekan `Enter` untuk menyimpan kunci di lokasi default (`~/.ssh/id_ed25519`). Jika Anda ingin menyimpan dengan nama atau lokasi lain, ketikkan di sini.
***`Enter passphrase`**: **Sangat disarankan** untuk memasukkan passphrase di sini. Passphrase ini akan melindungi kunci privat Anda. Meskipun kunci privat Anda dicuri, tanpa passphrase, kunci tersebut tidak dapat digunakan. Anggap ini sebagai kata sandi kedua untuk kunci Anda.
***`Enter file in which to save the key`**: Tekan `Enter` untuk menyimpan kunci di lokasi default (`~/.ssh/id_ed25519`). Jika ingin menyimpan dengan nama atau lokasi lain, ketikkan di sini.
***`Enter passphrase`**: **Sangat disarankan** untuk memasukkan passphrase di sini. Passphrase ini akan melindungi kunci privat. Meskipun kunci privat dicuri, tanpa passphrase, kunci tersebut tidak dapat digunakan. Anggap ini sebagai kata sandi kedua untuk kunci.
Setelah selesai, Anda akan memiliki dua file di direktori `~/.ssh/`:
*`id_ed25519`: Kunci privat Anda (HARUS DIJAGA KERAHASIAANNYA).
*`id_ed25519.pub`: Kunci publik Anda (yang akan kita letakkan di server).
Setelah selesai, akan memiliki dua file di direktori `~/.ssh/`:
*`ssh-copy-id`: Skrip yang menyalin kunci publik ke server remote dan menambahkannya ke file `~/.ssh/authorized_keys` di server. Ini juga mengatur izin file yang benar.
*`-i ~/.ssh/id_ed25519.pub`: Menentukan lokasi kunci publik yang akan disalin.
*`-p 22222`: Menentukan port SSH server Anda (port baru yang sudah kita konfigurasikan di Tahap 3).
*`<nama_pengguna>@<alamat_ip_server>`: Detail koneksi server Anda.
*`-p 22222`: Menentukan port SSH server (port baru yang sudah kita konfigurasikan di Tahap 3).
@@ -373,27 +373,27 @@ Now try logging into the machine, with: "ssh -p 22222 '<nama_pengguna>@<alamat
and check to see that only the key(s) you wanted were added.
```
Anda akan diminta untuk memasukkan kata sandi pengguna di server (`<nama_pengguna>@<alamat_ip_server>`). Setelah berhasil, kunci publik Anda akan ditambahkan ke file `~/.ssh/authorized_keys` di server.
akan diminta untuk memasukkan kata sandi pengguna di server (`<nama_pengguna>@<alamat_ip_server>`). Setelah berhasil, kunci publik akan ditambahkan ke file `~/.ssh/authorized_keys` di server.
**3. Uji Coba Koneksi dengan SSH Key**
**SEBELUM LOGOUT DARI SESI SSH YANG LAMA DI SERVER**, buka terminal baru di mesin klien Anda dan coba terhubung menggunakan SSH key:
**SEBELUM LOGOUT DARI SESI SSH YANG LAMA DI SERVER**, buka terminal baru di mesin klien dan coba terhubung menggunakan SSH key:
```bash
ssh -p 22222 <nama_pengguna>@<alamat_ip_server>
```
Jika Anda diminta passphrase, masukkan passphrase kunci privat Anda. Jika berhasil masuk tanpa diminta kata sandi server, berarti autentikasi dengan SSH key berhasil!
Jika diminta passphrase, masukkan passphrase kunci privat. Jika berhasil masuk tanpa diminta kata sandi server, berarti autentikasi dengan SSH key berhasil!
---
### Bagian B: Mengkonfigurasi SSH Server untuk Hanya Mengizinkan Autentikasi Kunci
Sekarang setelah Anda yakin bahwa Anda dapat masuk ke server menggunakan SSH key, kita dapat mengkonfigurasi server untuk melarang autentikasi kata sandi. Lakukan ini **di server Anda** dalam sesi SSH yang masih berjalan.
Sekarang setelah yakin bahwa dapat masuk ke server menggunakan SSH key, kita dapat mengkonfigurasi server untuk melarang autentikasi kata sandi. Lakukan ini **di server** dalam sesi SSH yang masih berjalan.
Buka kembali file `/etc/ssh/sshd_config` di server Anda:
Buka kembali file `/etc/ssh/sshd_config` di server:
```bash
sudo vi /etc/ssh/sshd_config
...
...
@@ -404,7 +404,7 @@ Cari dan/atau tambahkan/ubah parameter berikut:
***`PasswordAuthentication no`**:
***Definisi:** Mengontrol apakah otentikasi kata sandi diizinkan.
***Usecase:** Melarang penggunaan kata sandi untuk masuk via SSH, memaksa penggunaan SSH key.
***Skenario:** Ketika Anda hanya ingin mengizinkan metode otentikasi yang lebih kuat seperti kunci publik.
***Skenario:** Ketika hanya ingin mengizinkan metode otentikasi yang lebih kuat seperti kunci publik.
```
#PasswordAuthentication yes
...
...
@@ -415,7 +415,7 @@ Cari dan/atau tambahkan/ubah parameter berikut:
***`ChallengeResponseAuthentication no`**:
***Definisi:** Mengontrol apakah metode otentikasi berbasis tantangan/respons (misalnya, autentikasi PAM yang meminta kata sandi) diizinkan.
***Usecase:** Sering dikaitkan dengan `PasswordAuthentication` dan harus dimatikan jika hanya ingin menggunakan SSH key.
***Skenario:** Ketika Anda melarang autentikasi kata sandi dan tidak menggunakan metode tantangan/respons lainnya.
***Skenario:** Ketika melarang autentikasi kata sandi dan tidak menggunakan metode tantangan/respons lainnya.
```
#ChallengeResponseAuthentication yes
...
...
@@ -424,9 +424,9 @@ Cari dan/atau tambahkan/ubah parameter berikut:
Pastikan `yes` diubah menjadi `no` dan baris tidak dikomentari.
***`UsePAM no` (Opsional, tapi direkomendasikan untuk hardening maksimal)**:
***Definisi:** Mengontrol apakah modul PAM (Pluggable Authentication Modules) digunakan untuk autentikasi. PAM dapat menambahkan fleksibilitas tetapi juga kompleksitas dan potensi kerentanan jika tidak dikonfigurasi dengan benar. Jika Anda tidak memerlukan fitur PAM untuk SSH (seperti 2FA berbasis PAM), mematikannya dapat mengurangi permukaan serangan.
***Definisi:** Mengontrol apakah modul PAM (Pluggable Authentication Modules) digunakan untuk autentikasi. PAM dapat menambahkan fleksibilitas tetapi juga kompleksitas dan potensi kerentanan jika tidak dikonfigurasi dengan benar. Jika tidak memerlukan fitur PAM untuk SSH (seperti 2FA berbasis PAM), mematikannya dapat mengurangi permukaan serangan.
***Usecase:** Untuk memastikan bahwa autentikasi SSH sepenuhnya ditangani oleh SSH itu sendiri dan tidak bergantung pada PAM.
***Skenario:** Ketika Anda ingin meminimalkan dependensi dan hanya mengandalkan autentikasi kunci SSH.
***Skenario:** Ketika ingin meminimalkan dependensi dan hanya mengandalkan autentikasi kunci SSH.
```
#UsePAM yes
...
...
@@ -479,21 +479,21 @@ sudo systemctl restart sshd
**Validasi (Skenario Krusial):**
**SEBELUM LOGOUT DARI SESI SSH SAAT INI DI SERVER**, buka terminal baru di mesin klien Anda dan coba terhubung ke server.
**SEBELUM LOGOUT DARI SESI SSH SAAT INI DI SERVER**, buka terminal baru di mesin klien dan coba terhubung ke server.
***Uji Koneksi Menggunakan SSH Key (Harus Berhasil):**
```bash
ssh -p 22222 <nama_pengguna>@<alamat_ip_server>
```
Jika Anda dapat masuk, autentikasi kunci publik Anda berfungsi.
Jika dapat masuk, autentikasi kunci publik berfungsi.
***Uji Koneksi Menggunakan Kata Sandi (Harus Gagal):**
```bash
ssh -p 22222 <nama_pengguna>@<alamat_ip_server>
```
Kali ini, coba masukkan kata sandi Anda jika diminta. Anda seharusnya tidak diminta kata sandi, atau jika diminta, koneksi harus ditolak dengan pesan seperti "Permission denied (publickey)". Ini mengkonfirmasi bahwa autentikasi kata sandi telah dinonaktifkan.
Kali ini, coba masukkan kata sandi jika diminta. seharusnya tidak diminta kata sandi, atau jika diminta, koneksi harus ditolak dengan pesan seperti "Permission denied (publickey)". Ini mengkonfirmasi bahwa autentikasi kata sandi telah dinonaktifkan.
Jika Anda masih bisa login dengan kata sandi, berarti ada kesalahan dalam konfigurasi Anda. Jangan keluar dari sesi lama Anda dan perbaiki masalahnya.
Jika masih bisa login dengan kata sandi, berarti ada kesalahan dalam konfigurasi. Jangan keluar dari sesi lama dan perbaiki masalahnya.
---
...
...
@@ -503,7 +503,7 @@ Setelah kita beralih ke autentikasi SSH key, langkah hardening berikutnya adalah
#### Mengapa Melarang Login Root Langsung?
1. **Mengurangi Permukaan Serangan:** Akun `root` adalah akun paling istimewa di sistem Linux. Jika penyerang berhasil mendapatkan akses ke akun `root` secara langsung, mereka akan memiliki kendali penuh atas server Anda. Dengan melarang login root langsung, penyerang harus terlebih dahulu mendapatkan akses ke akun pengguna biasa, lalu melakukan eskalasi hak istimewa (misalnya dengan `sudo`) untuk mendapatkan akses root. Ini adalah dua langkah, bukan satu.
1. **Mengurangi Permukaan Serangan:** Akun `root` adalah akun paling istimewa di sistem Linux. Jika penyerang berhasil mendapatkan akses ke akun `root` secara langsung, mereka akan memiliki kendali penuh atas server. Dengan melarang login root langsung, penyerang harus terlebih dahulu mendapatkan akses ke akun pengguna biasa, lalu melakukan eskalasi hak istimewa (misalnya dengan `sudo`) untuk mendapatkan akses root. Ini adalah dua langkah, bukan satu.
2. **Auditabilitas yang Lebih Baik:** Semua aktivitas yang dilakukan setelah login sebagai pengguna biasa dan kemudian menggunakan `sudo` akan dicatat dan dihubungkan dengan akun pengguna tersebut. Ini membuat audit dan pelacakan aktivitas jauh lebih mudah.
3. **Mencegah Kesalahan yang Tidak Disengaja:** Bekerja sebagai `root` secara langsung meningkatkan risiko melakukan kesalahan fatal yang dapat merusak sistem.
...
...
@@ -516,18 +516,18 @@ Setelah kita beralih ke autentikasi SSH key, langkah hardening berikutnya adalah
**1. Verifikasi Adanya Akun Pengguna Biasa dengan Hak `sudo`**
Sebelum Anda melarang login root, **pastikan** Anda memiliki setidaknya satu akun pengguna biasa yang:
Sebelum melarang login root, **pastikan** memiliki setidaknya satu akun pengguna biasa yang:
* Sudah memiliki SSH key di server (seperti yang kita lakukan di Tahap 4).
* Memiliki hak istimewa `sudo` untuk melakukan perintah administratif.
Anda dapat memeriksa apakah pengguna Anda memiliki hak `sudo` dengan mencoba perintah `sudo`:
dapat memeriksa apakah pengguna memiliki hak `sudo` dengan mencoba perintah `sudo`:
```bash
sudo ls /root
```
Jika Anda diminta kata sandi (untuk pengguna biasa Anda) dan kemudian perintah berhasil dieksekusi, berarti pengguna Anda memiliki hak `sudo`.
Jika diminta kata sandi (untuk pengguna biasa) dan kemudian perintah berhasil dieksekusi, berarti pengguna memiliki hak `sudo`.
Jika Anda belum memiliki pengguna seperti itu, Anda perlu membuatnya:
Jika belum memiliki pengguna seperti itu, perlu membuatnya:
```bash
# Tambahkan pengguna baru
...
...
@@ -539,9 +539,9 @@ sudo passwd newuser
# Tambahkan pengguna ke grup 'wheel' (grup sudo di Rocky Linux)
sudo usermod -aG wheel newuser
# PENTING: Salin kunci SSH publik Anda ke pengguna baru ini juga!
# Anda perlu login sebagai 'newuser' atau menyalinnya secara manual
# Untuk melakukannya secara manual dari akun pengguna biasa Anda:
# PENTING: Salin kunci SSH publik ke pengguna baru ini juga!
# perlu login sebagai 'newuser' atau menyalinnya secara manual
# Untuk melakukannya secara manual dari akun pengguna biasa:
Pastikan Anda dapat login dengan `newuser` menggunakan SSH key sebelum melanjutkan.
Pastikan dapat login dengan `newuser` menggunakan SSH key sebelum melanjutkan.
**2. Melarang Login Root Langsung**
...
...
@@ -567,7 +567,7 @@ Cari dan ubah parameter `PermitRootLogin`:
* **Definisi:** Parameter ini mengontrol apakah akun `root` dapat langsung login melalui SSH.
* **Nilai Default:** `prohibit-password` (artinya root bisa login dengan SSH key, tetapi tidak dengan kata sandi). Kita ingin membuatnya lebih ketat menjadi `no`.
* **Usecase:** Untuk mencegah penyerang langsung menargetkan akun `root`. Pengguna harus login sebagai pengguna biasa dan kemudian menggunakan `sudo` atau `su`.
* **Skenario:** Ketika Anda ingin meningkatkan keamanan dengan menambahkan lapisan pertahanan ekstra terhadap akses `root` yang tidak sah.
* **Skenario:** Ketika ingin meningkatkan keamanan dengan menambahkan lapisan pertahanan ekstra terhadap akses `root` yang tidak sah.
```
#PermitRootLogin prohibit-password
...
...
@@ -582,7 +582,7 @@ Ada dua cara untuk membatasi akses pengguna:
* **`AllowUsers`**: Hanya daftar pengguna yang ditentukan yang diizinkan untuk login via SSH. Ini adalah cara yang paling ketat.
* **`AllowGroups`**: Hanya anggota dari grup yang ditentukan yang diizinkan untuk login via SSH. Ini lebih fleksibel untuk lingkungan dengan banyak pengguna.
Pilih salah satu sesuai kebutuhan Anda. Jika Anda memiliki pengguna bernama `sysadmin` dan `devuser`, dan Anda ingin hanya mereka yang bisa login SSH:
Pilih salah satu sesuai kebutuhan. Jika memiliki pengguna bernama `sysadmin` dan `devuser`, dan ingin hanya mereka yang bisa login SSH:
* **Opsi A: Menggunakan `AllowUsers`**
Tambahkan baris ini di akhir file `sshd_config`:
...
...
@@ -595,7 +595,7 @@ Pilih salah satu sesuai kebutuhan Anda. Jika Anda memiliki pengguna bernama `sys
* **Skenario:** Cocok untuk server dengan jumlah pengguna SSH yang terbatas dan terdefinisi dengan jelas.
* **Opsi B: Menggunakan `AllowGroups`**
Jika Anda ingin semua anggota dari grup `sshusers` (Anda harus membuat grup ini terlebih dahulu) dapat login, tambahkan baris ini:
Jika ingin semua anggota dari grup `sshusers` (harus membuat grup ini terlebih dahulu) dapat login, tambahkan baris ini:
```bash
# Di server, buat grup 'sshusers' jika belum ada
...
...
@@ -609,10 +609,10 @@ Pilih salah satu sesuai kebutuhan Anda. Jika Anda memiliki pengguna bernama `sys
AllowGroups sshusers
```
* **Definisi:** Mengizinkan hanya anggota dari grup yang terdaftar untuk login via SSH.
* **Usecase:** Lebih mudah dikelola untuk lingkungan dengan banyak pengguna, di mana Anda dapat menambahkan/menghapus pengguna dari grup daripada mengedit `sshd_config` setiap saat.
* **Skenario:** Cocok untuk lingkungan tim di mana beberapa orang perlu akses SSH dan Anda ingin mengelola izin melalui keanggotaan grup.
* **Usecase:** Lebih mudah dikelola untuk lingkungan dengan banyak pengguna, di mana dapat menambahkan/menghapus pengguna dari grup daripada mengedit `sshd_config` setiap saat.
* **Skenario:** Cocok untuk lingkungan tim di mana beberapa orang perlu akses SSH dan ingin mengelola izin melalui keanggotaan grup.
**PENTING:** Jika Anda menggunakan `AllowGroups`, pastikan pengguna yang Anda gunakan untuk login saat ini termasuk dalam grup yang diizinkan, jika tidak Anda akan terkunci!
**PENTING:** Jika menggunakan `AllowGroups`, pastikan pengguna yang gunakan untuk login saat ini termasuk dalam grup yang diizinkan, jika tidak akan terkunci!
**4. Menyimpan dan Keluar dari Editor**
...
...
@@ -629,27 +629,27 @@ sudo systemctl restart sshd
**Validasi (Skenario Krusial):**
**SEBELUM LOGOUT DARI SESI SSH SAAT INI DI SERVER**, buka terminal baru di mesin klien Anda dan coba terhubung.
**SEBELUM LOGOUT DARI SESI SSH SAAT INI DI SERVER**, buka terminal baru di mesin klien dan coba terhubung.
* **Coba Login sebagai Pengguna Biasa yang Diizinkan (Harus Berhasil):**
Anda seharusnya mendapatkan pesan "Permission denied (publickey)".
seharusnya mendapatkan pesan "Permission denied (publickey)".
Jika ada masalah, perbaiki `sshd_config` dalam sesi SSH lama Anda yang masih berjalan.
Jika ada masalah, perbaiki `sshd_config` dalam sesi SSH lama yang masih berjalan.
---
...
...
@@ -659,7 +659,7 @@ Langkah-langkah hardening ini bertujuan untuk mencegah sesi SSH yang tidak aktif
#### Mengapa Timeout Sesi Penting?
* **Mengurangi Risiko Akses Tidak Sah:** Sesi SSH yang terbuka dan tidak diawasi dapat menjadi risiko keamanan. Jika workstation Anda ditinggalkan tanpa pengawasan dan sesi SSH tetap aktif, siapa pun yang memiliki akses fisik ke workstation Anda dapat mengakses server Anda.
* **Mengurangi Risiko Akses Tidak Sah:** Sesi SSH yang terbuka dan tidak diawasi dapat menjadi risiko keamanan. Jika workstation ditinggalkan tanpa pengawasan dan sesi SSH tetap aktif, siapa pun yang memiliki akses fisik ke workstation dapat mengakses server.
* **Mengurangi Sumber Daya yang Terpakai:** Sesi yang tidak aktif tetap menggunakan sumber daya server. Meskipun dampaknya kecil, ini adalah praktik manajemen sumber daya yang baik.
* **Skenario Penggunaan:** Sangat berguna di lingkungan di mana pengguna seringkali lupa untuk memutuskan koneksi SSH mereka.
...
...
@@ -694,7 +694,7 @@ Cari dan/atau tambahkan/ubah parameter berikut:
* **`ClientAliveCountMax 0`**:
* **Definisi:** Ini adalah jumlah pesan keepalive yang akan dikirim server tanpa menerima respons dari klien sebelum memutuskan koneksi. Jika `ClientAliveCountMax` tercapai, SSH server akan memutuskan klien, mengakhiri sesi.
* **Usecase:** Digunakan bersama dengan `ClientAliveInterval` untuk menentukan total waktu idle sebelum sesi diputus.
* **Skenario:** Jika `ClientAliveInterval` adalah 300 detik dan `ClientAliveCountMax` adalah 0, ini berarti begitu pesan keepalive pertama tidak dijawab, koneksi akan langsung diputus. Jika Anda ingin memberikan kesempatan lebih, atur ke 1, 2, atau 3. Namun, untuk hardening, 0 adalah yang paling ketat.
* **Skenario:** Jika `ClientAliveInterval` adalah 300 detik dan `ClientAliveCountMax` adalah 0, ini berarti begitu pesan keepalive pertama tidak dijawab, koneksi akan langsung diputus. Jika ingin memberikan kesempatan lebih, atur ke 1, 2, atau 3. Namun, untuk hardening, 0 adalah yang paling ketat.
```
#ClientAliveCountMax 3
...
...
@@ -761,19 +761,19 @@ sudo systemctl restart sshd
**Validasi:**
Untuk memvalidasi `ClientAliveInterval` dan `ClientAliveCountMax`, Anda dapat:
Untuk memvalidasi `ClientAliveInterval` dan `ClientAliveCountMax`, dapat:
1. Login ke server melalui SSH.
2. Biarkan terminal idle (jangan ketik apa pun) selama lebih dari 5 menit.
3. Anda seharusnya akan terputus dari server.
3. seharusnya akan terputus dari server.
Untuk memvalidasi `MaxAuthTries` dan `MaxStartups`:
* Ini lebih sulit divalidasi secara langsung tanpa simulasi serangan. Namun, Anda dapat mencoba login dengan sengaja salah beberapa kali dari terminal klien baru. Anda seharusnya akan terputus setelah 3 upaya.
* Anda juga bisa memantau log `/var/log/secure` untuk melihat pesan yang terkait dengan pemutusan koneksi atau penolakan autentikasi.
* Ini lebih sulit divalidasi secara langsung tanpa simulasi serangan. Namun, dapat mencoba login dengan sengaja salah beberapa kali dari terminal klien baru. seharusnya akan terputus setelah 3 upaya.
* juga bisa memantau log `/var/log/secure` untuk melihat pesan yang terkait dengan pemutusan koneksi atau penolakan autentikasi.
```bash
sudo tail -f /var/log/secure
```
Coba login dan sengaja salah memasukkan passphrase beberapa kali. Anda akan melihat pesan seperti `Disconnected from authenticating user <user> <ip_address> port <port> [preauth]` atau `Failed password for <user> from <ip_address> port <port> ssh2`.
Coba login dan sengaja salah memasukkan passphrase beberapa kali. akan melihat pesan seperti `Disconnected from authenticating user <user> <ip_address> port <port> [preauth]` atau `Failed password for <user> from <ip_address> port <port> ssh2`.
---
...
...
@@ -881,13 +881,13 @@ sudo systemctl restart sshd
**Validasi:**
Untuk memvalidasi bahwa server Anda menggunakan algoritma yang Anda tentukan, Anda dapat menggunakan perintah `ssh` dengan opsi verbose (`-v`) dari mesin klien Anda, atau menggunakan alat `ssh-audit`.
Untuk memvalidasi bahwa server menggunakan algoritma yang tentukan, dapat menggunakan perintah `ssh` dengan opsi verbose (`-v`) dari mesin klien, atau menggunakan alat `ssh-audit`.
Perhatikan output verbose yang menunjukkan algoritma apa yang sedang dinegosiasikan dan digunakan. Anda akan melihat baris seperti:
Perhatikan output verbose yang menunjukkan algoritma apa yang sedang dinegosiasikan dan digunakan. akan melihat baris seperti:
```
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
...
...
@@ -902,7 +902,7 @@ Untuk memvalidasi bahwa server Anda menggunakan algoritma yang Anda tentukan, An
* **Menggunakan `ssh-audit` (Direkomendasikan):**
`ssh-audit` adalah alat yang sangat baik untuk menganalisis konfigurasi keamanan server SSH.
Anda dapat menginstalnya di mesin klien Anda (jika belum ada):
dapat menginstalnya di mesin klien (jika belum ada):
```bash
# Di klien (misalnya, di Linux atau WSL)
...
...
@@ -910,13 +910,13 @@ Untuk memvalidasi bahwa server Anda menggunakan algoritma yang Anda tentukan, An
# Atau jika menggunakan Python 3
pip3 install ssh-audit
```
Setelah terinstal, jalankan dari klien Anda:
Setelah terinstal, jalankan dari klien:
```bash
ssh-audit -p 22222 <alamat_ip_server>
```
`ssh-audit` akan memberikan laporan terperinci tentang protokol, cipher, MAC, KexAlgorithms, dan pengaturan lainnya yang digunakan oleh server SSH Anda, serta rekomendasi untuk peningkatannya. Pastikan output menunjukkan bahwa semua algoritma yang Anda pilih adalah "strong" atau "good".
`ssh-audit` akan memberikan laporan terperinci tentang protokol, cipher, MAC, KexAlgorithms, dan pengaturan lainnya yang digunakan oleh server SSH, serta rekomendasi untuk peningkatannya. Pastikan output menunjukkan bahwa semua algoritma yang pilih adalah "strong" atau "good".
**Contoh Output `ssh-audit` (parsial):**
```
...
...
@@ -953,8 +953,8 @@ Cari dan/atau tambahkan/ubah parameter berikut:
**1. Batasi Fungsionalitas yang Tidak Perlu**
* **`X11Forwarding no`**:
* **Definisi:** Mengontrol apakah X11 forwarding diizinkan. X11 forwarding memungkinkan aplikasi GUI dari server untuk ditampilkan di klien lokal Anda.
* **Usecase:** Jika server Anda adalah server headless (tanpa GUI) atau Anda tidak pernah perlu menjalankan aplikasi GUI dari server melalui SSH, matikan ini untuk mengurangi risiko.
* **Definisi:** Mengontrol apakah X11 forwarding diizinkan. X11 forwarding memungkinkan aplikasi GUI dari server untuk ditampilkan di klien lokal.
* **Usecase:** Jika server adalah server headless (tanpa GUI) atau tidak pernah perlu menjalankan aplikasi GUI dari server melalui SSH, matikan ini untuk mengurangi risiko.
* **Skenario:** Kebanyakan server hanya membutuhkan akses CLI, jadi mematikan X11 forwarding adalah praktik keamanan yang baik.
```
...
...
@@ -963,9 +963,9 @@ Cari dan/atau tambahkan/ubah parameter berikut:
```
* **`AllowAgentForwarding no`**:
* **Definisi:** Mengontrol apakah agent forwarding diizinkan. Agent forwarding memungkinkan Anda menggunakan kunci SSH lokal Anda untuk terhubung dari server ke server lain (seolah-olah kunci Anda ada di server perantara).
* **Usecase:** Meskipun nyaman, agent forwarding dapat menjadi risiko keamanan jika server perantara yang Anda masuki disusupi. Penyerang mungkin dapat memanfaatkan agent Anda untuk mengakses server lain.
* **Skenario:** Matikan jika Anda tidak memerlukan kemampuan untuk "melompati" dari satu server ke server lain menggunakan SSH agent Anda. Jika Anda membutuhkannya, pastikan Anda memahami risikonya.
* **Definisi:** Mengontrol apakah agent forwarding diizinkan. Agent forwarding memungkinkan menggunakan kunci SSH lokal untuk terhubung dari server ke server lain (seolah-olah kunci ada di server perantara).
* **Usecase:** Meskipun nyaman, agent forwarding dapat menjadi risiko keamanan jika server perantara yang masuki disusupi. Penyerang mungkin dapat memanfaatkan agent untuk mengakses server lain.
* **Skenario:** Matikan jika tidak memerlukan kemampuan untuk "melompati" dari satu server ke server lain menggunakan SSH agent. Jika membutuhkannya, pastikan memahami risikonya.
```
#AllowAgentForwarding yes
...
...
@@ -974,18 +974,18 @@ Cari dan/atau tambahkan/ubah parameter berikut:
* **`AllowTcpForwarding no`**:
* **Definisi:** Mengontrol apakah TCP forwarding (port forwarding atau tunneling) diizinkan. Ini memungkinkan pengguna untuk membuat terowongan melalui SSH untuk layanan lain.
* **Usecase:** Serangan tunneling bisa digunakan untuk melewati firewall atau mengakses layanan internal yang seharusnya tidak terekspos. Jika Anda tidak memerlukan fitur ini (misalnya, untuk tunneling database atau VPN sederhana melalui SSH), matikan.
* **Usecase:** Serangan tunneling bisa digunakan untuk melewati firewall atau mengakses layanan internal yang seharusnya tidak terekspos. Jika tidak memerlukan fitur ini (misalnya, untuk tunneling database atau VPN sederhana melalui SSH), matikan.
* **Skenario:** Matikan untuk server yang hanya berfungsi sebagai host CLI, tanpa kebutuhan tunneling data aplikasi.
```
#AllowTcpForwarding yes
AllowTcpForwarding no
```
**Catatan Penting:** Jika Anda menggunakan SFTP atau SCP untuk transfer file, ini mungkin akan terpengaruh jika Anda menyetel `AllowTcpForwarding no`. Namun, SFTP/SCP biasanya tidak mengandalkan TCP forwarding dalam arti yang sama; mereka menggunakan subsistem SSH. Jika SFTP/SCP Anda berhenti bekerja, Anda mungkin perlu mengaktifkan `AllowTcpForwarding yes` atau mempertimbangkan `PermitTunnel no`. Biasanya, `AllowTcpForwarding no` tidak memblokir SFTP.
**Catatan Penting:** Jika menggunakan SFTP atau SCP untuk transfer file, ini mungkin akan terpengaruh jika menyetel `AllowTcpForwarding no`. Namun, SFTP/SCP biasanya tidak mengandalkan TCP forwarding dalam arti yang sama; mereka menggunakan subsistem SSH. Jika SFTP/SCP berhenti bekerja, mungkin perlu mengaktifkan `AllowTcpForwarding yes` atau mempertimbangkan `PermitTunnel no`. Biasanya, `AllowTcpForwarding no` tidak memblokir SFTP.
* **`PermitTunnel no`**:
* **Definisi:** Mengontrol apakah perangkat tunnel (TUN/TAP) dapat dibuat. Ini digunakan untuk VPN SSH.
* **Usecase:** Jika Anda tidak menggunakan SSH sebagai VPN, matikan ini.
* **Usecase:** Jika tidak menggunakan SSH sebagai VPN, matikan ini.
* **Skenario:** Mematikan fitur ini untuk server yang tidak memerlukan fungsi VPN.
```
...
...
@@ -996,7 +996,7 @@ Cari dan/atau tambahkan/ubah parameter berikut:
* **`PermitUserEnvironment no`**:
* **Definisi:** Mengontrol apakah `sshd` akan memproses file `~/.ssh/environment` dan variabel lingkungan `environment=` dari `authorized_keys`.
* **Usecase:** Ini bisa menjadi risiko keamanan jika penyerang dapat memodifikasi variabel lingkungan untuk mengeksekusi kode berbahaya.
* **Skenario:** Secara umum, matikan ini kecuali Anda memiliki kasus penggunaan yang sangat spesifik dan aman.
* **Skenario:** Secara umum, matikan ini kecuali memiliki kasus penggunaan yang sangat spesifik dan aman.
Setelah me-restart SSH, coba login dan logout beberapa kali. Kemudian periksa file log keamanan Anda:
Setelah me-restart SSH, coba login dan logout beberapa kali. Kemudian periksa file log keamanan:
```bash
sudo tail /var/log/secure
```
Anda akan melihat lebih banyak detail logging dibandingkan sebelumnya, termasuk informasi tentang keberhasilan atau kegagalan autentikasi, negosiasi algoritma, dll.
akan melihat lebih banyak detail logging dibandingkan sebelumnya, termasuk informasi tentang keberhasilan atau kegagalan autentikasi, negosiasi algoritma, dll.
**Contoh Log dengan `LogLevel VERBOSE`:**
...
...
@@ -1062,8 +1062,8 @@ sudo systemctl restart sshd
```
* **Verifikasi Pembatasan Fungsionalitas:**
Ini lebih sulit divalidasi langsung dari terminal. Namun, Anda dapat mencoba fitur-fitur yang Anda nonaktifkan:
* **X11 Forwarding:** Coba jalankan aplikasi GUI dari server ke klien Anda (misalnya, `ssh -X -p 22222 user@ip xclock`). Jika X11Forwarding dimatikan, ini seharusnya gagal atau menampilkan pesan error.
Ini lebih sulit divalidasi langsung dari terminal. Namun, dapat mencoba fitur-fitur yang nonaktifkan:
* **X11 Forwarding:** Coba jalankan aplikasi GUI dari server ke klien (misalnya, `ssh -X -p 22222 user@ip xclock`). Jika X11Forwarding dimatikan, ini seharusnya gagal atau menampilkan pesan error.
* **Agent Forwarding:** Ini membutuhkan skenario server ke server yang lebih kompleks.
---
...
...
@@ -1114,7 +1114,7 @@ PermitUserEnvironment no # Nonaktifkan pemrosesan file l
# AllowGroups <group1> <group2> # Contoh: Hanya izinkan anggota group1 dan group2
```
**Penting:** Selalu pastikan Anda memiliki setidaknya satu user yang diizinkan untuk login SSH dengan SSH Key yang valid sebelum menerapkan konfigurasi `PermitRootLogin no`, `PasswordAuthentication no`, dan `AllowUsers` / `AllowGroups`.
**Penting:** Selalu pastikan memiliki setidaknya satu user yang diizinkan untuk login SSH dengan SSH Key yang valid sebelum menerapkan konfigurasi `PermitRootLogin no`, `PasswordAuthentication no`, dan `AllowUsers` / `AllowGroups`.
#### Persiapan untuk Skrip Otomatisasi
...
...
@@ -1147,9 +1147,9 @@ Skrip bash berikut akan mengimplementasikan semua langkah hardening SSH yang tel
**Penting Sebelum Menjalankan Skrip:**
1. **Baca Skrip dengan Seksama:** Pahami setiap bagian dari skrip sebelum menjalankannya.
2. **Pastikan SSH Key Anda Sudah Terpasang:** Skrip ini akan menonaktifkan autentikasi kata sandi. Pastikan Anda sudah dapat login dengan SSH Key ke **semua pengguna** yang ingin Anda akses (termasuk pengguna yang memiliki hak `sudo`) sebelum menjalankan skrip ini.
3. **Pastikan Ada Pengguna dengan `sudo`:** Skrip ini akan melarang login root. Pastikan Anda memiliki setidaknya satu akun pengguna biasa dengan SSH key yang diinstal dan hak `sudo`.
4. **Siapkan `AllowUsers` / `AllowGroups`:** Jika Anda ingin menggunakan `AllowUsers` atau `AllowGroups`, siapkan daftarnya sebelum menjalankan skrip. Jika tidak, skrip akan mengkomentari opsi ini secara default.
2. **Pastikan SSH Key Sudah Terpasang:** Skrip ini akan menonaktifkan autentikasi kata sandi. Pastikan sudah dapat login dengan SSH Key ke **semua pengguna** yang ingin akses (termasuk pengguna yang memiliki hak `sudo`) sebelum menjalankan skrip ini.
3. **Pastikan Ada Pengguna dengan `sudo`:** Skrip ini akan melarang login root. Pastikan memiliki setidaknya satu akun pengguna biasa dengan SSH key yang diinstal dan hak `sudo`.
4. **Siapkan `AllowUsers` / `AllowGroups`:** Jika ingin menggunakan `AllowUsers` atau `AllowGroups`, siapkan daftarnya sebelum menjalankan skrip. Jika tidak, skrip akan mengkomentari opsi ini secara default.
5. **Selalu Gunakan Mode Dry Run Terlebih Dahulu:** Jalankan skrip dengan opsi `--dry-run` untuk melihat perubahan apa yang akan dilakukan tanpa benar-benar menerapkannya.
Periksa outputnya dengan cermat. Pastikan Anda memahami semua perubahan yang akan dilakukan. Jika ada pesan `(Dry Run)`, itu berarti perintahnya tidak benar-benar dieksekusi.
Periksa outputnya dengan cermat. Pastikan memahami semua perubahan yang akan dilakukan. Jika ada pesan `(Dry Run)`, itu berarti perintahnya tidak benar-benar dieksekusi.
Pastikan untuk mengganti `youruser` dengan nama pengguna Anda sendiri yang memiliki SSH key dan hak `sudo`.
Pastikan untuk mengganti `youruser` dengan nama pengguna sendiri yang memiliki SSH key dan hak `sudo`.
5. **UJI KONEKSI SEGERA!**
Buka terminal baru di mesin klien Anda dan coba masuk ke server menggunakan port dan pengguna baru:
Buka terminal baru di mesin klien dan coba masuk ke server menggunakan port dan pengguna baru:
```bash
ssh -p 22222 youruser@<IP_SERVER_ANDA>
```
Jika berhasil, Anda aman untuk menutup sesi SSH lama Anda. Jika tidak, kembali ke sesi lama Anda, pulihkan backup (`sudo cp /etc/ssh/sshd_config.bak_<timestamp> /etc/ssh/sshd_config`), perbaiki masalah, dan coba lagi.
Jika berhasil, aman untuk menutup sesi SSH lama. Jika tidak, kembali ke sesi lama, pulihkan backup (`sudo cp /etc/ssh/sshd_config.bak_<timestamp> /etc/ssh/sshd_config`), perbaiki masalah, dan coba lagi.
@@ -11,8 +11,8 @@ Fail2Ban adalah sebuah framework pencegah intrusi berbasis log yang memindai fil
Meskipun kita sudah melakukan banyak langkah hardening SSH (mengubah port, SSH Key, dll.), Fail2Ban menambahkan lapisan keamanan yang proaktif dan reaktif:
1.**Pertahanan Reaktif Terhadap Brute-Force:** Ini adalah fungsi utamanya. Jika ada penyerang yang mencoba SSH key yang berbeda-beda, atau jika ada port scanner yang menemukan port SSH baru Anda dan mencoba brute-force, Fail2Ban akan mendeteksi upaya login yang gagal dan secara otomatis memblokir IP tersebut.
2.**Mengurangi Beban Server:** Dengan memblokir penyerang sejak dini, Anda mengurangi beban pada server karena upaya autentikasi yang berulang tidak akan sampai ke daemon SSH lagi.
1.**Pertahanan Reaktif Terhadap Brute-Force:** Ini adalah fungsi utamanya. Jika ada penyerang yang mencoba SSH key yang berbeda-beda, atau jika ada port scanner yang menemukan port SSH baru dan mencoba brute-force, Fail2Ban akan mendeteksi upaya login yang gagal dan secara otomatis memblokir IP tersebut.
2.**Mengurangi Beban Server:** Dengan memblokir penyerang sejak dini, mengurangi beban pada server karena upaya autentikasi yang berulang tidak akan sampai ke daemon SSH lagi.
3.**Melengkapi Keamanan SSH Key:** Meskipun SSH Key sangat kuat, penyerang masih bisa mencoba menargetkan pengguna yang memiliki SSH Key. Fail2Ban akan mencegah upaya-upaya ini.
4.**Fleksibilitas:** Fail2Ban dapat dikonfigurasi untuk memantau berbagai layanan, tidak hanya SSH, menjadikannya alat keamanan yang serbaguna.
5.**Konteks 5W1H:**
...
...
@@ -28,7 +28,7 @@ Meskipun kita sudah melakukan banyak langkah hardening SSH (mengubah port, SSH K
1.**Rocky Linux 10:** Sistem operasi target.
2.**Akses Root atau `sudo`:** Diperlukan untuk instalasi dan konfigurasi.
3.**`firewalld` Aktif dan Berjalan:** Fail2Ban akan berinteraksi dengan `firewalld` untuk menerapkan blokir IP. Pastikan `firewalld` sudah terinstal dan berjalan (seperti yang kita konfigurasikan di tahap hardening SSH sebelumnya).
4.**Port SSH Kustom:** Asumsi bahwa Anda sudah mengubah port SSH default (misalnya ke 22222) seperti yang kita lakukan di tutorial sebelumnya. Fail2Ban akan dikonfigurasi untuk memantau port ini.
4.**Port SSH Kustom:** Asumsi bahwa sudah mengubah port SSH default (misalnya ke 22222) seperti yang kita lakukan di tutorial sebelumnya. Fail2Ban akan dikonfigurasi untuk memantau port ini.
5.**SSH Server Berjalan:** Daemon OpenSSH (`sshd`) harus berjalan dan aktif agar Fail2Ban dapat memantau log-nya.
#### Arsitektur Fail2Ban (Dependency & Use Case)
...
...
@@ -42,7 +42,7 @@ Fail2Ban terdiri dari beberapa komponen utama:
***Actions (`/etc/fail2ban/action.d/`):** File yang mendefinisikan tindakan yang harus diambil saat IP diblokir (misalnya, menggunakan `firewalld`, `iptables`, atau mengirim email).
**Contoh Skenario:**
Seorang penyerang mencoba login SSH ke server Anda pada port 22222 dengan pengguna `admin` dan kata sandi yang salah.
Seorang penyerang mencoba login SSH ke server pada port 22222 dengan pengguna `admin` dan kata sandi yang salah.
1. Server SSH mencatat upaya gagal ini di `/var/log/secure`.
2. Daemon `fail2ban-server` memindai `/var/log/secure` dan mendeteksi pola "failed password for admin" yang cocok dengan filter `sshd`.
3. Jika penyerang melakukan ini 3 kali (sesuai `maxretry`) dalam waktu 10 menit (sesuai `findtime`), Fail2Ban akan memicu `action`.
...
...
@@ -63,7 +63,7 @@ Fail2Ban bukanlah bagian dari instalasi minimal Rocky Linux secara default. Oleh
**1. Update Repositori Sistem (Opsional, tapi direkomendasikan)**
Selalu merupakan praktik yang baik untuk memperbarui indeks paket repositori sistem Anda sebelum menginstal paket baru. Ini memastikan Anda mendapatkan versi paket terbaru yang tersedia dan menghindari masalah dependensi.
Selalu merupakan praktik yang baik untuk memperbarui indeks paket repositori sistem sebelum menginstal paket baru. Ini memastikan mendapatkan versi paket terbaru yang tersedia dan menghindari masalah dependensi.
```bash
sudo dnf update -y
...
...
@@ -146,7 +146,7 @@ Complete!
**Validasi Instalasi:**
Setelah instalasi selesai, Anda dapat memverifikasi bahwa Fail2Ban telah terinstal dengan benar dengan memeriksa versi paket:
Setelah instalasi selesai, dapat memverifikasi bahwa Fail2Ban telah terinstal dengan benar dengan memeriksa versi paket:
```bash
rpm -q fail2ban
...
...
@@ -156,7 +156,7 @@ rpm -q fail2ban
```
fail2ban-1.0.2-1.el9.noarch
```
Jika Anda melihat output versi seperti di atas, artinya instalasi berhasil.
Jika melihat output versi seperti di atas, artinya instalasi berhasil.
**3. Aktifkan dan Mulai Layanan Fail2Ban**
...
...
@@ -194,17 +194,17 @@ sudo systemctl status fail2ban
Cari `Active: active (running)`. Jika Anda melihat ini, layanan Fail2Ban Anda berjalan dengan sukses.
Cari `Active: active (running)`. Jika melihat ini, layanan Fail2Ban berjalan dengan sukses.
---
### Tahap 3: Konfigurasi Fail2Ban (Jail dan Filter)
Pada tahap ini, kita akan mengkonfigurasi Fail2Ban untuk memantau upaya login SSH yang gagal di port kustom Anda. Fail2Ban menggunakan konsep "jail" untuk menentukan layanan mana yang akan dimonitor dan bagaimana cara menangani insiden.
Pada tahap ini, kita akan mengkonfigurasi Fail2Ban untuk memantau upaya login SSH yang gagal di port kustom. Fail2Ban menggunakan konsep "jail" untuk menentukan layanan mana yang akan dimonitor dan bagaimana cara menangani insiden.
#### Struktur Konfigurasi Fail2Ban
Fail2Ban memiliki file konfigurasi utama `/etc/fail2ban/jail.conf`. **Penting:** Jangan langsung mengedit `jail.conf`. Sebaliknya, buat file `jail.local` atau file di direktori `jail.d/` untuk menimpa atau menambahkan konfigurasi. Ini adalah praktik terbaik agar konfigurasi Anda tidak hilang saat Fail2Ban di-update.
Fail2Ban memiliki file konfigurasi utama `/etc/fail2ban/jail.conf`. **Penting:** Jangan langsung mengedit `jail.conf`. Sebaliknya, buat file `jail.local` atau file di direktori `jail.d/` untuk menimpa atau menambahkan konfigurasi. Ini adalah praktik terbaik agar konfigurasi tidak hilang saat Fail2Ban di-update.
Urutan prioritas konfigurasi adalah:
1.`/etc/fail2ban/jail.conf` (default global)
...
...
@@ -216,14 +216,14 @@ Kita akan membuat file konfigurasi baru di `/etc/fail2ban/jail.d/` untuk jail SS
#### Mengapa Konfigurasi Khusus Diperlukan?
***Port Kustom:** Konfigurasi default Fail2Ban untuk SSH memantau port 22. Karena kita telah mengubah port SSH (misalnya ke 22222), kita perlu memberi tahu Fail2Ban untuk memantau port yang benar.
***Best Practice:** Menggunakan file `.local` atau `.d/` memastikan konfigurasi kustom Anda tetap utuh saat Fail2Ban di-upgrade.
***Fleksibilitas:** Memungkinkan penyesuaian parameter banning (seperti durasi ban, jumlah percobaan gagal) sesuai kebutuhan keamanan spesifik Anda.
***Best Practice:** Menggunakan file `.local` atau `.d/` memastikan konfigurasi kustom tetap utuh saat Fail2Ban di-upgrade.
***Fleksibilitas:** Memungkinkan penyesuaian parameter banning (seperti durasi ban, jumlah percobaan gagal) sesuai kebutuhan keamanan spesifik.
#### Parameter Konfigurasi Kunci
Berikut adalah parameter utama yang akan kita konfigurasikan:
***`ignoreip`**: Daftar alamat IP atau subnet yang akan diabaikan oleh Fail2Ban. Masukkan IP Anda sendiri di sini agar Anda tidak terkunci secara tidak sengaja.
***`ignoreip`**: Daftar alamat IP atau subnet yang akan diabaikan oleh Fail2Ban. Masukkan IP sendiri di sini agar tidak terkunci secara tidak sengaja.
***`bantime`**: Durasi (dalam detik) IP akan diblokir. Default: 10 menit (600 detik).
***`findtime`**: Jendela waktu (dalam detik) di mana upaya login yang gagal akan dihitung. Default: 10 menit (600 detik).
***`maxretry`**: Jumlah upaya login yang gagal yang diizinkan dalam `findtime` sebelum IP diblokir. Default: 5.
...
...
@@ -242,7 +242,7 @@ Kita akan membuat file `/etc/fail2ban/jail.d/ssh_hardening.conf`.
sudo vi /etc/fail2ban/jail.d/ssh_hardening.conf
```
Tambahkan konten berikut ke file tersebut. Pastikan Anda mengganti `your_ssh_port` dengan port SSH Anda yang sebenarnya (misalnya, `22222`) dan `your_ip_address_or_subnet` dengan alamat IP atau subnet Anda.
Tambahkan konten berikut ke file tersebut. Pastikan mengganti `your_ssh_port` dengan port SSH yang sebenarnya (misalnya, `22222`) dan `your_ip_address_or_subnet` dengan alamat IP atau subnet.
# Default action adalah menggunakan firewalld, yang cocok untuk Rocky Linux.
# Anda juga bisa menambahkan email notification (membutuhkan postfix/sendmail):
# juga bisa menambahkan email notification (membutuhkan postfix/sendmail):
# action = %(action_mwl)s
# Untuk hanya memblokir IP:
action=%(action_)s
...
...
@@ -276,13 +276,13 @@ action = %(action_)s
***`[sshd]`**: Ini mendefinisikan sebuah "jail" bernama `sshd`. Fail2Ban akan memantau layanan ini.
***`enabled = true`**: Mengaktifkan jail ini.
***`port = your_ssh_port`**: **Definisi:** Port TCP yang akan dipantau oleh jail ini. **Usecase:** Penting untuk mengubah ini dari default `ssh` (port 22) ke port kustom Anda (misalnya, `22222`) agar Fail2Ban memonitor lalu lintas SSH Anda dengan benar. **Skenario:** Jika port SSH Anda adalah 22222, Fail2Ban hanya akan memblokir upaya gagal pada port tersebut.
***`port = your_ssh_port`**: **Definisi:** Port TCP yang akan dipantau oleh jail ini. **Usecase:** Penting untuk mengubah ini dari default `ssh` (port 22) ke port kustom (misalnya, `22222`) agar Fail2Ban memonitor lalu lintas SSH dengan benar. **Skenario:** Jika port SSH adalah 22222, Fail2Ban hanya akan memblokir upaya gagal pada port tersebut.
***`filter = sshd`**: **Definisi:** Nama file filter yang akan digunakan (dari `/etc/fail2ban/filter.d/sshd.conf`). Ini berisi regex untuk mengidentifikasi upaya login SSH yang gagal. **Usecase:** Menggunakan filter standar Fail2Ban untuk SSH.
***`logpath = /var/log/secure`**: **Definisi:** Lokasi file log yang akan dipantau oleh jail ini. **Usecase:** Di Rocky Linux, upaya login SSH dicatat di `/var/log/secure`. **Skenario:** Fail2Ban akan membaca file ini untuk mencari pola serangan SSH.
***`maxretry = 3`**: **Definisi:** Jumlah upaya gagal yang diizinkan. **Usecase:** Mengurangi toleransi terhadap tebakan kredensial. **Skenario:** IP akan diblokir setelah 3 kali salah memasukkan kunci atau kata sandi dalam `findtime`.
***`bantime = 1h`**: **Definisi:** Durasi IP akan diblokir (1 jam = 3600 detik). **Usecase:** Memberi penyerang waktu henti dan mengurangi tekanan pada server. **Skenario:** IP yang diblokir tidak akan bisa mengakses SSH selama 1 jam.
***`findtime = 10m`**: **Definisi:** Jendela waktu untuk menghitung `maxretry` (10 menit = 600 detik). **Usecase:** Mencegah ban permanen untuk kesalahan ketik sesekali. **Skenario:** Jika penyerang melakukan 3 upaya gagal dalam rentang 10 menit, mereka akan diblokir.
***`ignoreip = ...`**: **Definisi:** Daftar IP atau subnet yang harus diabaikan oleh Fail2Ban. **Usecase:** Sangat krusial untuk memasukkan IP statis Anda sendiri di sini. **Skenario:** Anda tidak akan diblokir jika Anda sendiri melakukan kesalahan ketik saat login.
***`ignoreip = ...`**: **Definisi:** Daftar IP atau subnet yang harus diabaikan oleh Fail2Ban. **Usecase:** Sangat krusial untuk memasukkan IP statis sendiri di sini. **Skenario:** tidak akan diblokir jika sendiri melakukan kesalahan ketik saat login.
**2. Menyimpan dan Keluar dari Editor**
...
...
@@ -291,7 +291,7 @@ action = %(action_)s
**3. Menerapkan Perubahan Konfigurasi Fail2Ban**
Setelah membuat atau memodifikasi file konfigurasi, Anda harus me-restart layanan Fail2Ban agar perubahan diterapkan:
Setelah membuat atau memodifikasi file konfigurasi, harus me-restart layanan Fail2Ban agar perubahan diterapkan:
Gunakan `fail2ban-client` untuk memverifikasi bahwa jail `sshd`Anda aktif dan memantau port yang benar.
Gunakan `fail2ban-client` untuk memverifikasi bahwa jail `sshd` aktif dan memantau port yang benar.
***Periksa Status Layanan Fail2Ban:**
...
...
@@ -330,40 +330,40 @@ Gunakan `fail2ban-client` untuk memverifikasi bahwa jail `sshd` Anda aktif dan m
Perhatikan `file list: /var/log/secure`, yang menunjukkan bahwa jail memantau log yang benar.
***Verifikasi Konfigurasi Port:**
Perintah di atas tidak secara eksplisit menunjukkan port, tetapi Anda bisa melihat file konfigurasi yang sedang digunakan Fail2Ban dengan `fail2ban-client -d | grep 'sshd/port'`. Jika ini tidak berfungsi, cukup pastikan Anda sudah mengedit file `ssh_hardening.conf` dengan benar.
Perintah di atas tidak secara eksplisit menunjukkan port, tetapi bisa melihat file konfigurasi yang sedang digunakan Fail2Ban dengan `fail2ban-client -d | grep 'sshd/port'`. Jika ini tidak berfungsi, cukup pastikan sudah mengedit file `ssh_hardening.conf` dengan benar.
**4. Uji Coba Fungsi Fail2Ban (Skenario Krusial):**
**SEBELUM LOGOUT DARI SESI SSH SAAT INI**, buka terminal baru di mesin klien Anda dan coba login ke server dengan sengaja salah memasukkan SSH key (atau passphrase) 3 kali.
**SEBELUM LOGOUT DARI SESI SSH SAAT INI**, buka terminal baru di mesin klien dan coba login ke server dengan sengaja salah memasukkan SSH key (atau passphrase) 3 kali.
```bash
# Ulangi 3 kali dengan sengaja salah memasukkan passphrase atau SSH key
ssh -p your_ssh_port youruser@your_server_ip
```
Setelah 3 kali percobaan gagal, Anda seharusnya tidak dapat login lagi dari IP klien Anda untuk sementara waktu.
Setelah 3 kali percobaan gagal, seharusnya tidak dapat login lagi dari IP klien untuk sementara waktu.
***Periksa Log di Server:**
Di sesi SSH Anda yang masih aktif di server, periksa log Fail2Ban dan log keamanan:
Di sesi SSH yang masih aktif di server, periksa log Fail2Ban dan log keamanan:
```bash
sudo tail -f /var/log/fail2ban.log
sudo tail -f /var/log/secure
```
Anda seharusnya melihat pesan di `fail2ban.log` yang menunjukkan bahwa IP Anda telah diblokir:
seharusnya melihat pesan di `fail2ban.log` yang menunjukkan bahwa IP telah diblokir:
```
... fail2ban.actions [sshd] NOTICE [sshd] Ban <YOUR_CLIENT_IP>
```
***Periksa Aturan Firewall:**
Anda juga dapat melihat aturan firewall untuk mengkonfirmasi bahwa IP Anda telah ditambahkan ke aturan blokir:
juga dapat melihat aturan firewall untuk mengkonfirmasi bahwa IP telah ditambahkan ke aturan blokir:
**Sangat Penting:** Ganti `<IP_ANDA_SAAT_INI>` dengan alamat IP publik Anda agar Anda tidak terkunci secara tidak sengaja. Anda bisa mencari IP Anda dengan `whatismyip.com` atau `curl ifconfig.me`.
**Sangat Penting:** Ganti `<IP_ANDA_SAAT_INI>` dengan alamat IP publik agar tidak terkunci secara tidak sengaja. bisa mencari IP dengan `whatismyip.com` atau `curl ifconfig.me`.
5.**UJI KONEKSI SEGERA!**
* Dari IP yang **TIDAK** ada di `ignore-ip` (misalnya, dari jaringan yang berbeda atau menggunakan VPN dengan IP yang berbeda), coba login SSH ke server Anda dengan **sengaja salah memasukkan SSH key/passphrase sebanyak `maxretry` kali**.
* Setelah itu, Anda seharusnya tidak bisa lagi terhubung dari IP tersebut.
* Di sesi SSH Anda yang masih aktif di server, periksa log `fail2ban.log` (`sudo tail -f /var/log/fail2ban.log`) untuk melihat IP Anda diblokir.
*Anda juga bisa memeriksa status jail dengan `sudo fail2ban-client status sshd`.
* Dari IP yang **TIDAK** ada di `ignore-ip` (misalnya, dari jaringan yang berbeda atau menggunakan VPN dengan IP yang berbeda), coba login SSH ke server dengan **sengaja salah memasukkan SSH key/passphrase sebanyak `maxretry` kali**.
* Setelah itu, seharusnya tidak bisa lagi terhubung dari IP tersebut.
* Di sesi SSH yang masih aktif di server, periksa log `fail2ban.log` (`sudo tail -f /var/log/fail2ban.log`) untuk melihat IP diblokir.
* juga bisa memeriksa status jail dengan `sudo fail2ban-client status sshd`.
* Setelah `bantime` berakhir, IP tersebut akan otomatis di-unban.
log_info "Anda sekarang dapat mengakses antarmuka web admin Nginx Proxy Manager di:"; log_info "URL: ${C_YELLOW}http://${server_ip}:${ADMIN_PORT}${C_RESET}"
log_info "sekarang dapat mengakses antarmuka web admin Nginx Proxy Manager di:"; log_info "URL: ${C_YELLOW}http://${server_ip}:${ADMIN_PORT}${C_RESET}"
if[-n"${ADMIN_SOURCE_IP}"];then log_warn " (Akses hanya diizinkan dari alamat IP sumber: ${ADMIN_SOURCE_IP})";fi
log_info "Gunakan kredensial default berikut untuk login pertama kali:"; log_info " Email: ${C_YELLOW}admin@example.com${C_RESET}"; log_info " Password: ${C_YELLOW}changeme${C_RESET}"
log_error "${C_BOLD}SANGAT PENTING:${C_RESET} Segera ubah email dan password default setelah Anda berhasil login!"
log_error "${C_BOLD}SANGAT PENTING:${C_RESET} Segera ubah email dan password default setelah berhasil login!"
