Cara Mengubah Kata Sandi Root VPS di Ubuntu

Cara mengubah kata sandi root VPS di Ubuntu

Untuk mengubah kata sandi root VPS (virtual private server) di Ubuntu, buka sesi SSH (secure shell) sebagai pengguna yang dapat menjalankan sudo, lalu jalankan sudo passwd root. Perintah tersebut meminta kata sandi baru dua kali dan tidak pernah meminta kata sandi lama, karena sudo sudah memverifikasi identitas Anda. Untuk mengubah kata sandi login Anda sendiri, jalankan passwd tanpa argumen. Perintah tersebut akan meminta kata sandi Anda saat ini terlebih dahulu.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Itulah seluruh prosesnya. Bagian berikut membahas hal-hal yang biasanya menimbulkan masalah: memastikan kata sandi baru berfungsi sebelum sesi yang dapat digunakan untuk memperbaikinya terputus, menetapkan kata sandi dari skrip, sengaja membuat kata sandi kedaluwarsa, dan mendapatkan kembali akses ketika kata sandi sudah hilang.

Buka sesi kedua sebelum mengubah kata sandi

Buka sesi SSH kedua sekarang dan biarkan tetap terhubung. Hampir semua kegagalan dalam panduan ini dapat diperbaiki dalam dua menit selama masih ada shell terautentikasi yang aktif. Jika sesi terakhir ditutup, Anda mungkin perlu mengakses konsol.

Shell yang sudah terbuka tetap berfungsi setelah Anda mengubah, mengunci, atau membuat akun yang terkait menjadi kedaluwarsa, karena SSH memeriksa kredensial saat login dan tidak memeriksanya lagi. Pengecualiannya adalah sudo. Perintah ini memeriksa ulang kata sandi melalui PAM (modul autentikasi yang dapat dipasang) setelah stempelnya kedaluwarsa, secara default 15 menit setelah permintaan terakhir. Jadi, kata sandi baru benar-benar diuji saat sudo memintanya, bukan saat login.

Uji kata sandi baru di sesi kedua, sementara sesi pertama tetap terbuka.

Ubah kata sandi Anda sendiri dengan passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully adalah satu-satunya output yang berarti hash dalam /etc/shadow telah diganti. Jika outputnya berbeda, kata sandi lama tetap digunakan.

Dua kegagalan terjadi di sini. passwd: Authentication token manipulation error, kemudian passwd: password unchanged, berarti kata sandi saat ini yang Anda masukkan salah, atau filesystem yang menyimpan /etc/shadow tidak dapat ditulisi. Kondisi terakhir ini normal dalam recovery mode. You must choose a longer password. berasal dari pam_unix dalam /etc/pam.d/common-password, yang menerapkan pemeriksaan panjang dan kemiripan pada pengguna biasa.

Pada sebagian besar image VPS, akun default (ubuntu, atau nama apa pun yang digunakan provider Anda) sama sekali tidak memiliki kata sandi, melainkan hanya SSH key. passwd tidak memiliki kata sandi saat ini untuk diverifikasi, sehingga tidak dapat melewati prompt pertama. Gunakan sudo passwd $USER sebagai gantinya. Cara ini berfungsi karena file drop-in sudoers pada image mengizinkan akun tersebut menjalankan sudo tanpa kata sandi.

Ubah kata sandi pengguna lain dengan sudo passwd

sudo passwd deploy

root tidak diminta memasukkan kata sandi lama, dan pam_unix melewati pemeriksaan kekuatan kata sandi yang diterapkan pada pengguna biasa. Karena itu, root dapat menetapkan kata sandi yang tidak dapat ditetapkan pengguna tersebut untuk dirinya sendiri.

Mengunci kata sandi merupakan tindakan terpisah. sudo passwd -l deploy menambahkan ! di depan hash yang tersimpan, sehingga tidak ada kata sandi yang cocok dengannya. sudo passwd -u deploy menghapusnya. Baca kembali statusnya dengan sudo passwd -S deploy.

