WIKI TKJ

Linux : Praktikum Hardening SSH dan Audit Konfigurasi

Revision as of 18:18, 11 November 2026 by Maintenance script (talk | contribs) (Praktikum pendamping: hardening SSH, audit konfigurasi efektif (sshd -T/-C), dan lima lapis bukti akses)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

SSH hardening sering diajarkan sebagai daftar baris sakti: matikan password, matikan root, ganti port. Di server nyata, daftar itu sering gagal bukan karena salah tulis, tetapi karena berkas yang kamu edit bukan berkas yang dibaca sshd.

Artikel ini adalah lab pendamping: kamu akan membangun baseline hardening di instance sshd kedua yang tidak menyentuh layanan produksi, lalu mematahkannya satu per satu. Tujuannya bukan menghafal opsi, tetapi bisa menunjuk bukti: setting mana yang benar-benar aktif, untuk user mana, dan dari mana asalnya.

🎯 Tujuan

Setelah mengikuti lab ini, kamu bisa:

  • Menjelaskan lima lapis keputusan akses SSH dan berhenti di lapis pertama yang gagal.
  • Membaca konfigurasi efektif sshd lewat sshd -T, bukan menebak dari isi berkas.
  • Membuktikan bahwa urutan Include membuat nilai dari sshd_config.d/ menang atas berkas utama.
  • Menguji Match untuk dua user berbeda pada satu berkas konfigurasi.
  • Menegakkan kunci-saja, larangan root, AllowUsers, dan izin berkas yang benar.
  • Menjelaskan kenapa sshd -t wajib dijalankan sebelum reload atau restart.

📍 Konteks nyata

Bayangkan pos jaga sekolah. Ada gerbang (jaringan), daftar nama yang boleh masuk (identitas), kartu atau sidik jari (metode), kunci ruang tertentu (kewenangan), dan buku tamu (jejak).

Kalau gerbangnya terbuka tetapi daftar nama tidak pernah dibaca, penjaga tetap meloloskan siapa pun. Itulah yang terjadi saat kamu menulis PasswordAuthentication no di berkas utama, sementara berkas lain di folder sshd_config.d/ menulis yes dan dibaca lebih dulu.

  • 💡 Tips: pegangan pertama hardening SSH: berkas yang kamu tulis belum tentu berkas yang dibaca. Selalu tutup pekerjaan dengan sshd -T dan -C, bukan dengan perasaan "sudah saya matikan".

Perintah sshd -T adalah mode uji lanjutan: ia mencetak konfigurasi efektif setelah semua Include dan Match diterapkan. Tanpa alat itu, kamu hanya membaca niat, bukan kenyataan.

🧠 Konsep singkat

Akses SSH adalah keputusan berlapis, bukan satu saklar. Setiap lapis bisa menolak lebih dulu, dan lapis sesudahnya tidak akan pernah dievaluasi.

Lapis Pertanyaan Alat bukti
1. Jaringan Apakah paket sampai ke port yang benar? ss -tlnp, aturan firewall
2. Identitas Apakah akun ini boleh login dari sini? AllowUsers, DenyUsers
3. Metode Dengan apa identitas dibuktikan? PubkeyAuthentication, PasswordAuthentication
4. Kewenangan Setelah masuk, boleh melakukan apa? PermitRootLogin, sudo -l
5. Jejak Apa yang tercatat setelah semuanya? journalctl -u ssh, lastb

Aturan kerjanya sederhana: berhenti di lapis pertama yang gagal. Kalau Connection refused, jangan mengutak-atik AllowUsers. Kalau kunci ditolak padahal akun benar, jangan menyalakan password sebagai "solusi".

🔹 Nilai pertama yang menang

sshd_config(5) menulis aturan yang mudah terlewat: untuk setiap kata kunci, nilai pertama yang ditemukan itulah yang dipakai.

