Cara Tukar Kata Laluan Root VPS Ubuntu

Cara menukar kata laluan root VPS anda pada Ubuntu

Untuk menukar kata laluan root VPS (virtual private server) anda pada Ubuntu, buka sesi SSH (secure shell) sebagai pengguna yang boleh menjalankan sudo, kemudian jalankan sudo passwd root. Ia akan meminta kata laluan baharu sebanyak dua kali dan tidak akan meminta kata laluan lama, kerana sudo telah pun mengesahkan identiti anda. Untuk menukar kata laluan log masuk anda sendiri, jalankan passwd tanpa sebarang argumen, dan ia akan meminta kata laluan semasa anda terlebih dahulu.

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

Itu sahaja keseluruhan operasinya. Segala perkara di bawah adalah bahagian yang sering bermasalah: mengesahkan kata laluan baharu berfungsi sebelum anda kehilangan sesi yang boleh membaikinya, menetapkan kata laluan daripada skrip, menamatkan tempoh kata laluan secara sengaja, dan mendapatkan semula akses apabila kata laluan telah hilang.

Buka sesi kedua sebelum anda menukar kata laluan

Buka sesi SSH kedua sekarang dan biarkan ia terus bersambung. Hampir setiap kegagalan dalam panduan ini boleh dibaiki dalam masa dua minit selagi satu shell yang telah disahkan masih aktif, berbanding perlu mengakses konsol fizikal sebaik sahaja sesi terakhir ditutup.

Shell yang sudah dibuka akan terus berfungsi selepas anda menukar, mengunci, atau menamatkan tempoh akaun tersebut, kerana SSH menyemak kelayakan semasa log masuk dan tidak menyemaknya semula. Pengecualiannya ialah sudo. Ia menyemak semula kata laluan anda melalui PAM (pluggable authentication modules) sebaik sahaja tanda masanya tamat, iaitu 15 minit selepas arahan terakhir secara lalai. Jadi, kata laluan baharu hanya akan diuji secara sebenar apabila sudo memintanya, bukan semasa log masuk.

Uji kata laluan baharu dalam sesi kedua sementara sesi pertama dibiarkan terbuka.

Tukar kata laluan anda sendiri dengan passwd

passwd

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

passwd: password updated successfully ialah satu-satunya output yang bermaksud hash dalam /etc/shadow telah digantikan. Sebarang output lain bermakna kata laluan lama masih dikekalkan.

Dua kegagalan sering berlaku di sini. passwd: Authentication token manipulation error, diikuti oleh passwd: password unchanged, bermaksud kata laluan semasa yang anda taip adalah salah, atau sistem fail yang menyimpan /etc/shadow tidak boleh ditulis, yang merupakan keadaan biasa dalam mod pemulihan (recovery mode). You must choose a longer password. datang daripada pam_unix dalam /etc/pam.d/common-password, yang mengenakan semakan panjang dan kesamaan terhadap pengguna biasa.

Pada kebanyakan imej VPS, akaun lalai (ubuntu, atau apa jua nama yang dibekalkan oleh penyedia anda) tidak mempunyai kata laluan, hanya kunci SSH. passwd tidak mempunyai kata laluan semasa untuk disemak, jadi ia tidak boleh melepasi gesaan pertama. Gunakan sudo passwd $USER sebaliknya, yang berfungsi kerana fail sudoers drop-in pada imej tersebut membenarkan akaun itu menjalankan sudo tanpa kata laluan.

Tukar kata laluan pengguna lain dengan sudo passwd

sudo passwd deploy

Root tidak diminta untuk memasukkan kata laluan lama, dan pam_unix melangkau semakan kekuatan yang dikenakan kepada pengguna biasa, jadi root boleh menetapkan kata laluan yang tidak boleh ditetapkan oleh pengguna itu sendiri.

Penguncian adalah tindakan yang berasingan. sudo passwd -l deploy meletakkan ! di hadapan hash yang disimpan, jadi tiada kata laluan yang sepadan dengannya. sudo passwd -u deploy membuangnya. Baca semula status dengan sudo passwd -S deploy.

Mengunci kata laluan tidak menghalang pengguna tersebut daripada log masuk. Sebarang kunci dalam ~/.ssh/authorized_keys mereka masih berfungsi, kerana pengesahan kunci awam tidak pernah membaca /etc/shadow. Untuk menghentikan akaun sepenuhnya, tamatkan tempoh akaun itu sendiri:

sudo usermod --expiredate 1 deploy

Tindakan itu menetapkan tamat tempoh akaun kepada tarikh pada tahun 1970, jadi sshd akan menolak log masuk walau apa pun kelayakan yang diberikan. Batalkan tindakan tersebut dengan sudo usermod --expiredate '' deploy.

Elakkan passwd -d. Ia menetapkan kata laluan kosong dan bukannya kata laluan terkunci, dan pada keluaran lama yang masih membawa nullok dalam timbunan PAM, kata laluan kosong adalah kata laluan yang boleh digunakan oleh sesiapa sahaja.

Adakah root memerlukan kata laluan pada VPS?

Ubuntu diedarkan dengan akaun root yang dikunci. /etc/shadow menyimpan ! sebagai ganti hash, dan sudo passwd -S root memaparkan baris yang bermula dengan root L. Tiada apa-apa yang boleh log masuk sebagai root menggunakan kata laluan sehingga anda menetapkannya, itulah sebabnya imej pelayan memberikan anda pengguna yang berupaya menggunakan sudo. Bekerja melalui akaun pengguna dengan keistimewaan terendah pada VPS dan bukannya sebagai root adalah corak yang perlu dikekalkan.

Menetapkan kata laluan root memberikan satu kelebihan khusus: cara untuk masuk melalui konsol pembekal. Konsol tersebut bersambung ke mesin maya di bawah tindanan rangkaian, jadi ia tetap berfungsi apabila sshd tersalah konfigurasi atau peraturan firewall tidak tepat. Ia juga mempunyai kos tersendiri. Shell root dalam menu pemulihan GRUB akan meminta kata laluan root jika ia telah ditetapkan, jadi alat yang sepatutnya anda gunakan untuk menetapkan semula kata laluan yang terlupa kini terhalang oleh kata laluan yang sama.

Menetapkan kata laluan root tidak membenarkan root log masuk melalui SSH. Ubuntu diedarkan dengan PermitRootLogin prohibit-password, yang bermaksud hanya kunci dibenarkan. Semak apa yang sebenarnya digunakan oleh pelayan anda:

sudo sshd -T | grep -i permitrootlogin

sshd -T memaparkan konfigurasi berkesan selepas setiap baris Include diselesaikan, jadi ia adalah satu-satunya jawapan yang tepat apabila /etc/ssh/sshd_config.d/ mengandungi fail drop-in.

Menetapkan kata laluan daripada skrip dengan chpasswd

passwd membaca daripada terminal dan tidak boleh dijalankan daripada skrip. chpasswd membaca pasangan user:password pada input standard, satu pasangan bagi setiap baris.

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

Cara itu berfungsi, namun ia meletakkan kata laluan teks biasa ke dalam sejarah shell dan log CI (integrasi berterusan) anda. Hash kata laluan tersebut terlebih dahulu:

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

openssl passwd -6 meminta kata laluan sebanyak dua kali tanpa paparan (echo), kemudian mencetak hash SHA-512 crypt yang bermula dengan $6$. -e memberitahu chpasswd bahawa medan kedua sudah di-hash, jadi ia disalin ke dalam /etc/shadow sebagaimana adanya. Hash tersebut selamat untuk disimpan dalam repositori atau pemboleh ubah CI, dan teks biasa tidak pernah keluar dari mesin tempat anda menaipnya.

Ubuntu 24.04 melakukan hash pada kata laluan baharu dengan yescrypt ($y$) apabila passwd menetapkannya, manakala openssl passwd -6 memberikan anda SHA-512. Kedua-duanya disahkan semasa log masuk, kerana libxcrypt membaca kedua-dua format tersebut. Mencampurkannya adalah dibolehkan, dan openssl passwd -6 berkelakuan sama pada setiap keluaran Ubuntu LTS, tidak seperti chpasswd -c YESCRYPT: pakej shadow yang lebih lama pada 20.04 tidak mengenali nama kaedah tersebut.

Bagaimanakah anda menyemak sama ada kata laluan benar-benar telah ditukar?

Mulakan dengan metadata, kemudian buktikannya dengan log masuk.

sudo passwd -S deploy

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