Mengunci kata sandi tidak mencegah pengguna tersebut untuk login. Semua key dalam ~/.ssh/authorized_keys tetap berfungsi karena autentikasi public key tidak pernah membaca /etc/shadow. Untuk menghentikan akun sepenuhnya, kedaluwarsakan akun itu sendiri:

sudo usermod --expiredate 1 deploy

Perintah tersebut menetapkan tanggal kedaluwarsa akun ke tahun 1970, sehingga sshd menolak login apa pun kredensial yang ditawarkan. Batalkan dengan sudo usermod --expiredate '' deploy.

Hindari passwd -d. Perintah tersebut menetapkan kata sandi kosong, bukan mengunci kata sandi. Pada release lama yang masih memuat nullok dalam stack PAM, kata sandi kosong dapat digunakan oleh siapa saja.

Apakah root memerlukan password pada VPS?

Ubuntu dirilis dengan root dalam keadaan terkunci. /etc/shadow menyimpan ! sebagai pengganti hash, dan sudo passwd -S root menampilkan baris yang diawali root L. Tidak ada yang dapat login sebagai root menggunakan password sampai Anda menetapkannya. Karena itu, image menyediakan pengguna yang memiliki kemampuan sudo. Tetap gunakan akun pengguna dengan hak minimum pada VPS, bukan root.

Menetapkan password root memberikan satu manfaat khusus: akses melalui konsol provider. Konsol tersebut terhubung ke virtual machine di bawah network stack. Karena itu, konsol tetap berfungsi ketika sshd salah konfigurasi atau aturan firewall keliru. Namun, ada konsekuensinya. Menu pemulihan GRUB meminta password root jika root memiliki password. Artinya, tool yang digunakan untuk mengatur ulang password yang terlupa kini berada di balik password yang sama.

Menetapkan password root tidak memungkinkan root login melalui SSH. Ubuntu dirilis dengan PermitRootLogin prohibit-password, yang berarti hanya key yang diizinkan. Periksa metode yang benar-benar digunakan server Anda:

sudo sshd -T | grep -i permitrootlogin

sshd -T menampilkan konfigurasi efektif setelah setiap baris Include diselesaikan. Karena itu, perintah tersebut adalah satu-satunya jawaban yang dapat diandalkan ketika /etc/ssh/sshd_config.d/ memuat file drop-in.

Menetapkan kata sandi dari skrip dengan chpasswd

passwd membaca input dari terminal dan tidak dapat dikendalikan dari skrip. chpasswd membaca pasangan user:password dari input standar, satu pasangan per baris.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Cara tersebut berhasil, tetapi memasukkan kata sandi teks biasa ke dalam riwayat shell dan log CI (continuous integration) Anda. Hash kata sandi terlebih dahulu:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 meminta kata sandi dua kali tanpa menampilkan input, lalu mencetak hash crypt SHA-512 yang diawali dengan $6$. -e memberi tahu chpasswd bahwa field kedua sudah berupa hash, sehingga nilainya disalin ke /etc/shadow apa adanya. Hash tersebut aman disimpan dalam repository atau variabel CI, dan teks biasa tidak pernah keluar dari mesin tempat Anda mengetikkannya.

Ubuntu 24.04 melakukan hashing kata sandi baru dengan yescrypt ($y$) saat passwd menetapkannya, sedangkan openssl passwd -6 menggunakan SHA-512. Keduanya dapat diverifikasi saat login karena libxcrypt membaca kedua format tersebut. Mencampur keduanya tidak masalah, dan openssl passwd -6 berperilaku sama pada setiap rilis Ubuntu LTS, sedangkan chpasswd -c YESCRYPT tidak: paket shadow yang lebih lama pada 20.04 tidak mengenali nama metode tersebut. Hash tersebut juga tetap valid setelah peningkatan rilis, sehingga meningkatkan server 24.04 ke 26.04 tidak mengharuskan Anda mengatur ulang kata sandi siapa pun.

Bagaimana cara memeriksa bahwa kata sandi benar-benar berubah?

