Rutin Audit authorized_keys agar Akses SSH Penyusup Tidak Bertahan

Setelah server dibobol, langkah yang biasanya langsung diambil adalah ganti password, scan malware, lalu tambal aplikasi yang jadi pintu masuk. Semua itu perlu, tapi ada satu celah yang sering terlewat: SSH key. Kalau penyusup sempat menambahkan public key miliknya ke ~/.ssh/authorized_keys, dia tetap bisa login berapa kali pun password diganti. Tulisan ini berisi checklist untuk memeriksa file itu di semua user, mencocokkan setiap key dengan pemiliknya, dan menghapus yang tidak dikenal tanpa mengunci diri sendiri dari server.

Kenapa ganti password tidak menutup akses lewat key

Login SSH dengan key tidak memakai password user sama sekali. Server cukup mengecek apakah public key yang ditawarkan client ada di daftar key yang diizinkan untuk user tersebut. Daftar itu, secara default, adalah file authorized_keys di folder .ssh milik user. Satu baris berisi satu key. Artinya, mengganti password hanya menutup jalur login password. Key yang sudah tertanam tetap valid sampai barisnya dihapus. Ini juga yang membuat teknik ini populer di kalangan penyusup: cukup satu baris teks, tidak butuh proses yang berjalan, dan tidak terdeteksi oleh scanner malware yang fokus mencari file PHP mencurigakan atau binary aneh. Di meja support, pola yang sering muncul adalah pemilik server merasa sudah bersih karena hasil scan aman dan password sudah baru, tapi aktivitas aneh tetap terjadi. Saat itu, authorized_keys termasuk hal pertama yang layak dicek.

Checklist audit, urut dari yang paling penting

Urutan ini disusun supaya hal yang paling sering jadi jalan masuk dicek lebih dulu. Semua langkah di bawah dijalankan sebagai root, dan sebaiknya dari sesi yang kamu yakini bersih.

Pastikan file mana yang sebenarnya dibaca sshd. Jangan berasumsi lokasinya selalu ~/.ssh/authorized_keys. Directive AuthorizedKeysFile bisa diubah, dan default OpenSSH juga membaca .ssh/authorized_keys2. Jalankan sshd -T | grep -i authorized untuk melihat konfigurasi efektif. Perhatikan juga AuthorizedKeysCommand dan TrustedUserCAKeys, karena keduanya bisa memberi akses lewat jalur lain di luar file per user.
Cek apakah konfigurasi sshd sendiri diubah. Penyusup yang punya akses root bisa menambahkan blok Match untuk user tertentu atau menaruh file baru di /etc/ssh/sshd_config.d/ kalau sshd_config memakai Include. Bandingkan dengan backup atau dengan konfigurasi standar distro. Perubahan di sini lebih berbahaya daripada satu key tambahan, karena bisa mengalihkan lokasi key ke tempat yang tidak akan kamu periksa.
Periksa root lebih dulu. File /root/.ssh/authorized_keys memberi akses penuh, jadi ini prioritas utama. Kalau di sshd login root sudah dimatikan dengan PermitRootLogin no, tetap cek, karena konfigurasi itu bisa saja diubah balik.
Daftar semua user, bukan hanya yang ada di /home. Akun service seperti user web server atau database punya home directory di tempat lain, misalnya di bawah /var. Ambil daftar lengkap dari getent passwd supaya user dari sumber lain (misalnya LDAP) juga ikut terdaftar. Perhatikan juga user baru yang tidak kamu kenal, atau user dengan UID 0 selain root.
Kumpulkan fingerprint setiap key. Fingerprint adalah hash pendek dari public key, dan inilah identitas yang bisa dicocokkan dengan log maupun dengan key milik tim. Jangan mengandalkan kolom komentar di ujung baris (biasanya berbentuk user@laptop), karena teks itu bebas diisi apa saja dan mudah dipalsukan agar terlihat seperti milik admin.
Cocokkan dengan pemilik yang sah. Minta setiap orang yang memang punya akses untuk menjalankan ssh-keygen -lf pada public key mereka sendiri, lalu bandingkan fingerprint-nya. Key yang tidak bisa diklaim siapa pun dianggap asing sampai terbukti sebaliknya.
Lihat opsi di depan key. Satu baris bisa diawali opsi seperti command=, from=, environment=, atau no-pty. Opsi command= misalnya memaksa perintah tertentu berjalan setiap kali key itu dipakai. Key yang sah biasanya tidak punya opsi aneh, jadi baris dengan opsi yang tidak kamu pasang layak dicurigai.
Cocokkan dengan log login. Saat login berhasil memakai key, sshd mencatat baris Accepted publickey lengkap dengan IP dan fingerprint key yang dipakai. Lokasi log tergantung distro, biasanya /var/log/auth.log di Debian/Ubuntu atau /var/log/secure di keluarga RHEL, atau lewat journalctl untuk unit ssh/sshd. Dari sini kamu bisa tahu key mana yang benar-benar dipakai dan dari mana.
Cek waktu perubahan dan atribut file. stat menunjukkan kapan file terakhir diubah. Timestamp modifikasi bisa dipalsukan dengan touch, tapi ctime (waktu perubahan metadata) jauh lebih sulit dimanipulasi tanpa akses tingkat rendah. Jalankan juga lsattr pada file dan folder .ssh. Kalau ada atribut i (immutable), file tidak bisa diubah bahkan oleh root sampai atribut itu dicabut dengan chattr -i, dan itu tanda jelas ada yang sengaja mempertahankan key tersebut.

