Paano Palitan ang Root Password sa Ubuntu VPS

Paano palitan ang root password ng iyong VPS sa Ubuntu

Para palitan ang root password ng iyong VPS (virtual private server) sa Ubuntu, magbukas ng SSH (secure shell) session bilang user na maaaring magpatakbo ng sudo, pagkatapos ay patakbuhin ang sudo passwd root. Hihingin nito ang bagong password nang dalawang beses at hindi hihingin ang luma, dahil napatunayan na ng sudo ang iyong pagkakakilanlan. Kung sarili mong login password ang papalitan, patakbuhin ang passwd nang walang mga argumento. 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 mga sumusunod ay tumatalakay sa mga karaniwang nagiging problema: pag-verify na gumagana ang bagong password bago mawala ang session na maaaring gamitin sa pag-aayos nito, pagtatakda ng 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 konektado. Halos lahat ng failure sa gabay na ito ay naaayos sa loob ng dalawang minuto habang may isang authenticated shell na gumagana pa, ngunit kailangan nang pumunta sa console kapag nagsara ang huli.

Patuloy na gumagana ang shell na nakabukas na kahit palitan, i-lock, o i-expire mo ang account na pagmamay-ari nito, dahil tinitingnan ng SSH ang credentials sa pag-login at hindi na ito muling sinusuri. Ang exception ay sudo. Muli nitong sinusuri ang iyong password sa pamamagitan ng PAM (pluggable authentication modules) kapag nag-expire ang timestamp nito, na karaniwang 15 minuto mula sa huling prompt. Kaya ang bagong password ay unang tunay na masusubukan sa susunod na hilingin 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 nagmumula sa pam_unix sa /etc/pam.d/common-password, na nagpapatupad ng mga pagsusuri sa haba at pagkakahawig para sa mga ordinaryong user.

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

Baguhin ang password ng ibang user gamit ang sudo passwd

sudo passwd deploy

Hindi hihingan ang root ng lumang password, at nilalampasan ng pam_unix ang mga pagsusuri sa lakas ng password na ipinapatupad nito sa mga karaniwang user. Dahil dito, maaaring magtakda ang root ng password na hindi sana maitakda ng user para sa sarili niya.

Hiwalay na aksyon ang pag-lock. Naglalagay ang sudo passwd -l deploy ng ! sa unahan ng nakaimbak na hash, kaya walang password ang makakatugma rito. Inaalis ito ng sudo passwd -u deploy. Basahin muli ang estado gamit ang sudo passwd -S deploy.

Hindi pinipigilan ng pag-lock ng password ang user na mag-log in. 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 expiry ng account sa petsa noong 1970, kaya tinatanggihan ng sshd ang login anuman ang credential na gamitin. Ibalik 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 mayroon pa ring nullok sa PAM stack, ang walang laman na password ay maaaring gamitin ng kahit sino.

Kailangan ba ng root ng password sa isang VPS?

Naka-lock ang root sa Ubuntu release. Ang /etc/shadow ay naglalaman ng ! sa halip na hash, at nagpi-print ang sudo passwd -S root ng linyang nagsisimula sa root L. Walang makakapag-login bilang root gamit ang password hangga't hindi ka nagse-set ng isa. Kaya naman binibigyan ka ng image ng user na may kakayahang gumamit ng sudo. Ang dapat panatilihin ay ang pagtatrabaho gamit ang mga user account na may least privilege sa isang VPS, sa halip na bilang root.

Isang partikular na pakinabang lang ang naibibigay ng pag-set ng root password: paraan ito para makapasok sa provider console. Kumokonekta ang console na ito 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. Hihingin ng root shell sa GRUB recovery menu ang root password kapag may password ang root. Dahil dito, ang tool na gagamitin mo sana para mag-reset ng nakalimutang password ay nasa likod na rin ng parehong password.

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

sudo sshd -T | grep -i permitrootlogin

Pini-print ng sshd -T ang aktuwal na configuration matapos malutas ang bawat linyang Include. Kaya ito lamang ang mapagkakatiwalaang sagot kapag may mga drop-in file na pinapapasok ng /etc/ssh/sshd_config.d/.

Magtakda ng password mula sa script gamit ang chpasswd

Binabasa ng passwd ang input mula sa terminal at hindi ito maaaring patakbuhin mula sa script. Binabasa ng chpasswd ang mga pares na user:password mula sa standard input, tig-isa 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:

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