Mulai dengan metadata, lalu buktikan melalui login.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Field kedua menunjukkan status: P untuk kata sandi yang dapat digunakan, L untuk kata sandi yang dikunci, dan NP jika tidak ada kata sandi sama sekali. Tanggal tersebut menunjukkan kapan kata sandi terakhir diubah, sehingga seharusnya berisi tanggal hari ini. Angka setelahnya adalah field masa berlaku yang dijelaskan di bawah.

Pengujian langsung yang paling aman adalah sudo. sudo -k membuang timestamp yang tersimpan di cache, sedangkan sudo -v memaksa prompt baru. Jika kata sandi baru diterima di sana, PAM menerimanya dan tidak ada perubahan pada sesi Anda.

sudo -k && sudo -v

Untuk menguji akun lain, jalankan su - deploy dari shell tanpa hak istimewa. Jangan jalankan sudo su - deploy, karena root tidak pernah diminta memasukkan kata sandi dan pengujian tersebut tidak membuktikan apa pun. Kata sandi yang salah akan menampilkan su: Authentication failure.

Pengujian sebenarnya adalah login SSH baru dari laptop Anda, sementara sesi kerja tetap terbuka:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). di sini berarti server tidak pernah menawarkan autentikasi kata sandi, sehingga perubahan kata sandi tidak akan memungkinkan Anda masuk. Permission denied, please try again. berarti server memang menawarkannya, tetapi menolak masukan yang Anda ketik.

Memaksa perubahan kata sandi pada login berikutnya dengan chage

sudo chage -d 0 deploy

-d 0 menetapkan tanggal perubahan terakhir ke epoch, sehingga PAM menganggap kata sandi telah kedaluwarsa. Login interaktif berikutnya meminta kata sandi saat ini, lalu kata sandi baru, sebelum memberikan shell. sudo passwd -e deploy melakukan hal yang sama.

Gunakan ini hanya untuk akun yang login secara interaktif dengan kata sandi. Kata sandi yang kedaluwarsa juga memengaruhi login berbasis key, karena sshd menjalankan tahap account PAM meskipun key digunakan untuk autentikasi. ssh deploy@203.0.113.10 'systemctl restart app' yang dijalankan oleh skrip kemudian gagal dengan pesan ini dan berhenti:

Password change required but no TTY available.

Tidak ada perintah setelah baris tersebut yang dijalankan, dan job hanya melaporkan kode keluar non-zero.

Makna kolom masa berlaku password

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Angka tersebut adalah kolom 4 hingga 8 pada baris pengguna tersebut di /etc/shadow. Hari minimum (chage -m) adalah waktu tunggu sebelum pengguna dapat mengubah password lagi. Pengaturan ini mencegah pengguna langsung kembali ke password lama setelah perubahan yang diwajibkan. Hari maksimum (chage -M) adalah lamanya password tetap valid. Hari peringatan (chage -W) menentukan kapan login mulai menampilkan peringatan. Hari tidak aktif (chage -I) adalah masa tenggang setelah password kedaluwarsa sebelum password tidak lagi diterima sama sekali. Kedaluwarsa akun (chage -E) adalah tanggal tetap dan tidak bergantung pada password.

sudo chage -M 90 -W 14 deploy

Atur nilai tersebut hanya jika diwajibkan oleh kebijakan. NIST (National Institute of Standards and Technology Amerika Serikat) sejak 2017 menyarankan agar kedaluwarsa password rutin tidak diterapkan. Kebijakan tersebut mendorong pengguna membuat variasi yang mudah diprediksi dari satu password. NIST merekomendasikan perubahan password jika terdapat bukti bahwa password telah disusupi. Password unik yang panjang dan disimpan dalam password manager, ditambah SSH berbasis key, lebih baik daripada siklus 90 hari.

Yang harus dilakukan jika Anda kehilangan password root

Jika akun apa pun pada server dapat menjalankan sudo, tidak ada yang perlu dipulihkan: sudo passwd root akan menetapkan password baru. Situasi yang sulit terjadi jika tidak ada login yang berfungsi sama sekali.

