Cara Mengubah Kata Sandi Root VPS di Ubuntu

Cara mengubah kata sandi root VPS di Ubuntu

Untuk mengubah kata sandi root VPS (server privat virtual) 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. Semua hal di bawah ini membahas masalah yang dapat terjadi: memverifikasi bahwa 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 saat 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 kedaluwarsa akun yang terkait dengannya, karena SSH memeriksa kredensial saat login dan tidak memeriksanya lagi. Pengecualiannya adalah sudo. sudo memeriksa ulang kata sandi melalui PAM (modul autentikasi pluggable) setelah timestamp-nya kedaluwarsa, secara default 15 menit setelah permintaan terakhir. Jadi, kata sandi baru pertama kali 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 keluaran yang berarti hash di /etc/shadow telah diganti. Keluaran lainnya 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 sistem berkas yang memuat /etc/shadow tidak dapat ditulis. Kondisi ini normal dalam mode pemulihan. You must choose a longer password. berasal dari pam_unix di /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 oleh provider Anda) tidak memiliki kata sandi sama sekali, hanya kunci SSH. 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 milik image mengizinkan akun tersebut menjalankan sudo tanpa kata sandi.

Mengubah 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 dengannya. sudo passwd -u deploy menghapusnya. Baca kembali statusnya dengan sudo passwd -S deploy.

Mengunci kata sandi tidak mencegah pengguna tersebut untuk login. Kunci apa pun di ~/.ssh/authorized_keys tetap berfungsi karena autentikasi kunci publik tidak pernah membaca /etc/shadow. Untuk menghentikan 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 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 rilis lama yang masih memuat nullok dalam stack PAM, kata sandi kosong dapat digunakan oleh siapa saja.

Apakah root memerlukan kata sandi pada VPS?

Ubuntu dirilis dengan akun root yang terkunci. /etc/shadow menyimpan ! sebagai pengganti hash, dan sudo passwd -S root menampilkan baris yang diawali root L. Tidak ada yang dapat masuk sebagai root menggunakan kata sandi sampai Anda menetapkannya. Karena itu, image menyediakan pengguna dengan akses sudo. Gunakan akun pengguna dengan hak minimum pada VPS, bukan root.

Menetapkan kata sandi root memberikan satu manfaat khusus: akses melalui konsol penyedia. Konsol tersebut terhubung ke mesin virtual di bawah lapisan jaringan. Karena itu, konsol tetap berfungsi ketika sshd salah dikonfigurasi atau aturan firewall keliru. Namun, tindakan ini juga memiliki konsekuensi. Menu pemulihan GRUB meminta kata sandi root jika root memilikinya. Akibatnya, alat yang digunakan untuk mengatur ulang kata sandi yang terlupa kini berada di balik kata sandi yang sama.

Menetapkan kata sandi root tidak memungkinkan root masuk melalui SSH. Ubuntu dirilis dengan PermitRootLogin prohibit-password, yang berarti hanya kunci. Periksa konfigurasi yang sebenarnya digunakan server Anda:

sudo sshd -T | grep -i permitrootlogin

sshd -T menampilkan konfigurasi efektif setelah setiap baris Include diselesaikan. Karena itu, perintah ini 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 dari terminal dan tidak dapat dijalankan dari skrip. chpasswd membaca pasangan user:password dari input standar, satu pasangan per baris.

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

Cara ini berhasil, tetapi memasukkan kata sandi teks biasa ke dalam riwayat shell dan log CI (continuous integration). 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 SHA-512 crypt yang diawali $6$. -e memberi tahu chpasswd bahwa field kedua sudah berupa hash, sehingga nilainya disalin ke /etc/shadow apa adanya. Hash tersebut aman disimpan di repositori 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. Hal ini tidak berlaku untuk chpasswd -c YESCRYPT: paket shadow yang lebih lama pada 20.04 tidak mengenali nama metode tersebut.

Bagaimana cara memeriksa bahwa kata sandi benar-benar 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 untuk akun tanpa kata sandi. Tanggal tersebut menunjukkan kapan kata sandi terakhir diubah, sehingga seharusnya berisi tanggal hari ini. Angka setelahnya adalah kolom masa berlaku yang dijelaskan di bawah.

Pengujian langsung yang paling aman adalah sudo itu sendiri. sudo -k membuang stempel waktu yang tersimpan di cache, sedangkan sudo -v memaksa permintaan kata sandi 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 sehingga 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 yang berfungsi 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 login. Permission denied, please try again. berarti server memang menawarkannya, tetapi menolak masukan Anda.

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

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

Password change required but no TTY available.

