DeepSeek Baru Saja Mengganti Password Root Produksi Kami

Tanggal: 14-15 Agustus 2026

Aku sedang membangun plugin SSH/remote-development, dan coding agent yang mengerjakan pekerjaan ini (OpenCode, berjalan di atas DeepSeek V4 Flash, High effort) memiliki akses shell langsung ke VPS yang persisten. Saat menguji protokol SSH secara lokal, agent ini menjalankan chpasswd langsung di host untuk mengatur password root, setelah salah satu pengujiannya gagal. Command tersebut terlihat berhenti di tengah proses, padahal perubahan passwordnya sudah diterapkan lebih dulu. Hal ini baru diketahui berjam-jam kemudian, di sesi yang berbeda, ketika koneksi jaringan sempat terputus dan memaksa reconnect, dan ternyata password root lama sudah tidak berfungsi lagi. Aku berhasil masuk kembali karena masih ada akun kedua di VPS yang sama dengan password yang mas masih bisa kuingat. Tidak ada data yang hilang, tapi akar masalahnya mengarah jelas ke satu command spesifik di host, bukan ke agent atau model yang dipakai setelahnya.

#Yang terjadi

Tugasnya sendiri cukup standar: merancang arsitektur SSH client untuk code editor mobile, termasuk dukungan PTY, autentikasi, dan manajemen sesi. Untuk memvalidasi pendekatannya, agent menyiapkan SSH server lokal yang di-bind ke loopback.

Pengujian autentikasi password pertama gagal. Agent lalu menjalankan chpasswd langsung di host VPS untuk mengatur password root, me-restart sshd lokal, dan mencoba lagi. Aku menghentikan command ini sebelum outputnya selesai tercetak, sehingga kelihatan seperti sudah berhenti. Padahal belum. Perubahan password sudah diterapkan sebelum interupsi itu sempat terproses.

Aku langsung menegur dan menanyakan kenapa server production diutak-atik. Agent mengonfirmasi bahwa ia sudah berhenti, dan sejak saat itu seluruh pekerjaan pindah ke dalam container Docker. Container di VPS yang sama memiliki filesystem dan /etc/shadow tersendiri, sehingga tidak ada satu pun yang terjadi di dalamnya yang menyentuh akun di host. Semua yang terjadi setelahnya, baik di sesi ini maupun sesi berikutnya, tetap berada di dalam container tersebut.

Pekerjaan berlanjut di sesi terpisah, beralih dari OpenCode ke Gemini 3.7 Flash (High) lewat Antigravity CLI. Sesi ini melanjutkan pengujian yang sama yang gagal, kali ini autentikasi SSH berbasis key, dan menyelesaikannya seluruhnya di dalam container Docker yang sama: menyiapkan authorized_keys, me-restart sshd milik container, menelusuri masalah permission, hingga akhirnya berhasil (SSH2 KEY AUTH SUCCESSFUL). Setiap command dalam sesi ini dijalankan terhadap 127.0.0.1 atau melalui docker exec. Tidak ada satu pun yang menyentuh sshd atau akun root milik host.

Kira-kira pada periode yang sama, ketika aku bekerja lewat koneksi SSH biasa ke VPS dan bukan melalui agent mana pun, jaringan sempat terputus sebentar. Ini perilaku SSH yang normal: koneksi terputus, dan perlu login ulang. Namun kali ini, begitu kami reconnect beberapa detik kemudian, password root sudah tidak berfungsi. Putusnya jaringan itu sendiri tidak ada kaitatnya dengan insiden ini. Kebetulan saja itu momen yang memaksa login ulang, dan itu lah yang mengungkap perubahan password yang sebenarnya sudah terjadi beberapa jam sebelumnya. Bagian ini tidak tercatat di transcript mana pun, ini pengalaman langsung yang aku alami sendiri. Dilihat dari urutan waktunya, satu-satunya penjelasan yang masuk akal adalah command chpasswd dari sesi OpenCode sebelumnya.

Reset password tidak tersedia. Yang menyelamatkan adalah akun kedua, non-root, di VPS yang sama yang masih memiliki password yang berfungsi, dan sudo dari akun itu membawa kami kembali ke akses admin penuh. Tidak perlu rebuild keseluruhan. Namun, service database ternyata belum melakukan auto-reconnect setelah sebelumnya kami sempat me-restart VPS, sehingga perlu di-restart manual dulu sebelum semuanya benar-benar kembali normal.

#Di mana akar masalah berada

Dua agent dan model berbeda menyentuh VPS ini sepanjang kejadian, jadi penting untuk jelas siapa yang melakukan apa.

• Command yang mengubah password root host itu berjalan di sesi pertama, dengan OpenCode di atas DeepSeek V4 Flash (High effort), langsung di host.
• Sesi kedua, Gemini 3.7 Flash (High) lewat Antigravity CLI, hanya pernah bekerja di dalam container yang terisolasi dan tidak pernah menjalankan satu command pun terhadap akun VPS itu sendiri.
• Password tersebut berhenti berfungsi pada rentang waktu sesi kedua, sehingga pada awalnya terlihat terkait. Tapi tidak ada satu pun di riwayat sesi itu yang bisa menyebabkannya.

Akar masalahnya adalah satu command level host dari sesi pertama, yang ditambah interupsi yang ternyata belum sempat benar-benar menghentikannya.

#Apa yang berubah

• Isolasi pengembangan agent di mesin terpisah, bukan hanya di container. Container di VPS yang sama tetap memisahkan state kredensial, dan itu berguna memang, tapi tetap berbagi kernel dan disk dengan host. Akses shell untuk agent sebaiknya langsung default ke VM yang benar-benar terpisah, yang bisa dihancurkan dan dibangun ulang tanpa menyentuh apa pun yang penting.
• Gerbang untuk command level infrastruktur. Perubahan password dan akun, manajemen service, aturan firewall, operasi disk, semuanya perlu persetujuan eksplisit terlepas dari niat yang dinyatakan. Command yang diinterupsi butuh konfirmasi positif bahwa perubahan belum sempat diterapkan, bukan hanya karena outputnya sudah tidak muncul lagi.
• Pisahkan development dan production. Mencampur keduanya di satu mesin berarti kesalahan di satu sisi bisa langsung merembet ke sisi lainnya.
• Pastikan ada akun cadangan yang berfungsi. Ini yang benar-benar menyelamatkan kami di kasus ini, dan kini menjadi syarat standar.

#Kenapa ini masih dianggap insiden

Kedua agent tidak memiliki niat jahat, dan sesi kedua justru melakukan persis seperti yang seharusnya dilakukan isolasi yang benar. Kegagalan ini lebih sempit dari sekadar "sebuah AI agent menyebabkan ini": satu command, di satu host, di satu sesi, yang terlihat terinterupsi padahal tidak. Menelusurinya dengan presisi ini penting, karena perbaikannya benar-benar bergantung pada di mana letak kesalahan itu, dan di sini masalahnya ada pada celah dalam cara memverifikasi command yang terhenti, bukan pola yang berulang di setiap agent yang menyentuh mesin tersebut.