Autentikasi kata sandi lewat SSH adalah permukaan terbuka terbesar yang dimiliki server biasa. Terhadapnya tidak ada gunanya baik Fail2ban maupun ambang batas apa pun: seribu alamat dengan satu percobaan per jam tidak akan pernah mencapai batas, dan mereka akan terus menebak persis selama menebak masih mungkin dilakukan. Kunci menghapus kemungkinan itu sendiri, dan dari seluruh daftar hardening inilah satu-satunya pengaturan yang mengubah situasi secara kualitatif.

Hanya satu hal yang menakutkan darinya: mematikan kata sandi lalu tertinggal di luar. Berikut urutan yang membuat hal itu tidak mungkin terjadi.

Kunci

Dibuat di mesin Anda sendiri, bukan di server:

ssh-keygen -t ed25519 -C "work laptop"

Pakai ed25519 alih-alih RSA: lebih pendek, lebih cepat, dan tanpa pertanyaan soal panjangnya. RSA hanya perlu kalau Anda harus menjangkau sesuatu yang sangat tua; saat itu pakai -t rsa -b 4096.

Memasang passphrase pada kunci itu layak: berkas kunci bisa dicuri dari laptop, dan tanpa passphrase ia langsung bekerja. Anda tidak perlu mengetiknya setiap kali — itu ditangani ssh-agent, dan di macOS serta sebagian besar Linux desktop ia sudah berjalan.

Menyalinnya ke server memakan satu perintah, selagi kata sandinya masih berfungsi:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Kalau ssh-copy-id tidak tersedia, isi berkas .pub ditambahkan sebagai satu baris ke ~/.ssh/authorized_keys di server. Hak akses itu penting: direktori .ssh 700, berkasnya 600, milik pengguna tersebut. Dengan nilai lain sshd diam-diam menolak membaca berkas itu, dan itulah penyebab paling umum dari «kuncinya tidak bekerja».

Pemeriksaan yang menentukan segalanya

Sebelum mematikan apa pun, bukalah koneksi kedua tanpa menutup yang pertama:

ssh -o PasswordAuthentication=no user@203.0.113.25

Opsi ini melarang klien mundur ke kata sandi — jadi kalau loginnya berhasil, berarti berhasil dengan kunci. Jangan melangkah lebih jauh sampai perintah ini bekerja. Dan biarkan koneksi pertama terbuka sampai akhir: itulah yang akan memperbaiki apa pun yang sempat Anda rusakkan.

Mematikan kata sandi dan satu jebakan yang tak kentara

Pengaturan diletakkan di berkas terpisah agar pembaruan paket tidak menimpanya. Tetapi nama berkasnya penting:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Soalnya OpenSSH memakai nilai pertama yang ditemukannya untuk sebuah parameter, bukan yang terakhir seperti hampir di mana pun. Berkas di sshd_config.d dibaca menurut abjad, dan citra cloud Ubuntu meletakkan 50-cloud-init.conf di sana, yang sering memuat PasswordAuthentication yes. Dalam situasi itu berkas Anda bernomor 90 tidak akan berbuat apa-apa: pengaturannya tampak sudah terpasang sementara kata sandinya terus berfungsi. Dari sinilah angka 10 — ia dibaca lebih dulu.

Hasil sebenarnya bisa dilihat tanpa menebak-nebak:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Perintah ini mencetak konfigurasi efektif setelah semua include. Percayai itu, bukan isi berkasnya.

Lalu pemeriksaan sintaks dan pemuatan ulang layanan yang lembut:

sudo sshd -t && sudo systemctl reload ssh

sshd -t wajib: salah ketik pada konfigurasi disertai restart akan meninggalkan layanan mati dan Anda di luar. reload juga tidak memutus sesi yang terbuka.

Ubuntu 24.04: portnya tidak ada di tempat yang Anda kira

Jebakan tersendiri pada Ubuntu terbaru: di sana sshd dijalankan lewat socket systemd. Dalam mode itu baris Port di sshd_config tidak berbuat apa-apa — yang mendengarkan adalah socket, bukan daemon. Kalau Anda mengubah port, yang harus disunting adalah ini:

sudo systemctl edit ssh.socket

dan ListenStream= (nilai kosong mereset nilai sebelumnya) harus menyebut port yang baru. Gejala yang menyingkapnya: konfigurasi sudah diubah, layanan sudah dinyalakan ulang, dan server tetap menjawab di port 22.

Sekalian soal mengubah port: sebagai perlindungan itu tidak bekerja — pemindai menemukan layanan pada port mana pun dalam hitungan menit. Satu-satunya efeknya adalah log yang lebih sepi, karena penebakan massal hanya menuju port 22. Itu praktis, tetapi jangan campuradukkan dengan keamanan.

Siapa yang boleh login sama sekali

Tambahan yang berguna adalah daftar yang eksplisit:

AllowUsers deploy admin

Semua yang tidak tercantum dipotong bahkan sebelum kuncinya diperiksa. Itu juga menutup kasus ketika suatu paket membuat pengguna sistem dengan shell dan direktori home.

Jalan masuk cadangan

Satu kunci di satu laptop adalah titik kegagalan tunggal. Diska mati, laptop hilang, dan server jadi tak terjangkau selamanya. Minimum yang masuk akal:

  • kunci kedua dari perangkat lain di authorized_keys;
  • salinan kunci privat di pengelola kata sandi atau di flash disk terenkripsi;
  • akses konsol penyedia yang sudah diuji — VNC atau serial. Sudah diuji berarti Anda pernah masuk melaluinya setidaknya sekali, bukan «ada tombolnya di suatu tempat di panel».

Sekalian lihat apa yang sudah ada di authorized_keys — baik milik pengguna Anda maupun milik root. Kunci asing yang ada di sana bertahan melewati setiap penggantian kata sandi dan tetap menjadi akses yang berfungsi.

Sesudahnya

Penebakan kata sandi tidak akan hilang, ia hanya menjadi tak berguna: di log akan tetap ada ribuan baris Failed password, yang tidak satu pun bisa berakhir dengan keberhasilan. Yang layak diamati sekarang adalah login yang berhasil: dari alamat mana, dengan nama pengguna apa, pada jam berapa. Satu login sukses dengan kunci dari alamat asing adalah peristiwa yang jauh lebih penting daripada sejuta kegagalan, dan jauh lebih sulit terlihat di dalam arus umum. Itulah gambaran yang ditunjukkan halaman demo di bawah.