Cara Tukar Kata Laluan Root VPS Ubuntu

Cara menukar kata laluan root VPS pada Ubuntu

Untuk menukar kata laluan root VPS (pelayan peribadi maya) pada Ubuntu, buka sesi SSH (shell selamat) sebagai pengguna yang boleh menjalankan sudo, kemudian jalankan sudo passwd root. Perintah ini meminta kata laluan baharu sebanyak 2 kali dan tidak pernah meminta kata laluan lama kerana sudo telah mengesahkan identiti anda. Untuk menukar kata laluan log masuk anda sendiri, jalankan passwd tanpa argumen. Perintah ini 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

Itulah keseluruhan operasi. Bahagian di bawah menerangkan perkara yang biasanya menimbulkan masalah: mengesahkan kata laluan baharu berfungsi sebelum anda kehilangan sesi yang boleh digunakan untuk membaikinya, menetapkan kata laluan daripada skrip, sengaja menetapkan kata laluan supaya luput, dan mendapatkan semula akses apabila kata laluan sudah hilang.

Buka sesi kedua sebelum anda mengubah kata laluan

Buka sesi SSH kedua sekarang dan biarkan sesi itu kekal bersambung. Hampir setiap kegagalan dalam panduan ini boleh dibaiki dalam masa dua minit selagi satu shell yang disahkan masih aktif. Jika sesi terakhir ditutup, anda mungkin perlu menggunakan konsol.

Shell yang sudah terbuka terus berfungsi selepas anda mengubah, mengunci atau tamat tempoh akaun yang dikaitkan dengannya. SSH menyemak kelayakan semasa log masuk dan tidak menyemaknya lagi selepas itu. Pengecualiannya ialah sudo. Ia menyemak semula kata laluan anda melalui PAM (modul pengesahan boleh pasang) selepas cap masanya tamat, secara lalai 15 minit selepas gesaan terakhir. Oleh itu, kata laluan baharu menerima ujian sebenar yang pertama apabila sudo memintanya semula, bukan semasa log masuk.

Uji kata laluan baharu dalam sesi kedua sementara sesi pertama masih 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 cincangan dalam /etc/shadow telah digantikan. Output lain bermaksud kata laluan lama masih digunakan.

Dua kegagalan berlaku di sini. passwd: Authentication token manipulation error, diikuti oleh passwd: password unchanged, bermaksud kata laluan semasa yang anda masukkan adalah salah, atau sistem fail yang mengandungi /etc/shadow tidak boleh ditulis. Ini ialah keadaan biasa dalam mod pemulihan. You must choose a longer password. datang daripada pam_unix dalam /etc/pam.d/common-password, yang menguatkuasakan semakan panjang dan persamaan untuk pengguna biasa.

Pada kebanyakan imej VPS, akaun lalai (ubuntu, atau apa-apa nama yang disediakan oleh pembekal anda) tidak mempunyai kata laluan, hanya kunci SSH. passwd tidak mempunyai kata laluan semasa untuk disahkan, jadi ia tidak dapat melepasi gesaan pertama. Sebaliknya, gunakan sudo passwd $USER. Ini berfungsi kerana fail drop-in sudoers bagi imej tersebut membenarkan akaun itu menjalankan sudo tanpa kata laluan.

Tukar kata laluan pengguna lain dengan sudo passwd

sudo passwd deploy

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

Mengunci kata laluan ialah tindakan berasingan. sudo passwd -l deploy meletakkan ! di hadapan cincangan 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 itu daripada log masuk. Sebarang kunci dalam ~/.ssh/authorized_keys masih berfungsi kerana pengesahan kunci awam tidak pernah membaca /etc/shadow. Untuk menghentikan akaun sepenuhnya, luputkan akaun itu sendiri:

sudo usermod --expiredate 1 deploy

Perintah itu menetapkan tamat tempoh akaun kepada tarikh pada tahun 1970, supaya sshd menolak log masuk tanpa mengira kelayakan yang ditawarkan. Batalkan perubahan itu dengan sudo usermod --expiredate '' deploy.

Elakkan passwd -d. Perintah itu menetapkan kata laluan kosong, bukannya mengunci kata laluan. Pada keluaran lama yang masih mengandungi nullok dalam tindanan PAM, kata laluan kosong boleh digunakan oleh sesiapa sahaja.

Adakah root memerlukan kata laluan pada VPS?

