Paano Palitan ang VPS Root Password sa Ubuntu

Paano baguhin ang root password ng iyong VPS sa Ubuntu

Para baguhin ang root password ng iyong VPS (virtual private server) sa Ubuntu, magbukas ng SSH (secure shell) session bilang user na maaaring magpatakbo ng sudo, at pagkatapos ay patakbuhin ang sudo passwd root. Hihingin nito ang bagong password nang dalawang beses at hindi nito hihingin ang lumang password, dahil napatunayan na ng sudo ang iyong pagkakakilanlan. Para baguhin naman ang sarili mong login password, patakbuhin ang passwd nang walang argument, at hihingin muna nito ang kasalukuyan mong password.

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

Iyon na ang buong proseso. Ang lahat ng kasunod ay tumatalakay sa mga problemang maaaring mangyari: pagtiyak na gumagana ang bagong password bago mawala ang session na maaaring gamitin sa pag-aayos nito, pagtatakda ng mga password mula sa script, sadyang pag-expire ng password, at muling pag-access kapag nawala na ang password.

Magbukas ng pangalawang session bago magpalit ng password

Magbukas ngayon ng pangalawang SSH session at panatilihin itong nakakonekta. Halos lahat ng failure sa gabay na ito ay naaayos sa loob ng dalawang minuto habang may isang authenticated shell pang aktibo, ngunit nangangailangan ng pagpunta sa console kapag nagsara ang huling session.

Patuloy na gumagana ang shell na nakabukas na kahit baguhin, i-lock, o i-expire mo ang account na pagmamay-ari nito, dahil chine-check ng SSH ang credentials sa pag-login at hindi na ito muling chine-check. Ang exception ay sudo. Muli nitong chine-check ang iyong password sa pamamagitan ng PAM (pluggable authentication modules) kapag nag-expire ang timestamp nito, na default na 15 minuto mula sa huling prompt. Kaya ang bagong password ay unang nasusubukan nang aktuwal sa susunod na hingin ito ng sudo, hindi sa pag-login.

Subukan ang bagong password sa pangalawang session habang nananatiling bukas ang una.

Baguhin ang sarili mong password gamit ang passwd

passwd

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

passwd: password updated successfully lamang ang output na nangangahulugang napalitan ang hash sa /etc/shadow. Anumang ibang output ay nangangahulugang nanatili ang dating password.

Dalawang failure ang nangyayari rito. Ang passwd: Authentication token manipulation error, na sinusundan ng passwd: password unchanged, ay nangangahulugang mali ang kasalukuyang password na inilagay mo, o hindi maisulat ang filesystem na naglalaman ng /etc/shadow. Ito ang karaniwang kalagayan sa recovery mode. Ang You must choose a longer password. ay mula sa pam_unix sa /etc/pam.d/common-password, na nagpapatupad ng mga pagsusuri sa haba at pagkakatulad para sa mga ordinaryong user.

Sa karamihan ng VPS image, ang default na account (ubuntu, o anumang pangalan na ibinibigay ng iyong provider) ay walang password. SSH key lamang ang mayroon ito. Walang kasalukuyang password na mabe-verify ang passwd, kaya hindi nito malalampasan ang unang prompt. Sa halip, gamitin ang sudo passwd $USER. Gumagana ito dahil pinapahintulutan ng sudoers drop-in file ng image ang account na iyon na patakbuhin ang sudo nang walang password.

Baguhin ang password ng ibang user gamit ang sudo passwd

sudo passwd deploy

Hindi hihingin sa root ang dating password. Nilalampasan din ng pam_unix ang mga strength check na ipinapatupad nito sa mga ordinaryong user. Kaya makakapagtakda ang root ng password na hindi sana maitatakda ng user para sa sarili niya.

Hiwalay na action ang pag-lock. Naglalagay ang sudo passwd -l deploy ng ! sa unahan ng naka-store na hash, kaya walang password na tutugma rito. Tinatanggal ito ng sudo passwd -u deploy. Basahin muli ang state gamit ang sudo passwd -S deploy.