Dalawang beses humihingi ng password ang openssl passwd -6 nang hindi ipinapakita ang input, pagkatapos ay nagpi-print ito 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 hindi binabago. Ligtas na itago ang hash sa repository o bilang CI variable, at hindi umaalis sa machine kung saan mo ito inilagay ang plaintext.

Hinahash ng Ubuntu 24.04 ang mga bagong password gamit ang yescrypt ($y$) kapag itinatakda ng passwd ang mga ito, samantalang SHA-512 ang ibinibigay ng openssl passwd -6. Parehong nabe-verify ang mga ito sa pag-login dahil binabasa ng libxcrypt ang parehong format. Ayos lang ang paghahalo ng mga ito, at pareho ang kilos ng openssl passwd -6 sa bawat Ubuntu LTS release. Hindi ito totoo sa chpasswd -c YESCRYPT: hindi alam ng mas lumang shadow package sa 20.04 ang method name na iyon. Nananatili ang mga hash na ito kahit mag-upgrade ng release, kaya hindi ka mapipilitang mag-reset ng password ng sinuman kapag inilipat ang 24.04 server sa 26.04.

Paano susuriin kung talagang nagbago ang password?

Magsimula sa metadata, pagkatapos ay patunayan ito gamit ang login.

sudo passwd -S deploy

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

Ang ikalawang field ang state: P para sa magagamit na password, L para sa naka-lock, at NP para sa walang password. Ang petsa ay kung kailan huling binago ang password, kaya dapat ay petsa ngayon ang nakalagay. Ang mga numerong kasunod nito ay ang aging fields na ipinaliliwanag 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 nagbago sa session mo.

sudo -k && sudo -v

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

Ang aktuwal na test ay bagong SSH login mula sa laptop mo, habang bukas pa ang gumaganang session:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Ibig sabihin ng Permission denied (publickey). dito, hindi kailanman nag-alok ang server ng password authentication, kaya walang password change na makapagpapapasok sa iyo. Ibig sabihin ng Permission denied, please try again., nag-alok ito ng password authentication ngunit tinanggihan ang inilagay mo.

Magpatupad ng 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, saka ang bagong password, bago magbigay ng shell. Pareho mismo ang ginagawa ng sudo passwd -e deploy.

Gamitin lamang ito sa mga account na nagla-login nang interactive gamit ang password. Nakaaapekto rin ang expired na password sa mga login na gumagamit ng key, dahil pinapatakbo ng sshd ang PAM account stage kahit key ang ginamit sa authentication. Kasunod nito, mabibigo ang naka-script na ssh deploy@203.0.113.10 'systemctl restart app' at hihinto:

Password change required but no TTY available.

Walang ibang command na tatakbo pagkatapos ng linyang iyon, at non-zero exit code lamang ang iuulat ng job.

Kahulugan 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 kailangang maghintay ang user bago muling magpalit ng password. Pinipigilan nito ang user na agad bumalik sa dating password matapos ang sapilitang pagpapalit. Ang maximum days (chage -M) ay kung gaano katagal mananatiling valid ang password. Ang warning days (chage -W) ay kung kailan magsisimulang magpakita ng warning ang mga login. Ang inactive days (chage -I) ay ang grace period pagkatapos mag-expire ng 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 kung kinakailangan ng policy. Mula pa noong 2017, nagpapayo ang NIST (ang National Institute of Standards and Technology ng US) laban sa regular na password expiry. Itinutulak kasi nito ang mga tao na gumamit ng mga predictable na variation ng iisang password. Inirerekomenda ng NIST ang pagpapalit ng password kapag may ebidensiya ng compromise. Mas ligtas ang isang mahaba at unique na password na naka-save sa password manager, kasama ang 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, wala nang kailangang i-recover: nagtatakda ang sudo passwd root ng bagong password. Mas mahirap ang sitwasyon kapag wala nang gumaganang login.

Kailangan ng lahat ng hakbang sa ibaba ang provider console, na karaniwang nakalista sa karamihan ng panel bilang VNC (virtual network computing) o serial console. Direktang 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 sa BIOS boot, o paulit-ulit na pindutin ang Esc sa UEFI boot, sa sandaling magsimula ang reboot.
3. Piliin ang Advanced options for Ubuntu, pagkatapos ay ang entry na nagtatapos sa (recovery mode), at pagkatapos ay ang root sa recovery menu.
4. Patakbuhin muna ang mount -o remount,rw /. Naka-mount bilang read-only ang root filesystem sa recovery, kaya kung hindi ito gagawin, mabibigo ang passwd sa passwd: Authentication token manipulation error dahil hindi nito maisulat ang /etc/shadow.
5. Patakbuhin ang passwd ubuntu para sa account na kailangan mo, pagkatapos ay i-reboot mula sa panel.