Artinya urutan berkas menentukan hasil. Paket Debian dan Ubuntu menaruh Include /etc/ssh/sshd_config.d/*.conf di baris paling atas berkas utama. Manpage-nya menyebut terang-terangan: opsi di folder itu akan menimpa opsi di /etc/ssh/sshd_config.

  • ⚠️ Hati-hati: kalau kamu menambahkan PasswordAuthentication no di bagian bawah berkas utama, tetapi ada 50-cloud-init.conf berisi PasswordAuthentication yes, maka nilai yes yang menang. Berkasnya benar, hasilnya salah.

🔹 Satu berkas, dua kebenaran

Match membuat blok bersyarat: jika kriteria terpenuhi, kata kunci di dalamnya menimpa bagian global. Ini fitur, bukan bug — tetapi berbahaya kalau kamu mengira satu setting berlaku untuk semua orang.

Karena itu sshd -T punya pasangan: -C (connection spec). Dengan -C user=...,addr=...,host=..., kamu bisa bertanya "kalau user ini datang dari alamat ini, konfigurasi efektifnya apa?". Dua user, satu berkas, dua jawaban berbeda.

  • 📊 Angka penting: bawaan OpenSSH yang sering jadi sumber kejutan: MaxAuthTries 6, MaxStartups 10:30:100, LoginGraceTime 120, ClientAliveInterval 0, PermitRootLogin prohibit-password, PasswordAuthentication yes, StrictModes yes.

🧩 Istilah penting

  • Konfigurasi efektif — hasil akhir setelah semua Include dan Match diterapkan, bukan isi mentah satu berkas.
  • Include — perintah menyisipkan berkas lain pada posisi baris itu; di Debian diletakkan di awal berkas.
  • Drop-in — berkas kecil di sshd_config.d/ untuk menambah atau menimpa pengaturan tanpa menyentuh berkas utama.
  • Match block — blok bersyarat berdasarkan User, Group, Address, Host, atau LocalPort.
  • prohibit-password — nilai PermitRootLogin yang mematikan password untuk root, tetapi masih mengizinkan kunci. Ini bukan "root mati".
  • StrictModes — pemeriksaan izin dan pemilik berkas kunci sebelum login diterima.
  • MaxAuthTries — batas percobaan autentikasi per koneksi; kegagalan mulai dicatat setelah mencapai separuh nilai.
  • MaxStartups — batas koneksi yang belum terautentikasi, ditulis start:rate:full.
  • AuthenticationMethods — daftar metode yang harus berhasil berurutan, misalnya kunci lalu password.
  • authorized_keys — berkas kunci publik yang boleh masuk sebagai user tersebut.

🔧 Praktik: baseline hardening di instance kedua

Lab ini memakai instance sshd kedua di port 2222 dengan berkas konfigurasi sendiri. Layanan SSH asli di port 22 tidak disentuh, jadi kamu tidak bisa terkunci di tengah jalan.

  • ⚠️ Hati-hati: jangan pernah menguji "matikan password" langsung di server yang hanya bisa kamu akses lewat SSH. Selalu siapkan jalur kedua: konsol VM, snapshot, atau instance uji seperti di lab ini.

🔹 Langkah 1 — potret dulu, jangan ubah apa pun

  1. Siapkan satu user uji dan satu kunci di VM latihan Debian atau Ubuntu.
sudo useradd -m -s /bin/bash lab
sudo passwd lab
sudo -u lab mkdir -p /home/lab/.ssh
sudo -u lab ssh-keygen -t ed25519 -f /home/lab/.ssh/id_lab -N ""
sudo -u lab cp /home/lab/.ssh/id_lab.pub /home/lab/.ssh/authorized_keys
sudo chmod 700 /home/lab/.ssh
sudo chmod 600 /home/lab/.ssh/authorized_keys
  1. Potret konfigurasi yang sedang berlaku, sebelum menyentuh apa pun.
sudo sshd -T | sort > /tmp/baseline-sshd.txt
sudo sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|allowusers|usepam)'
  1. Catat hasilnya di lembar kerja. Tanpa baseline, kamu tidak punya pembanding untuk membuktikan perubahanmu bekerja.
  • 🧪 Uji cepat: sudo sshd -T | wc -l memberi jumlah baris konfigurasi efektif. Kalau angkanya berubah setelah edit, ada sesuatu yang benar-benar terbaca — bukan sekadar tersimpan.

🔹 Langkah 2 — bangun instance kedua di port 2222

  1. Buat salinan konfigurasi terpisah supaya produksi aman.
sudo mkdir -p /tmp/ssh-lab/sshd_config.d
sudo mkdir -p /run/sshd
  1. Tulis konfigurasi lab yang mandiri. Perhatikan Include di baris pertama — ini meniru perilaku paket Debian.
sudo tee /tmp/ssh-lab/sshd_config > /dev/null <<'EOF'
Include /tmp/ssh-lab/sshd_config.d/*.conf
Port 2222
PidFile /tmp/ssh-lab/sshd.pid
HostKey /etc/ssh/ssh_host_ed25519_key
LogLevel VERBOSE
PasswordAuthentication yes
PubkeyAuthentication yes
PermitRootLogin prohibit-password
UsePAM yes
EOF
  1. Validasi, lalu jalankan instance lab di latar belakang dengan berkas log sendiri.
sudo sshd -t -f /tmp/ssh-lab/sshd_config
sudo /usr/sbin/sshd -f /tmp/ssh-lab/sshd_config -E /tmp/ssh-lab/sshd.log
ss -tlnp | grep 2222
  1. Uji dua jalur login sebagai pembanding. Keduanya harus berhasil sebelum kamu mematahkan apa pun.
ssh -p 2222 -i /home/lab/.ssh/id_lab lab@127.0.0.1 'echo masuk-dengan-kunci'
ssh -p 2222 lab@127.0.0.1 'echo masuk-dengan-password'

🔹 Langkah 3 — buktikan lapis metode (kunci saja)

  1. Ubah satu baris di konfigurasi lab, lalu reload instance lab saja, bukan layanan sistem.
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /tmp/ssh-lab/sshd_config
sudo sshd -t -f /tmp/ssh-lab/sshd_config
sudo kill -HUP $(sudo cat /tmp/ssh-lab/sshd.pid)
sudo sshd -T -f /tmp/ssh-lab/sshd_config | grep -i passwordauth
  1. Minta klien memaksa jalur password. Jawaban yang benar adalah penolakan yang menyebut metode yang tersisa.
ssh -p 2222 -o PubkeyAuthentication=no lab@127.0.0.1
  1. Hasil yang diharapkan: Permission denied (publickey). Perhatikan daftar metodenya — hanya publickey, tanda password benar-benar tidak ditawarkan lagi.

🔹 Langkah 4 — buktikan lapis identitas (root dan AllowUsers)

  1. Matikan root, lalu batasi user yang boleh masuk.
sudo tee /tmp/ssh-lab/sshd_config.d/10-identitas.conf > /dev/null <<'EOF'
PermitRootLogin no
AllowUsers lab@127.0.0.1
EOF
sudo sshd -t -f /tmp/ssh-lab/sshd_config
sudo kill -HUP $(sudo cat /tmp/ssh-lab/sshd.pid)
sudo sshd -T -f /tmp/ssh-lab/sshd_config | grep -Ei '^(permitrootlogin|allowusers)'
  1. Bandingkan arti tiga nilai PermitRootLogin berikut. Ini sumber salah paham paling sering.
Nilai Password root Kunci root
yes boleh boleh
prohibit-password ditolak boleh
no ditolak ditolak
  1. Uji dari akun lain: user yang tidak ada di AllowUsers harus ditolak walau kuncinya sah.
sudo useradd -m -s /bin/bash tamu
sudo -u tamu mkdir -p /home/tamu/.ssh
sudo -u tamu ssh-keygen -t ed25519 -f /home/tamu/.ssh/id_tamu -N ""
sudo -u tamu cp /home/tamu/.ssh/id_tamu.pub /home/tamu/.ssh/authorized_keys
sudo chmod 700 /home/tamu/.ssh
sudo chmod 600 /home/tamu/.ssh/authorized_keys
ssh -p 2222 -i /home/tamu/.ssh/id_tamu tamu@127.0.0.1
  1. Hasil yang diharapkan: Permission denied (publickey). Di log server muncul User tamu not allowed because not listed in AllowUsers — bukti lapis 2 yang menolak, bukan lapis 3.
  • 💡 Tips: pola USER@HOST di AllowUsers menerima alamat dalam bentuk CIDR, misalnya lab@192.168.100.0/24. Ini cara murah membatasi akses hanya dari LAN lab tanpa menyentuh firewall.

🔹 Langkah 5 — jebakan urutan Include

Ini uji paling penting di artikel ini. Kamu akan membuat dua berkas yang saling bertentangan, lalu melihat siapa yang menang.

  1. Tulis no di berkas utama, lalu yes di drop-in. Urutan Include menentukan pemenangnya.
sudo tee /tmp/ssh-lab/sshd_config.d/90-warisan.conf > /dev/null <<'EOF'
PasswordAuthentication yes
EOF
sudo sshd -T -f /tmp/ssh-lab/sshd_config | grep -i passwordauth
  1. Hasil yang diharapkan: passwordauthentication yes. Padahal berkas utama jelas menulis no. Penyebabnya bukan salah tulis, tetapi urutan baca.
  • 🔥 Kasus nyata: sebuah SMK mematikan login password di /etc/ssh/sshd_config untuk server CBT. Image cloud yang dipakai menyisakan 50-cloud-init.conf berisi PasswordAuthentication yes, dan berkas itu dibaca lebih dulu. Selama tujuh bulan password tetap berlaku; akun operator dengan sandi operator123 dipakai bergantian oleh empat orang. Nilai dua kelas berubah suatu malam, dan admin sempat menyalahkan siswa karena di berkas yang ia buka, password sudah mati.
  1. Bersihkan drop-in palsu itu, lalu pastikan nilai kembali no.
sudo rm /tmp/ssh-lab/sshd_config.d/90-warisan.conf
sudo sshd -T -f /tmp/ssh-lab/sshd_config | grep -i passwordauth

🔹 Langkah 6 — dua kebenaran dari Match

  1. Sekarang buat pengecualian yang sah: password hanya untuk user lab, sisanya kunci saja.
sudo tee /tmp/ssh-lab/sshd_config.d/20-pengecualian.conf > /dev/null <<'EOF'
PasswordAuthentication no
Match User lab
    PasswordAuthentication yes
EOF
sudo sshd -t -f /tmp/ssh-lab/sshd_config
  1. Tanyakan konfigurasi efektif untuk dua user berbeda. Perhatikan nilai yang berbeda untuk kunci yang sama.
sudo sshd -T -f /tmp/ssh-lab/sshd_config -C user=lab,addr=127.0.0.1,host=laptop | grep -i passwordauth
sudo sshd -T -f /tmp/ssh-lab/sshd_config -C user=tamu,addr=127.0.0.1,host=laptop | grep -i passwordauth
  1. Hasil yang diharapkan: yes untuk lab, no untuk tamu. Satu berkas, dua kebenaran — dan kamu bisa menunjuk buktinya.
  • ⚠️ Hati-hati: Match tidak bisa membatalkan keputusan lapis sebelumnya. Kalau user sudah ditolak AllowUsers, pengecualian password tidak akan pernah dievaluasi.

🔹 Langkah 7 — izin berkas dan StrictModes

  1. Rusak izin direktori home dengan sengaja, lalu coba masuk dengan kunci.
sudo chmod 777 /home/lab
ssh -p 2222 -i /home/lab/.ssh/id_lab lab@127.0.0.1
  1. Hasil yang diharapkan: penolakan, dan di log server muncul pesan semacam Authentication refused: bad ownership or modes for directory /home/lab.
  • 📊 Angka penting: StrictModes bawaannya yes. Artinya sshd memeriksa pemilik dan izin direktori home serta authorized_keys. Direktori home yang bisa ditulis semua orang dianggap sebagai risiko pembajakan kunci.
  1. Kembalikan izin yang benar, lalu ulangi. Login harus berhasil lagi tanpa mengubah konfigurasi apa pun.
sudo chown lab:lab /home/lab
sudo chmod 750 /home/lab
sudo chmod 700 /home/lab/.ssh
sudo chmod 600 /home/lab/.ssh/authorized_keys
ssh -p 2222 -i /home/lab/.ssh/id_lab lab@127.0.0.1 'echo izin-beres'

🔹 Langkah 8 — batas percobaan dan jejak log

  1. Turunkan MaxAuthTries ke 2, reload instance lab, lalu paksa klien menawarkan beberapa kunci.
sudo tee /tmp/ssh-lab/sshd_config.d/30-batas.conf > /dev/null <<'EOF'
MaxAuthTries 2
EOF
sudo sshd -t -f /tmp/ssh-lab/sshd_config
sudo kill -HUP $(sudo cat /tmp/ssh-lab/sshd.pid)
ssh -p 2222 -o IdentitiesOnly=no -i /home/lab/.ssh/id_lab lab@127.0.0.1
  1. Perhatikan log server. Dengan LogLevel VERBOSE, sshd mencatat sidik jari kunci dan percobaan yang gagal.
sudo tail -n 20 /tmp/ssh-lab/sshd.log
sudo grep -c 'Failed password' /tmp/ssh-lab/sshd.log
  1. Hasil yang diharapkan: baris Accepted publickey for lab lengkap dengan sidik jari SHA256:..., dan hitungan percobaan gagal yang bisa kamu tunjuk angkanya.
  • 🧪 Uji cepat: sudo journalctl -u ssh -n 30 --no-pager membaca jejak layanan asli. Untuk percobaan gagal dari jaringan, sudo lastb -n 10 memberi daftar singkat.

🔹 Langkah 9 — validasi sebelum reload

  1. Rusak satu kata kunci dengan sengaja, lalu lihat siapa yang menangkap kesalahan itu.
sudo sh -c 'echo PasswordAuthenticaion no >> /tmp/ssh-lab/sshd_config'
sudo sshd -t -f /tmp/ssh-lab/sshd_config; echo "kode keluar: $?"
  1. Hasil yang diharapkan: Bad configuration option: passwordauthenticaion dan kode keluar bukan nol. Inilah rem darurat yang mencegah server mati karena salah ketik.
  2. Buktikan akibatnya kalau rem itu dilewati: hentikan instance lab, jalankan ulang dengan berkas yang rusak.
sudo kill $(sudo cat /tmp/ssh-lab/sshd.pid)
sudo /usr/sbin/sshd -f /tmp/ssh-lab/sshd_config -E /tmp/ssh-lab/sshd.log; echo "kode keluar: $?"
ss -tlnp | grep 2222
  1. Hasil yang diharapkan: instance gagal start dan port 2222 hilang. Di server produksi, skenario ini berarti kehilangan akses sampai ada orang membetulkan berkas dari konsol.

🔹 Langkah 10 — bersih-bersih dan lembar bukti

  1. Perbaiki berkas, tutup instance lab, hapus bahan uji.
sudo sed -i '/PasswordAuthenticaion/d' /tmp/ssh-lab/sshd_config
sudo sshd -t -f /tmp/ssh-lab/sshd_config
sudo kill $(sudo cat /tmp/ssh-lab/sshd.pid) 2>/dev/null
sudo rm -rf /tmp/ssh-lab
sudo userdel -r lab
sudo userdel -r tamu
  1. Tulis lembar bukti berisi tujuh baris: port lab, nilai passwordauthentication per user, nilai permitrootlogin, isi allowusers, pesan penolakan tiap uji, cuplikan log Accepted publickey, dan bukti port 2222 sudah tertutup.

🏭 Dipakai di dunia kerja

  • Sekolah: server CBT dan e-rapor biasanya diakses admin dari ruang guru. Kunci-saja plus AllowUsers per subnet membuat akun bersama tidak lagi jadi pintu masuk, tanpa mengganggu jadwal ujian.
  • Kantor distributor: vendor aplikasi minta akses remote. Kebijakan PermitRootLogin no dan kunci per-vendor yang bisa dicabut membuat akses berhenti tepat saat kontrak berhenti.
  • Klinik dan layanan data pribadi: rekam medis hanya boleh dibuka staf tertentu. AllowUsers dan AuthenticationMethods adalah kontrol yang bisa ditunjukkan saat audit, bukan sekadar niat baik.
  • Hosting dan VPS: server yang menghadap internet menerima puluhan ribu percobaan login per hari. Kunci-saja membuat tebakan password tidak lagi punya sasaran.
  • ISP dan warnet: perangkat jaringan dikelola dari jarak jauh lewat SSH. Akses berbasis kunci mencegah sandi default perangkat dipakai ulang di semua unit.
  • Industri: jaringan operasi dan server HMI tidak boleh diakses dari sembarang host. Batas alamat di AllowUsers menjadi lapis pertama sebelum firewall dalam.

✅ Verifikasi

Lapis Perintah Bukti lulus
1. Jaringan ss -tlnp hanya port yang direncanakan terbuka
2. Identitas sshd -T -C user=tamu,... allowusers hanya memuat user sah
3. Metode ssh -o PubkeyAuthentication=no Permission denied (publickey)
3. Metode sshd -T -C user=lab,... nilai sesuai pengecualian Match
4. Kewenangan ssh root@host ditolak sesuai PermitRootLogin
4. Kewenangan sudo -l -U lab tidak ada hak berlebih
5. Jejak grep -c 'Failed password' angka percobaan tercatat
5. Jejak grep 'Accepted publickey' ada sidik jari SHA256:...
Umum sshd -t kode keluar 0, tanpa pesan

Kalau satu baris gagal, jangan lanjut ke baris berikutnya. Perbaiki lapis itu dulu, lalu ulangi dari atas.

⚠️ Kesalahan umum & troubleshooting

Pesan atau gejala Artinya Tindakan
Connection refused tidak ada daemon di port itu ss -tlnp, cek Port, cek firewall
Permission denied (publickey) hanya kunci, dan kunci tidak cocok ssh -vvv, cek AuthorizedKeysFile
Permission denied (publickey,password) password masih ditawarkan tapi gagal cek sshd -T -C, status akun
bad ownership or modes for directory StrictModes menolak izin home chmod 750, chown user:user
Too many authentication failures MaxAuthTries habis pakai -o IdentitiesOnly=yes
User ... not allowed because not listed in AllowUsers lapis identitas menolak tambahkan pola di AllowUsers
Bad configuration option: ... salah ketik kata kunci sshd -t lalu perbaiki barisnya
no hostkeys available -- exiting HostKey hilang atau tak terbaca ssh-keygen -A, cek path HostKey
Missing privilege separation directory: /run/sshd direktori runtime belum ada mkdir -p /run/sshd
Address already in use port lab sudah dipakai ss -tlnp, ganti port instance
  • ⚠️ Hati-hati: systemctl restart ssh dengan berkas rusak adalah cara paling cepat kehilangan server. Di Debian, kegagalan start meninggalkan layanan mati dan port tertutup. Selalu sshd -t dulu, dan pastikan kamu punya konsol atau snapshot.
  • 💡 Tips: saat men-debug klien, tambahkan -v (cukup) atau -vvv (detail). Di sisi server, LogLevel VERBOSE memberi sidik jari kunci tanpa membocorkan isi sesi. Kembalikan ke INFO setelah selesai.

🔐 Catatan keamanan & etika

  • LogLevel DEBUG bukan alat permanen. Manpage sshd_config(5) menyebut level DEBUG melanggar privasi pengguna. Nyalakan sebentar, matikan lagi.
  • Kunci adalah identitas, bukan berkas biasa. Kunci privat mode 600, direktori .ssh mode 700, dan jangan pernah menyalinnya ke flashdisk bersama.
  • prohibit-password bukan "root mati". Kalau ingin root benar-benar tertutup, tulis no dan pastikan ada akun lain dengan sudo.
  • Cabut akses dengan mencabut kunci. Hapus baris di authorized_keys atau pakai AuthorizedKeysCommand terpusat; mengganti password tidak menyentuh kunci yang sudah tertanam.
  • Log menyimpan data pribadi. Alamat IP, nama user, dan sidik jari kunci adalah data orang. Jangan menempel log mentah ke grup chat umum.
  • Lab di server bersama butuh izin. Instance kedua tidak mengganggu produksi, tetapi membuat user dan mengubah izin home tetap terlihat pengguna lain. Kembalikan kondisi awal setelah selesai.
  • Etika: materi ini untuk mengamankan server milik sendiri atau yang kamu diberi izin. Mencoba teknik ini pada server orang lain adalah pelanggaran hukum, bukan latihan.

📌 Kesimpulan

Hardening SSH bukan daftar baris yang ditempel, tetapi urutan lapis yang harus dibuktikan satu per satu: jaringan, identitas, metode, kewenangan, jejak.

Alat paling jujurnya bukan ingatanmu, melainkan sshd -T dan sshd -T -C. Dua perintah itu menunjukkan apa yang benar-benar dipakai sshd untuk user dan alamat tertentu, termasuk saat drop-in menimpa berkas utama.

Langkah berikutnya: ambil satu server latihan milikmu, potret baseline-nya, lalu jalankan lab ini dari Langkah 2 sampai Langkah 9 tanpa menyentuh layanan di port 22.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Linux_:_Praktikum_Hardening_SSH_dan_Audit_Konfigurasi&oldid=1727"