Hindi pinipigilan ng pag-lock ng password ang user na mag-login. Gumagana pa rin ang anumang key sa kanilang ~/.ssh/authorized_keys dahil hindi binabasa ng public key authentication ang /etc/shadow. Para tuluyang ihinto ang account, i-expire mismo ang account:

sudo usermod --expiredate 1 deploy

Itinatakda nito ang account expiry sa petsa sa 1970, kaya tinatanggihan ng sshd ang login anuman ang credential na gamitin. I-undo ito gamit ang sudo usermod --expiredate '' deploy.

Iwasan ang passwd -d. Nagtatakda ito ng walang laman na password sa halip na naka-lock na password. Sa mas lumang release na may nullok pa rin sa PAM stack, ang walang laman na password ay maaaring gamitin ng kahit sino.

Kailangan ba ng password ang root sa isang VPS?

Naka-lock ang root sa Ubuntu kapag inilabas ito. Ang /etc/shadow ay naglalaman ng ! sa halip na hash, at ang sudo passwd -S root ay nagpi-print ng linyang nagsisimula sa root L. Walang makakapag-login bilang root gamit ang password hangga't hindi ka nagse-set ng isa. Kaya binibigyan ka ng image ng user na may sudo capability. Ang paggamit ng mga user account na may least privilege sa isang VPS sa halip na root ang tamang pattern.

Isang partikular na bagay lang ang makukuha sa pag-set ng root password: paraan para makapasok gamit ang provider console. Kumokonekta ang console na iyon sa virtual machine sa ilalim ng network stack. Kaya gumagana pa rin ito kapag mali ang configuration ng sshd o may maling firewall rule. May kapalit din ito. Hihingi ng root password ang root shell sa GRUB recovery menu kapag may password ang root. Dahil dito, ang tool na gagamitin mo sana para mag-reset ng nakalimutang password ay mapoprotektahan na rin ng parehong password.

Hindi pinapahintulutan ng pag-set ng root password ang root na mag-login sa SSH. May PermitRootLogin prohibit-password ang Ubuntu, na nangangahulugang keys lamang. Suriin kung ano talaga ang ginagamit ng server mo:

sudo sshd -T | grep -i permitrootlogin

Nipi-print ng sshd -T ang effective configuration matapos i-resolve ang bawat linyang Include. Kaya ito lang ang tumpak na sagot kapag may mga drop-in file ang /etc/ssh/sshd_config.d/.

Magtakda ng password mula sa script gamit ang chpasswd

Ang passwd ay nagbabasa mula sa terminal at hindi maaaring patakbuhin mula sa script. Ang chpasswd ay nagbabasa ng user:password pairs mula sa standard input, tig-isa sa bawat linya.

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

Gumagana ito, pero naglalagay ito ng plaintext password sa shell history at sa mga CI (continuous integration) log. I-hash muna ito sa halip:

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

Ang openssl passwd -6 ay humihingi ng password nang dalawang beses nang hindi ipinapakita ang mga character, pagkatapos ay nagpi-print ng SHA-512 crypt hash na nagsisimula sa $6$. Sinasabi ng -e sa chpasswd na naka-hash na ang second field, kaya kinokopya ito sa /etc/shadow nang walang pagbabago. Ligtas itago ang hash sa repository o bilang CI variable, at hindi umaalis sa machine na pinag-type-an mo ang plaintext.

Hinahash ng Ubuntu 24.04 ang mga bagong password gamit ang yescrypt ($y$) kapag itinatakda ng passwd ang mga ito, habang SHA-512 naman ang ibinibigay ng openssl passwd -6. Parehong nabe-verify ang mga ito kapag nagla-login, dahil parehong format ang binabasa ng libxcrypt. Ayos lang pagsamahin ang mga ito, at pareho ang paggana ng openssl passwd -6 sa bawat Ubuntu LTS release, hindi tulad ng chpasswd -c YESCRYPT: hindi alam ng mas lumang shadow package sa 20.04 ang method name na iyon. Nananatili rin ang mga hash na iyon kapag nag-upgrade ng release, kaya hindi mo kailangang i-reset ang password ng sinuman kapag ina-upgrade ang 24.04 server sa 26.04.

Paano susuriin kung talagang nabago ang password?

