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 sebanyak dua kali dan tidak pernah meminta kata sandi lama, karena sudo telah 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 Anda kehilangan sesi yang dapat digunakan untuk memperbaikinya, menetapkan kata sandi dari skrip, sengaja membuat kata sandi kedaluwarsa, dan mendapatkan kembali akses ketika kata sandi sudah tidak diketahui.

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 tertutup, Anda mungkin perlu mengakses konsol.

Shell yang sudah terbuka tetap berfungsi setelah Anda mengubah, mengunci, atau membuat kedaluwarsa akun yang terkait dengannya, karena SSH memeriksa kredensial saat login dan tidak memeriksanya lagi. Pengecualiannya adalah sudo. Program ini memeriksa ulang kata sandi melalui PAM (modul autentikasi yang dapat dicolokkan) setelah stempel waktunya 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 dalam 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 keluaran yang berarti hash dalam /etc/shadow telah diganti. Keluaran lain berarti kata sandi lama tetap digunakan.

Dua kegagalan terjadi di sini. passwd: Authentication token manipulation error, diikuti oleh passwd: password unchanged, berarti kata sandi saat ini yang Anda masukkan salah, atau filesystem yang menyimpan /etc/shadow tidak dapat ditulis. Ini adalah kondisi 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 untuk pengguna biasa.

Pada sebagian besar image VPS, akun default (ubuntu, atau nama apa pun yang disediakan provider Anda) tidak memiliki kata sandi, melainkan hanya SSH key. passwd tidak memiliki kata sandi saat ini untuk diverifikasi, sehingga tidak dapat melewati prompt pertama. Sebagai gantinya, gunakan sudo passwd $USER. Cara ini berhasil karena file drop-in sudoers milik image tersebut mengizinkan akun itu 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 adalah tindakan terpisah. sudo passwd -l deploy menambahkan ! di depan hash yang tersimpan, sehingga tidak ada kata sandi yang cocok. sudo passwd -u deploy menghapusnya. Baca kembali statusnya dengan sudo passwd -S deploy.

Mengunci kata sandi tidak menghentikan pengguna tersebut untuk login. Semua kunci dalam ~/.ssh/authorized_keys tetap dapat digunakan karena autentikasi kunci publik tidak pernah membaca /etc/shadow. Untuk menonaktifkan akun sepenuhnya, kedaluwarsakan akun itu sendiri:

sudo usermod --expiredate 1 deploy

Perintah tersebut menetapkan masa berlaku akun ke tanggal pada tahun 1970, sehingga sshd menolak login dengan kredensial apa pun. Batalkan perubahan ini dengan sudo usermod --expiredate '' deploy.

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

Apakah root memerlukan password pada VPS?

Ubuntu menyediakan root dalam keadaan terkunci. /etc/shadow berisi !, bukan hash, dan sudo passwd -S root menampilkan baris yang diawali root L. Tidak ada yang dapat login sebagai root menggunakan password sebelum 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 mesin virtual di bawah lapisan jaringan. Karena itu, konsol tetap berfungsi saat konfigurasi sshd salah atau aturan firewall keliru. Namun, tindakan ini juga memiliki konsekuensi. Menu pemulihan GRUB meminta password root jika root memiliki password. Artinya, tool yang Anda gunakan untuk mengatur ulang password yang terlupa kini berada di balik password yang sama.

Menetapkan password root tidak memungkinkan root login melalui SSH. Ubuntu menyediakan PermitRootLogin prohibit-password, yang berarti hanya key yang dapat digunakan. Periksa konfigurasi 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 merupakan satu-satunya jawaban yang akurat jika /etc/ssh/sshd_config.d/ memuat file drop-in.

Tetapkan 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 berfungsi, 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 $6$. -e memberi tahu chpasswd bahwa kolom kedua sudah berupa hash, sehingga nilainya disalin apa adanya ke /etc/shadow. Hash tersebut aman disimpan di repositori atau variabel CI, dan teks biasa tidak pernah meninggalkan 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 telah berubah?

Mulai dengan metadata, lalu buktikan dengan login.

sudo passwd -S deploy

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

Kolom 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 kolom masa berlaku yang dibahas di bawah.

Pengujian langsung yang paling aman adalah sudo itu sendiri. sudo -k membuang timestamp yang tersimpan di cache, sedangkan sudo -v memaksa prompt baru. Jika kata sandi baru diterima di sana, PAM telah menerimanya dan tidak ada yang berubah 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 input yang Anda masukkan.

Paksa perubahan kata sandi saat 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 cara ini hanya untuk akun yang login secara interaktif menggunakan kata sandi. Kata sandi yang kedaluwarsa juga memengaruhi login berbasis key karena sshd menjalankan tahap account PAM meskipun autentikasi dilakukan menggunakan key. 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 exit code yang bukan nol.