Semua langkah berikut memerlukan console dari provider, yang biasanya tercantum sebagai VNC (virtual network computing) atau serial console pada sebagian besar panel. Console ini terhubung ke virtual machine di bawah network stack, sehingga pengaturan sshd dan aturan firewall tidak memengaruhinya.

1. Reboot server dari panel, lalu pantau console.
2. Tampilkan menu GRUB. Cloud image biasanya menetapkan GRUB_TIMEOUT=0, jadi tahan Shift saat boot BIOS, atau tekan Esc berulang kali saat boot UEFI, segera setelah reboot dimulai.
3. Pilih Advanced options for Ubuntu, lalu entry yang diakhiri (recovery mode), kemudian root pada recovery menu.
4. Jalankan mount -o remount,rw / terlebih dahulu. Recovery memasang root filesystem dalam mode read-only, sehingga tanpa langkah ini passwd gagal dengan passwd: Authentication token manipulation error karena tidak dapat menulis ke /etc/shadow.
5. Jalankan passwd ubuntu untuk akun yang diperlukan, lalu reboot dari panel.

Jika root sudah memiliki password dan password itulah yang hilang, recovery shell tersebut akan memintanya sehingga metode ini tidak dapat dilanjutkan. Boot rescue image milik provider sebagai gantinya, lalu mount disk yang sebenarnya dan ubah password di dalamnya.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Baca tata letak partition dari lsblk, bukan menyalin /dev/vda1 dari halaman ini. Root partition adalah partition yang berukuran besar. Pada UEFI image, partition tersebut berada di samping EFI partition kecil yang sama sekali tidak berisi direktori /etc.

Tindakan saat SSH berhenti menerima kata sandi

Bekerjalah dari sesi yang masih terbuka. Jika tidak ada sesi yang tersisa, gunakan konsol.

Permission denied, please try again. berarti server menawarkan autentikasi kata sandi, tetapi menolak input yang Anda kirimkan. Penyebab yang umum adalah Caps Lock aktif atau tata letak keyboard pada konsol berbeda dari tata letak yang digunakan saat Anda menetapkan kata sandi.

Permission denied (publickey). berarti server tidak pernah menawarkan autentikasi kata sandi. PasswordAuthentication no diatur di suatu tempat, dan pada Ubuntu 22.04 serta versi yang lebih baru, pengaturan ini biasanya berada dalam file drop-in di bawah /etc/ssh/sshd_config.d/ yang menimpa file utama. Baca nilai efektifnya:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes bersama PasswordAuthentication no tetap memungkinkan kata sandi digunakan, karena metode keyboard-interactive menjalankan stack PAM yang sama. Menonaktifkan salah satunya dan membiarkan yang lain aktif membuat server yang tampak hanya menerima key tetap menerima kata sandi yang diketik.

Baris yang sama juga ditampilkan oleh login menggunakan key yang ditolak. Jadi, jika yang Anda tawarkan adalah key, bukan kata sandi, pengaturan kata sandi server hanya merupakan satu dari lima masalah yang menyebabkan Permission denied (publickey), dan output ssh -v menunjukkan masalah yang terjadi.

Too many authentication failures dalam pesan pemutusan koneksi berarti client Anda menawarkan beberapa key sebelum beralih ke kata sandi, dan server mencapai MaxAuthTries, yang secara default bernilai 6. Paksa penggunaan satu metode:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused pada port yang masih berfungsi satu menit lalu biasanya berarti fail2ban yang memantau SSH memblokir alamat Anda setelah terjadi kegagalan berulang. Aturan ban default-nya menolak paket, bukan membuangnya, sehingga penolakan segera diterima dan bukan mengalami timeout. Dari konsol, sudo fail2ban-client status sshd menampilkan alamat yang diblokir, dan sudo fail2ban-client set sshd unbanip 203.0.113.10 menghapus alamat Anda dari daftar tersebut.

Password adalah tahap peralihan, kunci adalah tujuan akhir