Untuk langkah 4 sampai 6, perintah di bawah ini hanya membaca dan tidak mengubah apa pun. Ia menelusuri semua user, mencari dua lokasi default, lalu menampilkan pemilik file, permission, dan fingerprint tiap key. Kalau langkah 1 menunjukkan AuthorizedKeysFile yang berbeda, sesuaikan path di dalam loop.

BASH

# Read-only. Jalankan sebagai root.
getent passwd | cut -d: -f1,6 | while IFS=: read -r user home; do
  for f in "home/.ssh/authorized_keys" "home/.ssh/authorized_keys2"; do
    [ -f "$f" ] || continue
    echo "== user :f"
    ls -l "$f"
    lsattr "$f" 2>/dev/null
    ssh-keygen -lf "$f"
  done
done

Hasilnya bisa panjang di server dengan banyak akun hosting. Simpan ke file teks supaya mudah dibandingkan dengan daftar key resmi tim.

Menghapus key tanpa mengunci diri sendiri

Bagian ini yang paling sering bikin masalah, jadi pelan-pelan saja. Sebelum mengedit apa pun, buat salinan file authorized_keys ke lokasi yang aman, di luar folder .ssh. Salinan ini berguna sebagai bukti untuk investigasi dan sebagai jalan balik kalau ternyata kamu menghapus key yang sah. Pertahankan sesi SSH yang sedang aktif selama proses berjalan. Hapus baris key yang asing, simpan, lalu buka sesi SSH baru dari terminal lain untuk memastikan kamu masih bisa masuk dengan key sendiri. Baru tutup sesi lama setelah login baru berhasil. Kalau server punya akses console dari panel VPS atau hypervisor, pastikan kamu tahu cara membukanya sebelum mulai. Periksa juga permission setelah mengedit. Dengan StrictModes aktif (default di OpenSSH), sshd akan menolak file key kalau folder .ssh atau file authorized_keys bisa ditulis oleh user lain. Aturan yang aman: folder .ssh dengan mode 700, file authorized_keys dengan mode 600, dan keduanya dimiliki oleh user yang bersangkutan. Kesalahan kepemilikan sering terjadi kalau root mengedit file milik user lain lalu tidak mengembalikan owner-nya. Kalau server memakai control panel, cek apakah panel itu punya halaman pengelolaan SSH key sendiri. Beberapa panel menyimpan atau menampilkan key dengan caranya sendiri, jadi menghapus lewat panel kadang lebih aman agar tampilan panel dan isi file tetap sinkron. Detailnya tergantung panel yang dipakai. Terakhir, ingat bahwa menghapus key hanya menutup satu pintu. Kalau penyusup sempat punya akses root, ada tempat lain yang juga perlu dicek: cron job, systemd unit baru, entri sudoers, dan user tambahan. Itu topik tersendiri, tapi jangan berhenti di authorized_keys saja.

Menjadikannya rutin, bukan cuma saat insiden

Audit setelah insiden itu reaktif. Yang lebih membantu adalah punya daftar resmi key yang boleh ada di setiap server, lengkap dengan fingerprint dan nama pemiliknya. Dengan daftar itu, audit berikutnya cukup membandingkan output loop di atas dengan daftar resmi, dan selisihnya langsung terlihat. Beberapa kebiasaan kecil yang membantu:

Saat ada anggota tim keluar atau berganti peran, hapus key-nya di semua server pada hari yang sama. Key lama yang tertinggal susah dibedakan dari key penyusup beberapa bulan kemudian.
Gunakan kolom komentar secara konsisten (misalnya nama orang dan tujuan key), walau tetap jangan dipercaya sebagai bukti identitas. Ini memudahkan membaca file, bukan menggantikan pengecekan fingerprint.
Jadwalkan audit berkala, misalnya bersamaan dengan jadwal patching. Seberapa sering tergantung jumlah server dan seberapa sering orang keluar masuk tim.
Kalau jumlah server sudah banyak, pertimbangkan mengelola key lewat configuration management atau SSH certificate, supaya daftar key tidak lagi tersebar manual di tiap home directory.

Intinya, setiap kali kamu membersihkan server yang kena bobol, anggap authorized_keys di semua user sebagai bagian wajib dari checklist, sejajar dengan ganti password dan scan malware. Pastikan dulu file mana yang dibaca sshd, cocokkan setiap fingerprint dengan pemilik yang jelas, hapus yang asing dengan sesi cadangan tetap terbuka, dan simpan daftar resmi supaya audit berikutnya tinggal membandingkan.