Kung mayroon nang password ang root at iyon ang nawala sa iyo, hihingin ito ng recovery shell at hindi na magagamit 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, nasa tabi nito ang isang 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., nag-alok ang server ng password authentication pero tinanggihan nito ang ipinadala mo. Karaniwang sanhi nito ang naka-enable na caps lock o console keyboard layout na iba sa ginamit mo nang itakda ang password.

Ibig sabihin ng Permission denied (publickey)., hindi kailanman nag-alok ang server ng password authentication. Naka-set sa isang lugar ang PasswordAuthentication no. Sa Ubuntu 22.04 at 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 aktuwal na mga value:

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

Kapag naka-enable ang KbdInteractiveAuthentication yes kasabay ng PasswordAuthentication no, nakapapasa pa rin ang password dahil ginagamit ng keyboard-interactive method ang parehong PAM stack. Kapag pinatay ang isa at iniwang naka-enable ang isa pa, magmumukhang key-only ang server pero tatanggap pa rin ito ng mga password na tina-type.

Ipinapakita rin ang linyang iyon kapag tinanggihan ang key login. Kaya kung key, hindi password, ang iniaalok mo, isa lamang ang setting ng password ng server sa limang sanhi ng Permission denied (publickey). Sinasabi ng output ng ssh -v kung alin sa mga ito ang nangyayari.

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

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 bina-ban ng fail2ban na nagmo-monitor sa SSH ang iyong address matapos ang paulit-ulit na mga failure. Tinatanggihan ng default ban rule nito ang packet sa halip na i-drop ito. Kaya mabilis bumabalik ang refusal sa halip na mag-timeout. Mula sa console, inililista ng sudo fail2ban-client status sshd ang mga naka-ban na address, at inaalis ng sudo fail2ban-client set sshd unbanip 203.0.113.10 ang iyong address sa ban.

Ang mga password ay panimulang hakbang; ang mga key ang panghuling setup

Ang password na gumagana sa SSH ay password na maaaring hulaan ng bawat scanner sa internet. Lumipat sa key-based authentication upang hindi na maging mahalaga ang paghula. Bumuo ng key pair, i-install ang public half, at tiyaking nakakapag-log in ang key mula sa pangalawang terminal bago ka magbago ng iba pa. Sinasaklaw ng mga pangunahing kaalaman sa SSH key management ang pagbuo, authorized_keys, at mga passphrase.

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. Tinatalakay ng pagpapatibay ng SSH sa isang VPS ang iba pang sshd setting na dapat baguhin, at inaayos ng unang sampung minuto sa bagong VPS ang mga ito ayon sa tamang pagkakasunod-sunod para sa bagong server.

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

FAQ

Paano ko papalitan ang root password sa aking VPS kung hindi ko alam ang dati?

Mag-login bilang user na maaaring magpatakbo ng sudo, pagkatapos ay patakbuhin ang sudo passwd root. Nagtatakda ito ng bagong password nang hindi hinihingi ang dati, dahil na-authenticate ka na ng sudo. Kung walang account sa server na maaaring magpatakbo ng sudo, buksan ang provider console, 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 magsagawa ng chroot.

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

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

Nagbabago rin ba ang aking sudo password kapag binago ko ang aking Linux password?

Oo. Walang sariling password ang sudo. Ina-authenticate ka nito sa pamamagitan ng PAM laban sa parehong /etc/shadow entry na ginagamit ng SSH at su, kaya isang password lang ang ginagamit ng bawat account. Kaya ang unang sudo prompt pagkatapos ng pagbabago ang aktuwal na pagsubok. Patakbuhin ang sudo -k && sudo -v upang pilitin na lumabas ang prompt na iyon habang may gumagana ka pang session.

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

Hindi. Hindi 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 nakakonekta dahil sinusuri lamang ng SSH ang credentials kapag nagla-login. Ang tanging nagbabago sa loob ng live session ay ang sudo, na humihingi ng bagong password kapag lumampas na ang 15 minutong timestamp nito.

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

Patakbuhin ang sudo chage -d 0 deploy o sudo passwd -e deploy, na pareho ang ginagawa. Itinatakda sa epoch ang nakaimbak na last-change date, itinuturing ng PAM na expired ang password, at kailangang magtakda ng bagong password ang user sa 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 at magbabalik ng Password change required but no TTY available. nang hindi ito tumatakbo.