Medan kedua ialah status: P untuk kata laluan yang boleh digunakan, L untuk dikunci, NP untuk tiada kata laluan langsung. Tarikh tersebut ialah tarikh kata laluan terakhir ditukar, jadi ia sepatutnya memaparkan tarikh hari ini. Nombor selepas tarikh tersebut ialah medan tempoh hayat yang diterangkan di bawah.

Ujian langsung yang paling selamat ialah sudo itu sendiri. sudo -k membuang cap masa yang disimpan dalam cache dan sudo -v memaksa gesaan baharu. Jika kata laluan baharu diterima di situ, PAM telah menerimanya, dan tiada apa-apa tentang sesi anda yang berubah.

sudo -k && sudo -v

Untuk menguji akaun lain, jalankan su - deploy daripada shell tanpa keistimewaan. Jangan jalankan sudo su - deploy, kerana root tidak pernah diminta kata laluan dan ujian tersebut tidak membuktikan apa-apa. Kata laluan yang salah akan mencetak su: Authentication failure.

Ujian sebenar ialah log masuk SSH baharu daripada komputer riba anda, dengan sesi yang berfungsi masih terbuka:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). di sini bermakna pelayan tidak pernah menawarkan pengesahan kata laluan, jadi tiada pertukaran kata laluan yang akan membolehkan anda masuk. Permission denied, please try again. bermakna ia menawarkan pengesahan tersebut tetapi menolak apa yang anda taip.

Memaksa pertukaran kata laluan pada log masuk seterusnya dengan chage

sudo chage -d 0 deploy

-d 0 menetapkan tarikh perubahan terakhir kepada epoch, supaya PAM menganggap kata laluan tersebut telah tamat tempoh. Log masuk interaktif seterusnya akan meminta kata laluan semasa, kemudian meminta kata laluan baharu, sebelum memberikan akses shell. sudo passwd -e deploy melakukan perkara yang sama.

Gunakan arahan ini hanya untuk akaun yang log masuk secara interaktif menggunakan kata laluan. Kata laluan yang tamat tempoh juga menjejaskan log masuk berasaskan kunci, kerana sshd menjalankan peringkat akaun PAM walaupun pengesahan dilakukan melalui kunci. Skrip ssh deploy@203.0.113.10 'systemctl restart app' kemudiannya akan gagal dengan ralat ini dan terhenti:

Password change required but no TTY available.

Tiada apa-apa selepas baris tersebut akan dijalankan, dan tugasan hanya akan melaporkan kod keluar bukan sifar.

Maksud medan tempoh hayat kata laluan

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

Nombor-nombor tersebut merupakan medan 4 hingga 8 bagi baris pengguna berkenaan dalam /etc/shadow. Hari minimum (chage -m) ialah tempoh masa pengguna perlu menunggu sebelum boleh menukar kata laluan semula, yang menghalang seseorang daripada terus menukar kembali kepada kata laluan lama selepas perubahan paksa. Hari maksimum (chage -M) ialah tempoh kata laluan kekal sah. Hari amaran (chage -W) ialah masa apabila log masuk mula memaparkan amaran. Hari tidak aktif (chage -I) ialah tempoh tangguh selepas tamat tempoh sebelum kata laluan tidak lagi diterima sama sekali. Tamat tempoh akaun (chage -E) ialah tarikh akhir yang tetap, dan ia tidak bergantung kepada kata laluan.

sudo chage -M 90 -W 14 deploy

Tetapkan perkara tersebut hanya apabila polisi memerlukannya. NIST (National Institute of Standards and Technology Amerika Syarikat) telah menasihatkan sejak tahun 2017 agar tidak melakukan tamat tempoh kata laluan secara rutin, kerana ia mendorong pengguna untuk menggunakan variasi yang boleh diramal bagi satu kata laluan, dan mengesyorkan perubahan paksa hanya apabila terdapat bukti kompromi. Kata laluan yang panjang dan unik yang disimpan dalam pengurus kata laluan, ditambah dengan SSH berasaskan kunci, adalah lebih baik daripada kitaran 90 hari.

Apa yang perlu dilakukan apabila anda kehilangan kata laluan root

Jika mana-mana akaun pada pelayan boleh menjalankan sudo, tiada apa yang perlu dipulihkan: sudo passwd root akan menetapkan kata laluan baharu. Situasi sukar berlaku apabila tiada log masuk yang berfungsi langsung.

