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 satu 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 kedaluwarsa, karena SSH memeriksa kredensial saat login dan tidak memeriksanya lagi. Pengecualiannya adalah sudo. sudo memeriksa ulang kata sandi melalui PAM (pluggable authentication modules) setelah kredensial yang di-cache kedaluwarsa. Di Ubuntu, masa berlaku ini secara default adalah 15 menit. Waktu tersebut tidak dihitung sejak prompt terakhir, karena sudo -v memperbarui kredensial yang di-cache tanpa meminta kata sandi lagi. Jadi, kata sandi baru pertama kali benar-benar diuji saat sudo benar-benar 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 adalah tindakan terpisah. sudo passwd -l deploy menambahkan ! di depan hash yang disimpan, 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 menghentikan pengguna tersebut untuk login. Kunci apa pun di dalam ~/.ssh/authorized_keys miliknya tetap berfungsi karena autentikasi kunci publik tidak memeriksa hash kata sandi. Untuk menghentikan akun sepenuhnya, kedaluwarsakan akun itu sendiri:

sudo usermod --expiredate 1 deploy

Perintah tersebut menetapkan kedaluwarsa akun ke tanggal pada tahun 1970, sehingga sshd menolak login apa pun kredensial yang ditawarkan. 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 tumpukan PAM, kata sandi kosong dapat digunakan oleh siapa pun.

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.

Tetapkan kata sandi dari skrip dengan chpasswd

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

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

Cara tersebut berhasil, tetapi kata sandi teks biasa akan tersimpan dalam riwayat shell dan log CI (continuous integration). Buat hash 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 karakter yang diketik, lalu mencetak hash SHA-512 crypt yang diawali dengan $6$. -e memberi tahu chpasswd bahwa field kedua sudah berupa hash, sehingga nilainya disalin ke /etc/shadow tanpa perubahan. Hash tersebut aman disimpan di repository atau variabel CI, dan teks biasa tidak pernah meninggalkan mesin tempat Anda mengetikkannya.

Ubuntu 24.04 membuat hash kata sandi baru dengan yescrypt ($y$) ketika passwd menetapkannya, sedangkan openssl passwd -6 menghasilkan SHA-512. Keduanya dapat diverifikasi saat login karena libxcrypt dapat membaca kedua format tersebut. Mencampur keduanya tidak masalah, dan openssl passwd -6 berperilaku sama pada setiap rilis Ubuntu LTS mulai dari 18.04. Namun, chpasswd -c YESCRYPT tidak demikian: paket shadow yang lebih lama pada 20.04 tidak mengenali nama metode tersebut. Ubuntu 16.04 merupakan pengecualian karena OpenSSL 1.0.2 pada versi itu sama sekali tidak memiliki opsi -6. Hash tersebut juga tetap valid setelah upgrade ke rilis berikutnya, sehingga memindahkan server 24.04 ke 26.04 tidak memaksa 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.

Paksa 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 persis.

Gunakan ini hanya untuk akun yang melakukan login interaktif dengan kata sandi. Kata sandi yang kedaluwarsa juga memengaruhi login berbasis key, karena sshd menjalankan tahap account PAM meskipun autentikasi dilakukan dengan key. ssh deploy@203.0.113.10 'systemctl restart app' yang dijalankan dari script kemudian gagal dengan pesan berikut sebelum perintah dijalankan:

Password change required but no TTY available.

Perintah jarak jauh tidak pernah dijalankan dan ssh keluar dengan kode non-zero. Jika script pemanggil tidak berhenti saat terjadi error, baik dengan set -e maupun dengan pemeriksaan eksplisit, baris setelahnya tetap dijalankan dan job dapat selesai seolah-olah restart telah terjadi.

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.

Apa yang harus dilakukan ketika SSH tidak lagi 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 data 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, sehingga nilai efektifnya adalah PasswordAuthentication no. no tersebut dapat berada di file utama atau di drop-in, jadi periksa keduanya. sshd membaca file di bawah /etc/ssh/sshd_config.d/ pada awal pemuatan konfigurasi dan menggunakan nilai pertama yang ditemukan untuk setiap kata kunci, sehingga drop-in mengesampingkan /etc/ssh/sshd_config. Aturan yang sama sering berlaku sebaliknya pada server Ubuntu 24.04 yang diinstal dari ISO dengan SSH diaktifkan: installer membuat drop-in cloud-init, 50-cloud-init.conf, yang menetapkan PasswordAuthentication yes, sehingga no yang ditambahkan ke file utama diabaikan. 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 PAM stack yang sama. Menonaktifkan salah satunya dan membiarkan yang lain aktif menyebabkan server yang tampak hanya menerima key tetap menerima kata sandi yang diketik.

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

Too many authentication failures dalam pesan pemutusan koneksi berarti koneksi tersebut telah menggunakan seluruh batas MaxAuthTries server, yang secara default adalah 6 percobaan. Penyebab yang umum adalah client yang menawarkan beberapa key sebelum mencoba kata sandi. 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 telah memblokir alamat Anda setelah kegagalan berulang. Aturan pemblokiran default-nya menolak paket, bukan membuangnya, sehingga penolakan segera diterima dan koneksi tidak 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 pengguna 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 pemulihan GRUB, pilih entri shell root, jalankan mount -o remount,rw /, lalu jalankan passwd. Jika root sudah memiliki password dan password itulah yang hilang, shell pemulihan akan memintanya. Dalam kondisi tersebut, gunakan image rescue dari provider, mount disk, lalu jalankan chroot.

Mengapa passwd menampilkan "Authentication token manipulation error"?

Pesan tersebut disebabkan oleh 2 hal. 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 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, sehingga setiap akun memiliki satu password. Karena itu, prompt sudo pertama setelah perubahan merupakan pengujian yang sebenarnya. Jalankan sudo -k && sudo -v untuk memaksa prompt tersebut saat sesi Anda masih berfungsi.

Apakah perubahan password akan merusak SSH key atau sesi yang sedang terbuka?

Perubahan password atau passwd -l tidak akan merusaknya. Autentikasi public key tidak memeriksa hash password, sehingga key tetap berfungsi setelah salah satunya diubah. chage -d 0 berbeda: sshd tetap menjalankan pemeriksaan akun PAM setelah login menggunakan key. Pemeriksaan tersebut membaca field masa berlaku password dalam /etc/shadow. Karena itu, password yang kedaluwarsa membuat login menggunakan key meminta password baru dan membuat perintah SSH terotomasi gagal. Sesi yang sudah terbuka tetap berjalan karena SSH hanya memeriksa kredensial saat login. Satu-satunya hal yang berubah dalam sesi aktif adalah sudo, yang meminta password baru setelah timestamp 15 menitnya kedaluwarsa.

Bagaimana cara memaksa pengguna 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 diubah ke epoch. PAM kemudian menganggap password tersebut kedaluwarsa, dan login interaktif berikutnya harus menetapkan password baru sebelum shell dimulai. Jangan lakukan ini pada akun yang digunakan oleh script melalui SSH. Perintah non-interaktif kemudian gagal dengan Password change required but no TTY available. dan tidak pernah dijalankan.