Magsimula sa metadata, pagkatapos ay patunayan ito sa pamamagitan ng pag-login.

sudo passwd -S deploy

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

Ang ikalawang field ay ang state: P para sa usable na password, L para sa naka-lock, at NP para sa walang password. Ipinapakita ng petsa kung kailan huling nabago ang password, kaya dapat ang petsa nito ay ngayon. Ang mga numerong kasunod nito ay ang mga aging field na tatalakayin sa ibaba.

Ang pinakaligtas na live test ay ang sudo mismo. Itinatapon ng sudo -k ang naka-cache na timestamp, at pinipilit ng sudo -v ang panibagong prompt. Kung tinanggap nito ang bagong password, tinanggap ito ng PAM, at walang binago sa session mo.

sudo -k && sudo -v

Para subukan ang ibang account, patakbuhin ang su - deploy mula sa isang unprivileged shell. Huwag patakbuhin ang sudo su - deploy, dahil hindi kailanman hinihingan ng password ang root at walang napapatunayan ang test. Ang maling password ay nagpi-print ng su: Authentication failure.

Ang tunay na test ay ang panibagong SSH login mula sa laptop mo, habang nakabukas pa ang gumaganang session:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Ang Permission denied (publickey). dito ay nangangahulugang hindi nag-alok ang server ng password authentication, kaya walang pagbabago sa password ang makapagpapapasok sa iyo. Ang Permission denied, please try again. ay nangangahulugang nag-alok ito ng password authentication ngunit tinanggihan ang inilagay mo.

Pilitin ang pagpapalit ng password sa susunod na login gamit ang chage

sudo chage -d 0 deploy

Itinatakda ng -d 0 ang petsa ng huling pagpapalit sa epoch, kaya itinuturing ng PAM na expired ang password. Sa susunod na interactive login, hihingin muna ang kasalukuyang password, pagkatapos ay ang bago, bago ibigay ang shell. Ganoon din mismo ang ginagawa ng sudo passwd -e deploy.

Gamitin lamang ito para sa mga account na nagla-login nang interactive gamit ang password. Nakaaapekto rin ang expired na password sa mga key-based login dahil isinasagawa ng sshd ang PAM account stage kahit key ang ginamit para sa authentication. Pagkatapos, mabibigo ang scripted na ssh deploy@203.0.113.10 'systemctl restart app' at hihinto ito gamit ang error na ito:

Password change required but no TTY available.

Walang anumang kasunod na linya ang isinasagawa, at non-zero exit code lamang ang iniuulat ng job.

Ano ang ibig sabihin ng mga field para sa password aging

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

Ang mga numerong iyon ay fields 4 hanggang 8 ng linya ng user na iyon sa /etc/shadow. Ang minimum days (chage -m) ay kung gaano katagal dapat maghintay ang user bago muling magpalit ng password. Pinipigilan nito ang user na agad bumalik sa dating password matapos ang forced change. Ang maximum days (chage -M) ay kung gaano katagal mananatiling valid ang password. Ang warning days (chage -W) ay kung kailan magsisimulang mag-print ng warning ang mga login. Ang inactive days (chage -I) ay ang grace period matapos mag-expire ang password bago ito tuluyang hindi na tanggapin. Ang account expiry (chage -E) ay isang fixed date at hiwalay ito sa password.

sudo chage -M 90 -W 14 deploy

Itakda lamang ito kapag kinakailangan ng policy. Mula pa noong 2017, nag-advice ang NIST (ang US National Institute of Standards and Technology) laban sa routine password expiry dahil itinutulak nito ang mga tao na gumamit ng predictable variations ng iisang password. Inirerekomenda nitong mag-force ng password change kapag may ebidensiya ng compromise. Mas secure ang mahaba at unique na password na naka-save sa password manager, kasama ng key based SSH, kaysa sa 90 day cycle.

Ano ang gagawin kapag nawala ang root password

Kung may account sa server na maaaring magpatakbo ng sudo, walang kailangang i-recover: nagse-set ang sudo passwd root ng bagong password. Mas mahirap kapag wala nang gumaganang login.