Ubuntu dikeluarkan dengan root dikunci. /etc/shadow mengandungi ! sebagai ganti cincangan, dan sudo passwd -S root mencetak baris yang bermula dengan root L. Tiada sesiapa boleh log masuk sebagai root menggunakan kata laluan sehingga anda menetapkan kata laluan. Oleh itu, imej tersebut memberikan anda pengguna yang mempunyai keupayaan sudo. Gunakan akaun pengguna dengan keistimewaan minimum pada VPS dan bukan root.

Menetapkan kata laluan root memberikan satu perkara khusus: cara untuk masuk melalui konsol penyedia. Konsol itu bersambung terus ke mesin maya di bawah tindanan rangkaian. Oleh itu, konsol tersebut masih berfungsi apabila sshd tersalah konfigurasi atau peraturan firewall tidak betul. Namun, terdapat kosnya. Menu pemulihan GRUB meminta kata laluan root apabila root mempunyai kata laluan. Ini bermakna alat yang anda gunakan untuk menetapkan semula kata laluan yang terlupa kini dilindungi oleh kata laluan yang sama.

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

sudo sshd -T | grep -i permitrootlogin

sshd -T mencetak konfigurasi berkesan selepas setiap baris Include diselesaikan. Oleh itu, ini ialah jawapan yang tepat apabila /etc/ssh/sshd_config.d/ mengandungi fail drop-in.

Tetapkan kata laluan daripada skrip dengan chpasswd

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

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

Cara ini berfungsi, tetapi kata laluan teks biasa akan dimasukkan ke dalam sejarah shell dan log CI (integrasi berterusan) anda. Cincangkan kata laluan itu terlebih dahulu:

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

openssl passwd -6 meminta kata laluan sebanyak 2 kali tanpa memaparkan aksara yang ditaip, kemudian mencetak cincangan crypt SHA-512 yang bermula dengan $6$. -e memberitahu chpasswd bahawa medan kedua sudah dicincang, jadi medan itu disalin ke dalam /etc/shadow tanpa perubahan. Cincangan itu selamat disimpan dalam repositori atau pemboleh ubah CI, dan teks biasa tidak pernah keluar dari mesin tempat anda menaipnya.

Ubuntu 24.04 mencincang kata laluan baharu dengan yescrypt ($y$) apabila passwd menetapkannya, manakala openssl passwd -6 menggunakan SHA-512. Kedua-duanya disahkan semasa log masuk kerana libxcrypt membaca kedua-dua format. Mencampurkan kedua-duanya tidak menjadi masalah, dan openssl passwd -6 berfungsi dengan cara yang 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 bahawa kata laluan benar-benar telah berubah?

Mulakan dengan metadata, kemudian buktikannya melalui log masuk.

sudo passwd -S deploy

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

Medan kedua ialah keadaan: P untuk kata laluan yang boleh digunakan, L untuk kata laluan yang dikunci, dan NP untuk tiada kata laluan langsung. Tarikh itu menunjukkan masa kata laluan kali terakhir diubah, jadi tarikh tersebut sepatutnya ialah tarikh hari ini. Nombor selepasnya ialah medan tempoh sah yang diterangkan di bawah.

Ujian langsung yang paling selamat ialah sudo itu sendiri. sudo -k membuang cap masa yang dicache dan sudo -v memaksa gesaan baharu. Jika kata laluan baharu diterima di situ, PAM telah menerimanya dan tiada apa-apa tentang sesi anda 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 memasukkan kata laluan dan ujian itu tidak membuktikan apa-apa. Kata laluan yang salah akan memaparkan su: Authentication failure.

Ujian sebenar ialah log masuk SSH baharu dari komputer riba anda, sementara sesi yang sedang digunakan masih terbuka:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). di sini bermaksud pelayan tidak pernah menawarkan pengesahan kata laluan, jadi tiada perubahan kata laluan akan membolehkan anda masuk. Permission denied, please try again. bermaksud pelayan memang menawarkannya tetapi menolak input yang anda taip.

Paksa pertukaran kata laluan pada log masuk seterusnya dengan chage

sudo chage -d 0 deploy

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

Gunakan kaedah ini hanya untuk akaun yang log masuk secara interaktif dengan kata laluan. Kata laluan yang telah tamat tempoh turut menjejaskan log masuk berasaskan key kerana sshd menjalankan peringkat akaun PAM walaupun key digunakan untuk pengesahan. ssh deploy@203.0.113.10 'systemctl restart app' yang dijalankan dalam skrip kemudiannya gagal dengan mesej ini dan berhenti:

Password change required but no TTY available.

Tiada arahan selepas baris itu dijalankan, dan tugas tersebut hanya melaporkan kod keluar bukan sifar.

Maksud medan penuaan 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 tersebut ialah medan 4 hingga 8 pada baris pengguna itu dalam /etc/shadow. Hari minimum (chage -m) ialah tempoh pengguna mesti menunggu sebelum menukar kata laluan sekali lagi. Tetapan ini menghalang pengguna daripada terus kembali kepada kata laluan lama selepas perubahan yang dipaksa. Hari maksimum (chage -M) ialah tempoh kata laluan kekal sah. Hari amaran (chage -W) ialah masa sistem mula memaparkan amaran semasa log masuk. Hari tidak aktif (chage -I) ialah tempoh kelonggaran selepas kata laluan tamat tempoh, sebelum kata laluan itu tidak lagi diterima sama sekali. Tamat tempoh akaun (chage -E) ialah tarikh tetap dan tidak bergantung pada kata laluan.

sudo chage -M 90 -W 14 deploy

Tetapkan nilai itu hanya apabila dasar memerlukannya. NIST (National Institute of Standards and Technology Amerika Syarikat) telah menasihatkan sejak 2017 supaya tamat tempoh kata laluan secara rutin tidak digunakan. Amalan itu mendorong pengguna menggunakan variasi kata laluan yang sama dan mudah dijangka. NIST mengesyorkan supaya perubahan dipaksa apabila terdapat bukti akaun telah terjejas. Kata laluan panjang dan unik yang disimpan dalam pengurus kata laluan, bersama SSH berasaskan kunci, lebih baik daripada kitaran 90 hari.

Perkara yang perlu dilakukan apabila anda kehilangan kata laluan root

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

Semua langkah di bawah memerlukan konsol penyedia, yang biasanya disenaraikan dalam kebanyakan panel sebagai VNC (pengkomputeran rangkaian maya) atau konsol bersiri. Konsol ini disambungkan kepada mesin maya di bawah tindanan rangkaian, jadi tetapan sshd dan peraturan tembok api tidak menjejaskannya.

1. But semula pelayan daripada panel dan pantau konsol.
2. Paparkan menu GRUB. Imej awan biasanya menetapkan GRUB_TIMEOUT=0, jadi tahan Shift semasa but BIOS, atau tekan Esc berulang kali semasa but UEFI, sebaik sahaja proses but semula bermula.
3. Pilih Advanced options for Ubuntu, kemudian entri yang berakhir dengan (recovery mode), kemudian root dalam menu pemulihan.
4. Jalankan mount -o remount,rw / dahulu. Pemulihan melekapkan sistem fail root sebagai baca sahaja, jadi tanpa langkah ini passwd gagal dengan passwd: Authentication token manipulation error kerana tidak dapat menulis /etc/shadow.
5. Jalankan passwd ubuntu untuk akaun yang diperlukan, kemudian but semula daripada panel.

Jika root sudah mempunyai kata laluan dan kata laluan itulah yang hilang, shell pemulihan tersebut akan memintanya dan laluan ini tidak dapat diteruskan. But imej penyelamat penyedia sebagai gantinya, kemudian lekapkan cakera sebenar dan ubah 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 jangan salin /dev/vda1 daripada halaman ini. Partition root ialah partition yang besar. Pada imej UEFI, partition ini terletak bersebelahan partition EFI kecil yang langsung tidak mengandungi direktori /etc.

Perkara yang perlu dilakukan apabila SSH berhenti menerima kata laluan

Teruskan dari sesi yang masih anda gunakan. Jika tiada sesi yang tinggal, gunakan konsol.

Permission denied, please try again. bermaksud pelayan menawarkan pengesahan kata laluan tetapi menolak perkara yang anda hantar. Punca yang biasa ialah caps lock aktif atau susun atur papan kekunci konsol berbeza daripada susun atur 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 serta versi lebih baharu, tetapan itu 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 PasswordAuthentication no masih membenarkan kata laluan digunakan kerana kaedah keyboard-interactive menjalankan tindanan PAM yang sama. Mematikan satu dan membiarkan satu lagi aktif menyebabkan pelayan yang kelihatan hanya menerima kunci masih menerima kata laluan yang ditaip.

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

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