Semua langkah di bawah memerlukan konsol pembekal, yang disenaraikan dalam kebanyakan panel sebagai VNC (virtual network computing) atau konsol bersiri. Ia bersambung ke mesin maya di bawah tindanan rangkaian, jadi tetapan sshd dan peraturan firewall tidak menjejaskannya.

1. But semula pelayan daripada panel dan perhatikan konsol.
2. Dapatkan menu GRUB. Imej awan biasanya menetapkan GRUB_TIMEOUT=0, jadi tahan Shift pada but BIOS, atau tekan Esc berulang kali pada but UEFI, sebaik sahaja but semula bermula.
3. Pilih Advanced options for Ubuntu, kemudian entri yang berakhir dengan (recovery mode), seterusnya root dalam menu pemulihan.
4. Jalankan mount -o remount,rw / terlebih dahulu. Mod pemulihan melekapkan sistem fail root sebagai baca-sahaja (read-only), jadi tanpanya passwd akan gagal dengan passwd: Authentication token manipulation error kerana ia tidak boleh menulis ke /etc/shadow.
5. Jalankan passwd ubuntu untuk akaun yang anda perlukan, kemudian but semula daripada panel.

Jika root sudah mempunyai kata laluan dan itu adalah kata laluan yang anda hilang, shell pemulihan akan memintanya dan laluan ini tertutup. Sebaliknya, but imej penyelamat (rescue image) pembekal, kemudian lekapkan cakera sebenar dan tukar kata laluan 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 susun atur partition daripada lsblk dan bukannya menyalin /dev/vda1 daripada halaman ini. Partition root adalah yang bersaiz besar. Pada imej UEFI, ia terletak bersebelahan dengan partition EFI kecil yang tidak mengandungi direktori /etc langsung.

Apa yang perlu dilakukan apabila SSH berhenti menerima kata laluan anda

Bekerjalah daripada sesi yang masih anda miliki. Jika tiada sesi yang tinggal, gunakan konsol.

Permission denied, please try again. bermaksud pelayan menawarkan pengesahan kata laluan dan menolak apa yang anda hantar. Punca biasa ialah caps lock, atau susun atur papan kekunci konsol yang berbeza daripada yang anda gunakan semasa menetapkan kata laluan.

Permission denied (publickey). bermaksud pelayan tidak pernah menawarkan pengesahan kata laluan. PasswordAuthentication no ditetapkan di suatu tempat, dan pada Ubuntu 22.04 ke atas, ia biasanya berada dalam fail drop-in di bawah /etc/ssh/sshd_config.d/ yang mengatasi fail utama. Baca nilai berkesan:

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

KbdInteractiveAuthentication yes bersama-sama dengan PasswordAuthentication no masih membenarkan kata laluan masuk, kerana kaedah keyboard-interactive menjalankan stack PAM yang sama. Mematikan satu dan membiarkan satu lagi aktif adalah cara pelayan yang kelihatan seperti hanya menerima kunci tetap menerima kata laluan yang ditaip.

Too many authentication failures dalam mesej putus sambungan bermaksud klien anda menawarkan beberapa kunci sebelum ia mencapai kata laluan, dan pelayan mencapai MaxAuthTries, iaitu 6 secara lalai. Paksa satu kaedah sahaja:

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

Connection refused pada port yang berfungsi seminit yang lalu biasanya bermaksud fail2ban memantau SSH telah mengharamkan alamat anda selepas kegagalan berulang. Peraturan haram lalai ia menolak paket tersebut dan bukannya menggugurkannya, itulah sebabnya penolakan kembali dengan cepat dan bukannya tamat masa. Daripada konsol, sudo fail2ban-client status sshd menyenaraikan alamat yang diharamkan dan sudo fail2ban-client set sshd unbanip 203.0.113.10 mengosongkan alamat anda.

Kata laluan hanyalah langkah permulaan, kunci adalah keadaan akhir

Kata laluan yang berfungsi melalui SSH ialah kata laluan yang boleh diteka oleh setiap pengimbas di internet. Beralihlah kepada pengesahan berasaskan kunci dan aktiviti meneka tersebut tidak lagi menjadi masalah. Jana pasangan kunci, pasang bahagian kunci awam, dan sahkan kunci tersebut membolehkan anda log masuk daripada terminal kedua sebelum anda mengubah apa-apa perkara lain. Asas pengurusan kunci SSH merangkumi penjanaan, authorized_keys dan frasa laluan.