Kailangan ng lahat ng nasa ibaba ang provider console, na karaniwang nakalista sa mga panel bilang VNC (virtual network computing) o serial console. Kumokonekta ito sa virtual machine sa ilalim ng network stack, kaya hindi ito naaapektuhan ng mga setting ng sshd at firewall rules.

1. I-reboot ang server mula sa panel at i-monitor ang console.
2. Buksan ang GRUB menu. Karaniwang naka-set ang cloud images sa GRUB_TIMEOUT=0, kaya pindutin nang matagal ang Shift kapag BIOS boot, o paulit-ulit na pindutin ang Esc kapag UEFI boot, sa sandaling magsimula ang reboot.
3. Piliin ang Advanced options for Ubuntu, pagkatapos ang entry na nagtatapos sa (recovery mode), at pagkatapos ang root sa recovery menu.
4. Patakbuhin muna ang mount -o remount,rw /. Naka-mount ang root filesystem bilang read-only sa recovery, kaya kung wala ito, mabibigo ang passwd sa passwd: Authentication token manipulation error dahil hindi nito maisusulat ang /etc/shadow.
5. Patakbuhin ang passwd ubuntu para sa account na kailangan mo, pagkatapos ay i-reboot mula sa panel.

Kung may password na ang root at iyon ang nawala sa iyo, hihingin ito ng recovery shell at hindi na gagana ang paraang ito. Sa halip, mag-boot gamit ang rescue image ng provider, pagkatapos ay i-mount ang aktuwal na disk at baguhin ang password sa loob nito.

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

Basahin ang partition layout mula sa lsblk sa halip na kopyahin ang /dev/vda1 mula sa page na ito. Ang root partition ang pinakamalaki. Sa UEFI image, katabi nito ang maliit na EFI partition na walang /etc directory.

Ano ang gagawin kapag hindi na tinatanggap ng SSH ang iyong password

Magtrabaho mula sa session na mayroon ka pa. Kung wala nang natitirang session, gamitin ang console.

Ibig sabihin ng Permission denied, please try again. ay nag-alok ang server ng password authentication at tinanggihan nito ang ipinadala mo. Karaniwang sanhi nito ang naka-on na caps lock o keyboard layout sa console na iba sa ginamit mo noong itinakda mo ang password.

Ibig sabihin ng Permission denied (publickey). ay hindi kailanman nag-alok ang server ng password authentication. Naka-set sa isang lugar ang PasswordAuthentication no. Sa Ubuntu 22.04 at mga mas bagong bersyon, karaniwan itong nasa isang drop-in file sa ilalim ng /etc/ssh/sshd_config.d/ na nag-o-override sa pangunahing file. Basahin ang mga aktuwal na value:

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

Ang KbdInteractiveAuthentication yes kapag kasama ng PasswordAuthentication no ay nagbibigay-daan pa rin sa password, dahil ginagamit ng keyboard-interactive method ang parehong PAM stack. Kapag pinatay ang isa at iniwang naka-on ang isa, maaaring magmukhang key-only ang server ngunit tumatanggap pa rin ito ng mga itinitip na password.

Ang Too many authentication failures sa disconnect message ay nangangahulugang nag-alok ang iyong client ng ilang key bago nito sinubukan ang password. Naabot ng server ang MaxAuthTries, na 6 bilang default. Pilitin ang paggamit ng iisang method:

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

Ang Connection refused sa port na gumana isang minuto lamang ang nakalipas ay karaniwang nangangahulugang na-ban ng fail2ban na nagmo-monitor sa SSH ang iyong address matapos ang paulit-ulit na failed attempt. Tinatanggihan ng default na ban rule nito ang packet sa halip na i-drop ito. Dahil dito, mabilis bumabalik ang refusal sa halip na mag-time out. Mula sa console, inililista ng sudo fail2ban-client status sshd ang mga na-ban na address, at inaalis ng sudo fail2ban-client set sshd unbanip 203.0.113.10 ang ban sa iyo.

Ang mga password ay pansamantalang hakbang; ang mga key ang target na setup