Arti kolom masa berlaku kata sandi

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 yang harus dilalui pengguna sebelum dapat mengubah kata sandi lagi. Pengaturan ini mencegah pengguna langsung kembali menggunakan kata sandi lama setelah perubahan yang diwajibkan. Hari maksimum (chage -M) adalah lamanya kata sandi tetap berlaku. Hari peringatan (chage -W) menentukan kapan login mulai menampilkan peringatan. Hari nonaktif (chage -I) adalah masa tenggang setelah kata sandi kedaluwarsa sebelum kata sandi tersebut tidak lagi diterima. Kedaluwarsa akun (chage -E) adalah tanggal tetap dan tidak bergantung pada kata sandi.

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 kata sandi rutin tidak diterapkan. Kebijakan tersebut mendorong orang menggunakan variasi kata sandi yang sama dan mudah diprediksi. NIST merekomendasikan perubahan kata sandi jika terdapat bukti bahwa kata sandi telah disusupi. Kata sandi panjang dan unik yang disimpan dalam password manager, ditambah SSH berbasis key, lebih aman daripada siklus 90 hari.

Yang harus dilakukan jika Anda kehilangan kata sandi root

Jika ada akun pada server yang dapat menjalankan sudo, tidak ada yang perlu dipulihkan: sudo passwd root menetapkan kata sandi baru. Kasus yang sulit adalah ketika tidak ada login yang berfungsi sama sekali.

Semua langkah berikut memerlukan konsol provider, yang biasanya tercantum di sebagian besar panel sebagai VNC (virtual network computing) atau konsol serial. Konsol ini terhubung ke mesin virtual di bawah lapisan jaringan, sehingga pengaturan sshd dan aturan firewall tidak memengaruhinya.

1. Reboot server dari panel, lalu pantau konsol.
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 proses reboot dimulai.
3. Pilih Advanced options for Ubuntu, lalu entri yang diakhiri dengan (recovery mode), kemudian root pada menu pemulihan.
4. Jalankan mount -o remount,rw / terlebih dahulu. Recovery memasang root filesystem dalam mode hanya-baca, sehingga tanpa langkah ini passwd gagal dengan pesan 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 kata sandi dan kata sandi itulah yang hilang, recovery shell akan meminta kata sandi tersebut sehingga cara ini tidak dapat digunakan. Boot rescue image milik provider, lalu mount disk sebenarnya dan ubah kata sandi 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 partisi dari lsblk, bukan menyalin /dev/vda1 dari halaman ini. Partisi root adalah partisi yang berukuran besar. Pada image UEFI, partisi tersebut berada di sebelah partisi EFI kecil yang sama sekali tidak memiliki direktori /etc.

Yang harus dilakukan ketika SSH berhenti menerima kata sandi

Gunakan 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 kata sandi yang Anda kirim. 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 ditetapkan di suatu tempat, dan pada Ubuntu 22.04 serta versi yang lebih baru, pengaturannya 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 penggunaan kata sandi karena metode keyboard-interactive menjalankan stack PAM yang sama. Menonaktifkan salah satunya dan membiarkan yang lain tetap aktif membuat server yang terlihat hanya menerima key tetap menerima kata sandi yang diketik.

Too many authentication failures dalam pesan pemutusan koneksi berarti klien Anda menawarkan beberapa key sebelum mencoba kata sandi, lalu 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 berfungsi satu menit sebelumnya biasanya berarti fail2ban yang memantau SSH memblokir alamat Anda setelah beberapa kegagalan. Aturan pemblokiran default-nya menolak paket, bukan mengabaikannya. Karena itu, penolakan muncul dengan cepat, 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 awal, key adalah hasil akhirnya

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

Setelah itu, nonaktifkan autentikasi password, lalu konfirmasikan 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 tersebut untuk diterapkan pada server baru.

Setelah itu, tetap simpan satu password. Server yang hanya menggunakan key dengan konfigurasi sshd yang rusak hanya dapat diakses melalui konsol provider, dan konsol tersebut meminta username serta password. Akun dengan password kuat yang Anda simpan adalah pembeda antara perbaikan selama lima menit dan instalasi ulang.

FAQ

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

Login sebagai pengguna yang dapat menjalankan sudo, lalu jalankan sudo passwd root. Perintah tersebut menetapkan kata sandi baru tanpa meminta kata sandi lama, karena sudo sudah mengautentikasi Anda. Jika tidak ada akun pada server yang dapat menjalankan sudo, buka konsol provider, reboot ke menu pemulihan GRUB, pilih entri shell root, jalankan mount -o remount,rw /, lalu jalankan passwd. Jika root sudah memiliki kata sandi dan kata sandi itulah yang hilang, shell pemulihan akan memintanya. Dalam kondisi tersebut, gunakan image penyelamatan dari provider, mount disk, lalu jalankan 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 terjadi dalam mode pemulihan karena / di-mount sebagai read-only. Jalankan mount -o remount,rw /, lalu coba lagi.

Apakah mengubah kata sandi Linux juga mengubah kata sandi sudo?

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

Apakah mengubah kata sandi akan merusak kunci SSH atau sesi yang sedang terbuka?

Tidak. Autentikasi kunci publik tidak pernah membaca /etc/shadow. Karena itu, kunci tetap berfungsi setelah perubahan kata sandi, setelah passwd -l, dan setelah chage -d 0. Sesi yang sudah terbuka tetap berjalan karena SSH hanya memeriksa kredensial saat login. Satu-satunya hal yang berubah dalam sesi aktif adalah sudo. Perintah tersebut meminta kata sandi baru setelah timestamp 15 menit berakhir.

Bagaimana cara memaksa pengguna mengubah kata sandi pada login berikutnya?

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