Kemudian, matikan pengesahan kata laluan, dan sahkan perkara tersebut dengan sudo sshd -T dan bukannya sekadar mempercayai fail yang telah anda sunting. Mengeraskan SSH pada VPS membincangkan tetapan sshd lain yang wajar diubah, dan sepuluh minit pertama pada VPS baharu menyusun langkah-langkah tersebut mengikut urutan untuk dilakukan pada pelayan yang baru.

Simpan satu kata laluan selepas itu. Pelayan yang hanya menggunakan kunci dengan konfigurasi sshd yang rosak hanya boleh dicapai melalui konsol pembekal, dan konsol tersebut akan meminta nama pengguna serta kata laluan. Akaun dengan kata laluan yang kuat yang telah anda simpan adalah perkara yang membezakan antara pembaikan lima minit dengan pemasangan semula sistem.

FAQ

Bagaimanakah cara menukar kata laluan root pada VPS saya jika saya tidak mengetahui kata laluan lama?

Log masuk sebagai pengguna yang boleh menjalankan sudo dan jalankan sudo passwd root. Ia menetapkan kata laluan baharu tanpa meminta kata laluan lama, kerana sudo telah mengesahkan identiti anda. Jika tiada akaun pada pelayan yang boleh menjalankan sudo, buka konsol pembekal, but semula ke menu pemulihan GRUB, pilih entri shell root, jalankan mount -o remount,rw /, kemudian jalankan passwd. Jika root sudah mempunyai kata laluan dan itu adalah kata laluan yang anda hilang, shell pemulihan akan memintanya, dan jalan penyelesaian seterusnya ialah menggunakan imej penyelamat (rescue image) pembekal dengan cakera yang dilekapkan (mounted) dan di-chroot.

Mengapakah passwd memaparkan "Authentication token manipulation error"?

Dua punca menyebabkan mesej tersebut. Punca biasa ialah jawapan yang salah pada gesaan Current password:, dan baris passwd: password unchanged di bawahnya mengesahkan tiada apa-apa yang ditulis. Punca lain ialah sistem fail yang tidak boleh ditulis, yang sering berlaku dalam mod pemulihan, kerana / dilekapkan sebagai baca-sahaja (read-only) di sana. Jalankan mount -o remount,rw / dan cuba semula.

Adakah menukar kata laluan Linux saya turut menukar kata laluan sudo saya?

Ya. sudo tidak mempunyai kata laluannya sendiri. Ia mengesahkan identiti anda melalui PAM terhadap entri /etc/shadow yang sama seperti yang digunakan oleh SSH dan su, jadi terdapat satu kata laluan bagi setiap akaun. Itulah sebabnya gesaan sudo pertama selepas penukaran adalah ujian sebenar. Jalankan sudo -k && sudo -v untuk memaksa gesaan tersebut semasa anda masih mempunyai sesi yang aktif.

Adakah menukar kata laluan saya akan merosakkan kunci SSH atau sesi terbuka saya?

Tidak. Pengesahan kunci awam tidak pernah membaca /etc/shadow, jadi kunci akan terus berfungsi selepas penukaran kata laluan, selepas passwd -l, dan selepas chage -d 0. Sesi yang sudah terbuka kekal terbuka, kerana SSH hanya menyemak kelayakan semasa log masuk sahaja. Satu-satunya perkara yang berubah di dalam sesi yang sedang berjalan ialah sudo, yang akan meminta kata laluan baharu sebaik sahaja tanda masa 15 minitnya tamat.

Bagaimanakah cara memaksa pengguna menukar kata laluan mereka pada log masuk seterusnya?

Jalankan sudo chage -d 0 deploy, atau sudo passwd -e deploy, yang melakukan perkara yang sama. Tarikh penukaran terakhir yang disimpan akan beralih ke epoch, PAM menganggap kata laluan tersebut telah tamat tempoh, dan log masuk interaktif seterusnya mesti menetapkan kata laluan baharu sebelum shell bermula. Jangan lakukan ini pada akaun yang digunakan oleh skrip melalui SSH: arahan bukan interaktif akan gagal dengan Password change required but no TTY available. dan tidak akan berjalan.