Ang password na gumagana sa SSH ay password na maaaring subukang hulaan ng bawat scanner sa internet. Lumipat sa key-based authentication upang hindi na maging mahalaga ang ganitong mga pagtatangka. Bumuo ng key pair, i-install ang public half, at kumpirmahing nakaka-log in ang key mula sa pangalawang terminal bago ka magbago ng iba pang setting. Sinasaklaw ng mga pangunahing kaalaman sa pamamahala ng SSH key ang generation, authorized_keys at passphrases.

Pagkatapos, i-off ang password authentication at kumpirmahin ito gamit ang sudo sshd -T sa halip na basta magtiwala sa file na in-edit mo. Tinutukoy ng pag-hardening ng SSH sa isang VPS ang iba pang sshd setting na dapat baguhin, at inilalagay ng unang sampung minuto sa bagong VPS ang mga ito sa tamang pagkakasunod-sunod para sa bagong server.

Panatilihin ang isang password pagkatapos nito. Ang key-only server na may sirang sshd config ay maa-access lamang sa provider console, at humihingi ang console na iyon ng username at password. Ang account na may matibay na password na naka-store mo ang nagtatakda kung limang minutong pag-aayos lang ang kailangan o reinstall.

FAQ

Paano ko babaguhin ang root password sa aking VPS kung hindi ko alam ang luma?

Mag-log in bilang user na maaaring magpatakbo ng sudo, at patakbuhin ang sudo passwd root. Nagtatakda ito ng bagong password nang hindi hinihingi ang luma, dahil na-authenticate ka na ng sudo. Kung walang account sa server na maaaring magpatakbo ng sudo, buksan ang console ng provider, mag-reboot sa GRUB recovery menu, piliin ang root shell entry, patakbuhin ang mount -o remount,rw /, at pagkatapos ay patakbuhin ang passwd. Kung may password na ang root at iyon ang nawala sa iyo, hihingin ito ng recovery shell. Ang natitirang paraan ay gamitin ang rescue image ng provider, i-mount ang disk, at gumamit ng chroot.

Bakit sinasabi ng passwd ang “Authentication token manipulation error”?

Dalawang sanhi ang naglalabas ng mensaheng ito. Ang karaniwang sanhi ay maling sagot sa prompt na Current password:, at kinukumpirma ng linyang passwd: password unchanged sa ilalim nito na walang naisulat. Ang isa pa ay filesystem na hindi maaaring sulatan. Ito ang nangyayari sa recovery mode dahil naka-mount bilang read-only ang / doon. Patakbuhin ang mount -o remount,rw / at subukan muli.

Ang pagpapalit ba ng Linux password ko ay nagpapalit din ng sudo password ko?

Oo. Walang sariling password ang sudo. Ina-authenticate ka nito sa pamamagitan ng PAM laban sa parehong entry sa /etc/shadow na ginagamit ng SSH at su, kaya iisa ang password ng bawat account. Ito rin ang dahilan kung bakit ang unang prompt ng sudo pagkatapos ng pagbabago ang tunay na test. Patakbuhin ang sudo -k && sudo -v upang pilitin ang prompt na iyon habang may gumagana ka pang session.

Masisira ba ng pagpapalit ng password ko ang aking SSH keys o mga bukas kong session?

Hindi. Hindi kailanman binabasa ng public key authentication ang /etc/shadow, kaya patuloy na gagana ang mga key pagkatapos magpalit ng password, pagkatapos ng passwd -l, at pagkatapos ng chage -d 0. Mananatiling bukas ang mga session na kasalukuyang nakabukas dahil sinusuri lamang ng SSH ang credentials sa oras ng login. Ang nagbabago lamang sa loob ng live session ay sudo, na humihingi ng bagong password kapag nag-expire ang 15 minutong timestamp nito.

Paano ko pipilitin ang isang user na palitan ang password nito sa susunod na login?

Patakbuhin ang sudo chage -d 0 deploy o ang sudo passwd -e deploy, na pareho ang ginagawa. Itinatakda sa epoch ang naka-store na petsa ng huling pagbabago. Itinuturing ng PAM na expired ang password, kaya dapat magtakda ng bagong password ang susunod na interactive login bago magsimula ang shell. Huwag itong gawin sa account na ginagamit ng mga script sa SSH. Mabibigo ang non-interactive command sa Password change required but no TTY available. at hindi ito tatakbo.