Connection refused pada port yang berfungsi seminit sebelumnya biasanya bermaksud fail2ban yang memantau SSH telah menyekat alamat anda selepas beberapa percubaan gagal. Peraturan sekatan lalainya menolak paket dan bukannya menggugurkannya. Oleh itu, penolakan diterima dengan cepat dan bukannya tamat masa. Dari konsol, sudo fail2ban-client status sshd menyenaraikan alamat yang disekat dan sudo fail2ban-client set sshd unbanip 203.0.113.10 membuang alamat anda daripada senarai.

Kata laluan ialah langkah peralihan, kunci ialah keadaan akhir

Kata laluan yang berfungsi melalui SSH ialah kata laluan yang boleh cuba diteka oleh setiap pengimbas di internet. Beralih kepada pengesahan berasaskan kunci supaya cubaan meneka tidak lagi berkesan. Jana pasangan kunci, pasang bahagian awam, dan sahkan kunci tersebut membolehkan anda log masuk dari terminal kedua sebelum anda mengubah perkara lain. Asas pengurusan kunci SSH merangkumi penjanaan, authorized_keys dan frasa laluan.

Kemudian matikan pengesahan kata laluan, dan sahkannya dengan sudo sshd -T, bukan dengan mempercayai fail yang anda sunting. pengerasan SSH pada VPS menerangkan tetapan sshd lain yang wajar diubah, manakala sepuluh minit pertama pada VPS baharu menyusun tetapan tersebut mengikut urutan pelaksanaannya pada pelayan baharu.

Simpan satu kata laluan selepas itu. Pelayan yang hanya menerima kunci dengan konfigurasi sshd yang rosak hanya boleh dicapai melalui konsol penyedia, dan konsol itu meminta nama pengguna serta kata laluan. Akaun dengan kata laluan kukuh yang telah anda simpan membezakan pembaikan selama lima minit daripada pemasangan semula.

FAQ

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

Log masuk sebagai pengguna yang boleh menjalankan sudo, kemudian jalankan sudo passwd root. Perintah itu menetapkan kata laluan baharu tanpa meminta kata laluan lama kerana sudo telah mengesahkan anda. Jika tiada akaun pada pelayan yang boleh menjalankan sudo, buka konsol penyedia, 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 kata laluan itu yang hilang, shell pemulihan akan memintanya. Dalam keadaan itu, gunakan imej penyelamat penyedia, lekapkan cakera dan jalankan chroot.

Mengapakah passwd memaparkan "Authentication token manipulation error"?

Dua punca boleh menghasilkan mesej itu. Punca yang biasa ialah jawapan yang salah pada gesaan Current password:. Baris passwd: password unchanged di bawahnya mengesahkan bahawa tiada perubahan ditulis. Punca yang satu lagi ialah sistem fail yang tidak boleh ditulis. Keadaan ini berlaku dalam mod pemulihan kerana / dilekapkan sebagai baca sahaja. Jalankan mount -o remount,rw / dan cuba lagi.

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

Ya. sudo tidak mempunyai kata laluan sendiri. Ia mengesahkan anda melalui PAM menggunakan entri /etc/shadow yang sama seperti yang digunakan oleh SSH dan su. Oleh itu, setiap akaun hanya mempunyai satu kata laluan. Atas sebab yang sama, gesaan sudo yang pertama selepas perubahan ialah ujian sebenar. Jalankan sudo -k && sudo -v untuk memaksa gesaan itu semasa sesi anda masih berfungsi.

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

Tidak. Pengesahan kunci awam tidak pernah membaca /etc/shadow. Oleh itu, kunci terus berfungsi selepas pertukaran kata laluan, selepas passwd -l dan selepas chage -d 0. Sesi yang telah dibuka terus kekal terbuka kerana SSH hanya menyemak kelayakan semasa log masuk. Satu-satunya perkara yang berubah dalam sesi aktif ialah sudo, yang meminta kata laluan baharu selepas cap masa 15 minit tamat tempoh.

Bagaimanakah saya memaksa pengguna menukar kata laluan pada log masuk seterusnya?

Jalankan sudo chage -d 0 deploy atau sudo passwd -e deploy, yang menghasilkan kesan yang sama. Tarikh perubahan terakhir yang disimpan ditetapkan kepada epoch. PAM menganggap kata laluan itu telah tamat tempoh, dan log masuk interaktif seterusnya mesti menetapkan kata laluan baharu sebelum shell dimulakan. Jangan lakukan ini pada akaun yang digunakan oleh skrip melalui SSH. Perintah bukan interaktif akan gagal dengan Password change required but no TTY available. dan tidak akan dijalankan.