Tidak ada perintah setelah baris tersebut yang dijalankan, dan tugas hanya melaporkan kode keluar nonzero.

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-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 mengganti kata sandi lagi. Pengaturan ini mencegah pengguna segera kembali menggunakan kata sandi lama setelah perubahan yang diwajibkan. Hari maksimum (chage -M) adalah lama waktu kata sandi tetap berlaku. Hari peringatan (chage -W) menentukan kapan login mulai menampilkan peringatan. Hari tidak aktif (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 (Institut Nasional Standar dan Teknologi Amerika Serikat) sejak 2017 menyarankan agar kedaluwarsa kata sandi rutin tidak diterapkan. Pengaturan tersebut mendorong pengguna membuat variasi yang mudah ditebak dari satu kata sandi. NIST merekomendasikan perubahan kata sandi jika terdapat bukti bahwa kata sandi telah disusupi. Kata sandi panjang dan unik yang disimpan dalam pengelola kata sandi, ditambah SSH berbasis kunci, lebih baik daripada siklus 90 hari.

Yang harus dilakukan jika Anda kehilangan kata sandi root

Jika akun mana pun di server 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 penyedia, yang biasanya tercantum di sebagian besar panel sebagai VNC (virtual network computing) atau konsol serial. Konsol ini terhubung ke mesin virtual di bawah tumpukan jaringan, sehingga pengaturan sshd dan aturan firewall tidak memengaruhinya.

1. Nyalakan ulang server dari panel dan pantau konsol.
2. Tampilkan menu GRUB. Image cloud biasanya menetapkan GRUB_TIMEOUT=0, jadi tahan Shift saat boot BIOS, atau tekan Esc berulang kali saat boot UEFI, segera setelah proses mulai ulang dimulai.
3. Pilih Advanced options for Ubuntu, lalu entri yang diakhiri dengan (recovery mode), kemudian root di menu pemulihan.
4. Jalankan mount -o remount,rw / terlebih dahulu. Dalam mode pemulihan, sistem berkas root dipasang hanya-baca. 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 nyalakan ulang dari panel.

Jika root sudah memiliki kata sandi dan kata sandi itulah yang hilang, shell pemulihan akan memintanya dan jalur ini tidak dapat digunakan. Boot image penyelamatan milik penyedia, lalu pasang 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 besar. Pada image UEFI, partisi ini berada di sebelah partisi EFI kecil yang sama sekali tidak memiliki direktori /etc.

Tindakan saat SSH berhenti menerima kata sandi Anda

Gunakan sesi yang masih tersedia. Jika tidak ada sesi yang tersisa, gunakan konsol.

Permission denied, please try again. berarti server menawarkan autentikasi kata sandi dan menolak data yang Anda kirim. Penyebab yang umum adalah caps lock aktif atau tata letak papan ketik di konsol berbeda dari yang digunakan saat menetapkan kata sandi.

Permission denied (publickey). berarti server tidak pernah menawarkan autentikasi kata sandi. PasswordAuthentication no ditetapkan di suatu tempat. Pada Ubuntu 22.04 dan versi 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 dapat membuat server yang tampak hanya menerima kunci tetap menerima kata sandi yang diketik.

Too many authentication failures dalam pesan pemutusan koneksi berarti klien Anda menawarkan beberapa kunci 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 telah memblokir alamat Anda setelah beberapa kegagalan. Aturan pemblokiran default-nya menolak paket, bukan membuangnya, sehingga penolakan muncul dengan cepat dan tidak mengalami waktu habis. 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.

Kata sandi adalah langkah antara, kunci adalah tujuan akhir

Kata sandi yang dapat digunakan melalui SSH adalah kata sandi yang dapat ditebak oleh setiap pemindai di internet. Gunakan autentikasi berbasis kunci agar upaya menebak kata sandi tidak lagi relevan. Buat pasangan kunci, pasang bagian publiknya, lalu pastikan kunci tersebut dapat memasukkan Anda dari terminal kedua sebelum mengubah hal lain. Dasar-dasar pengelolaan kunci SSH membahas pembuatan kunci, authorized_keys, dan frasa sandi.

Selanjutnya, nonaktifkan autentikasi kata sandi 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. sepuluh menit pertama pada VPS baru menempatkan pengaturan tersebut dalam urutan penerapannya pada server baru.

Setelah itu, simpan satu kata sandi. Server yang hanya menggunakan kunci dengan konfigurasi sshd yang rusak hanya dapat diakses melalui konsol penyedia, dan konsol tersebut meminta nama pengguna serta kata sandi. Akun dengan kata sandi kuat yang Anda simpan dapat membedakan perbaikan selama lima menit dari instalasi ulang.

FAQ

Bagaimana cara mengubah kata sandi root di 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 telah mengautentikasi Anda. Jika tidak ada akun di server yang dapat menjalankan sudo, buka konsol penyedia, 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 rescue penyedia, pasang 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 / dipasang 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 terhadap 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 merupakan pengujian yang sebenarnya. Jalankan sudo -k && sudo -v untuk memaksa prompt tersebut saat sesi Anda masih berfungsi.

Apakah mengubah kata sandi akan membuat kunci SSH atau sesi yang sedang terbuka tidak berfungsi?

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 aktif karena SSH hanya memeriksa kredensial saat login. Satu-satunya hal yang berubah dalam sesi aktif adalah sudo, yang meminta kata sandi baru setelah stempel waktu 15 menitnya kedaluwarsa.

Bagaimana cara memaksa pengguna mengubah kata sandinya saat 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 menganggap kata sandi tersebut 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 kemudian gagal dengan Password change required but no TTY available. dan tidak pernah dijalankan.