Password yang dapat digunakan melalui SSH adalah password yang dapat ditebak oleh setiap pemindai di Internet. Beralihlah ke autentikasi berbasis kunci agar upaya menebak tidak lagi relevan. Buat pasangan kunci, pasang bagian publiknya, lalu pastikan kunci tersebut dapat digunakan untuk login dari terminal kedua sebelum mengubah hal lain. Dasar-dasar pengelolaan kunci SSH membahas pembuatan kunci, authorized_keys, dan passphrase.

Selanjutnya, nonaktifkan autentikasi password dan konfirmasikan hasilnya dengan sudo sshd -T, bukan dengan mengandalkan file yang Anda edit. memperkuat keamanan SSH pada VPS membahas pengaturan sshd lain yang perlu diubah, sedangkan sepuluh menit pertama pada VPS baru mengurutkan langkah-langkah yang perlu dilakukan pada server baru.

Setelah itu, tetap simpan satu password. Server yang hanya menggunakan kunci dengan konfigurasi sshd yang rusak hanya dapat diakses melalui konsol provider, dan konsol tersebut meminta username serta password. Akun dengan password kuat yang telah Anda simpan dapat menentukan apakah perbaikan selesai dalam lima menit atau Anda harus melakukan instalasi ulang.

FAQ

Bagaimana cara mengubah password root pada VPS jika saya tidak mengetahui password lama?

Login sebagai user yang dapat menjalankan sudo, lalu jalankan sudo passwd root. Perintah tersebut menetapkan password baru tanpa meminta password lama karena sudo telah mengautentikasi Anda. Jika tidak ada akun pada server yang dapat menjalankan sudo, buka konsol provider, reboot ke menu recovery GRUB, pilih entri shell root, jalankan mount -o remount,rw /, lalu jalankan passwd. Jika root sudah memiliki password dan password itulah yang hilang, recovery shell akan memintanya. Jalur yang tersisa adalah menggunakan rescue image dari provider dengan disk ter-mount dan lingkungan chroot.

Mengapa passwd menampilkan "Authentication token manipulation error"?

Ada dua penyebab pesan tersebut. Penyebab yang umum adalah jawaban yang salah pada prompt Current password:. Baris passwd: password unchanged di bawahnya mengonfirmasi bahwa tidak ada perubahan yang ditulis. Penyebab lainnya adalah filesystem yang tidak dapat ditulis. Kondisi ini sering terjadi dalam recovery mode karena / di-mount sebagai read-only di sana. Jalankan mount -o remount,rw /, lalu coba lagi.

Apakah mengubah password Linux juga mengubah password sudo?

Ya. sudo tidak memiliki password sendiri. Perintah tersebut mengautentikasi Anda melalui PAM terhadap entri /etc/shadow yang sama dengan yang digunakan SSH dan su. Jadi, setiap akun memiliki satu password. Karena itu, prompt sudo pertama setelah perubahan password merupakan pengujian yang sebenarnya. Jalankan sudo -k && sudo -v untuk memaksa prompt tersebut saat Anda masih memiliki session yang berfungsi.

Apakah mengubah password akan merusak SSH key atau session yang sedang terbuka?

Tidak. Autentikasi public key tidak pernah membaca /etc/shadow. Karena itu, key tetap berfungsi setelah perubahan password, setelah passwd -l, dan setelah chage -d 0. Session yang sudah terbuka tetap berjalan karena SSH hanya memeriksa kredensial saat login. Satu-satunya hal yang berubah di dalam session aktif adalah sudo, yang meminta password baru setelah timestamp 15 menitnya kedaluwarsa.

Bagaimana cara memaksa user mengubah password pada login berikutnya?

Jalankan sudo chage -d 0 deploy atau sudo passwd -e deploy, yang melakukan hal yang sama. Tanggal perubahan terakhir yang tersimpan diatur ke epoch. PAM kemudian menganggap password telah kedaluwarsa, dan login interaktif berikutnya harus menetapkan password baru sebelum shell dimulai. Jangan lakukan ini pada akun yang digunakan script melalui SSH. Perintah non-interaktif kemudian gagal dengan Password change required but no TTY available. dan tidak pernah dijalankan.